User login with PKCE
The interactive OIDC leg: the app opens your identity provider in a real browser, catches the redirect on a locally-run server, and exchanges the code for tokens using PKCE. Triggered lazily, cancellable mid-flow.
Client credentials get you a machine token. Plenty of APIs, though, only make sense as a user — the endpoint reads the subject out of the token and hands back that person’s data. ProgramInterface.com implements the full interactive flow: authorization code + PKCE.
How the flow runs
- You send a request against a server whose provider is an OIDC user-login provider, and no valid token is cached.
- The app generates a PKCE verifier, derives the S256 challenge, picks
a random
state, and builds the authorization URL. - Your real browser opens at your identity provider. You log in there — with your password manager, your SSO, your hardware key, whatever you normally use. The app never sees your credentials.
- The provider redirects back to
http://localhost:<port><path>, where the app is running a loopback HTTP server for exactly this purpose. - The
stateis checked against what was sent (CSRF), the code is exchanged for tokens at the token endpoint with the original verifier, and the redirect server shuts down. - The access token is cached like any other, and the request that started all this goes out.
Everything after step 1 happens because you pressed Send — there’s no “log in” button to remember to press first.
Registering the redirect URI
Both the port and the path of the loopback redirect are configurable,
because identity providers require the redirect URI to be registered in advance
and every provider has opinions about what it will accept. The resulting URI —
http://localhost:<port><path> — is displayed in the provider form, ready to
copy into your IdP’s client configuration.
The authorization endpoint itself doesn’t have to be typed: it comes from
.well-known autodiscovery
alongside the token endpoint.
Cancelling
A browser login is the one part of sending a request that can hang indefinitely — wrong account, an SSO prompt you can’t satisfy, a tab you closed. While the login is pending the Send button becomes Cancel. Pressing it aborts the attempt and shuts the redirect server down cleanly, so the port is free and you can immediately try again.
Where it works
Catching the redirect means running a small server on your own machine, which the browser can’t do — so interactive login is desktop and mobile only. Every other part of the app behaves identically on the web.