OAuth, OpenID Connect and Authorization Code with PKCE

Separate the protocol jobs

OAuth delegates access to a protected resource. OpenID Connect adds identity assertions and an ID token for the client. A JWT is a possible token format; it does not define the flow.

Authorization Code with PKCE

1. The client creates a high-entropy code verifier and derived challenge.
2. The browser goes to the authorization endpoint with the challenge, state and an exact registered redirect URI.
3. The authorization server authenticates the user and returns a short-lived code.
4. The client sends the code and verifier to the token endpoint.
5. The client uses an access token intended for the resource API.

PKCE binds the authorization code to the initiating client. State binds the response to the browser transaction and helps defend against request forgery. They solve related but different problems.

Client categories

A public client such as a native app or browser application cannot safely keep a static client secret. A confidential server application can, but should still use strong client authentication and PKCE where supported.

For machine-to-machine calls, client credentials or workload identity can be appropriate because no human resource owner is involved. Use narrow scopes and prefer short-lived credentials or asymmetric authentication over widely copied secrets.

BFF trade-off

A backend-for-frontend completes the OAuth flow and holds access and refresh tokens server-side. The browser receives a secure cookie. This reduces token exposure to JavaScript but introduces cookie, CSRF, BFF availability and session-revocation responsibilities.

Red flags

• Access tokens in query strings.
• Wildcard or loosely matched redirect URIs.
• Implicit or password grants in a new design.
• ID tokens accepted by a resource API.
• Long-lived browser tokens stored where injected JavaScript can read them.

Strong answers explain why the chosen flow fits the client and threat model, not simply that it is the newest option.