Q08 proof · OAuth 2.0, OpenID Connect and authorization frameworks

8. OAuth 2.0, OpenID Connect and authorization

Answer as submitted

“Yes — OAuth2 (PKCE, client credentials) and OIDC/JWT with Entra ID, Keycloak and Auth0.”

Technical decision: expand. The submitted line names the protocols and providers but not the rules that make an implementation safe. This page is the separate, detailed version: it shows the flow per client type, the validation the API performs and the policy that decides access.

Expanded answer

Yes. Public clients use Authorization Code with PKCE and service-to-service calls use client credentials, both against an OpenID Connect provider — Microsoft Entra ID, Keycloak or Auth0 — discovered through its /.well-known/openid-configuration and JWKS endpoints. The API validates issuer, audience, lifetime and signature keys on every request instead of decoding a token and trusting it, authorization is expressed as policies over scopes and claims, refresh tokens rotate with reuse detection, and the hardening around it covers short lifetimes, CSRF/CORS strategy, secret management and audit logging.

Decision	Typical implementation	Why it is done this way
Public client flow	`response_type=code` + `S256` PKCE	No secret in the browser; an intercepted code is useless without the verifier.
Service-to-service	`grant_type=client_credentials`	No user context; a scoped token per calling service.
Token validation	Issuer + audience + lifetime + JWKS keys	A decoded token is never trusted; signatures are verified against published keys.
Authorization	Policy over scopes and claims	Least privilege is declared once and enforced everywhere, instead of role strings per endpoint.
Session longevity	Short access token, rotated refresh token	Limits the window of a stolen token; reuse detection revokes the family.
Hardening	CSRF/CORS allow-lists, secret vault, audit log	Closes the paths around the protocol itself.

Live identity workflow proof

The running component below changes its protocol/result view through real event binding. Select a step to see the exact request, what the security decision depends on, and the observable outcome.

AUTH WORKFLOWRUNNING

Choose an identity step

Select a step to inspect the protocol request, the reasoning and the result produced.

$ GET /authorize?response_type=code&code_challenge=<S256>&code_challenge_method=S256

The browser is sent to the identity provider with PKCE, so the client never sees the user credentials and an intercepted code is useless without the verifier.

302 → idp/authorize  ·  state + nonce bound to the session
code_challenge_method=S256  ·  redirect_uri exact match

How the implementation stays safe

Rules I apply. The flow follows the client type — PKCE for anything public, client credentials for service calls — tokens are short-lived and refreshed by rotation, and validation is centralised once at the composition root so no endpoint re-implements it. Authorization is a policy over scopes and claims with a resource-based check where ownership matters, and secrets live in Key Vault or Secrets Manager rather than in configuration files.

Boundary for Q08: this page covers the OAuth 2.0 and OIDC flows and the validation and authorization around them. Provider-specific tenant configuration, SSO federation with legacy identity stores and penetration-test remediation are separate topics.

Source files

Select a file to inspect the proof with syntax highlighting and line numbers. The first file is the code running the component above; the other two are the production shapes of the same decisions.

Acceptance criteria

Names OAuth 2.0 and OpenID Connect and the flow used by each client type.
Distinguishes authorizing, token exchange, validation, policy and refresh.
Shows an interactive proof of choosing a protocol step and reading its result.
Validates issuer, audience, lifetime and signature instead of trusting a decoded token.
Defers tenant configuration, legacy federation and pen-test remediation to a later topic.