OAuth 2.0 Delegated Authorization

A client application should not receive Alice's password merely because it needs to call the supplier API. OAuth 2.0 is a framework for a resource owner or administrator to authorize a client to obtain bounded access; it does not by itself tell the client who Alice is.

Today you will trace an authorization-code flow with Proof Key for Code Exchange (PKCE), validate the access token at the API, and deny one wrong verifier or audience. Missing AUTH-R02 routes to Day 02 because the authorization server relies on an already bounded authentication session.

Northstar's supplier CLI needs supplier.read for atlas-api, not a reusable user credential or every Northstar permission. The outcome is AUTH-R03, a grant contract with normal, denied, unaffected-control, and cleanup evidence.

The client starts the request; the authorization server authenticates the resource owner and records consent or administrative grant; the API runtime is the resource server and owns final token validation plus domain authorization. PostgreSQL owns clients, grants, and revocation metadata; secrets never enter course fixtures.

The client creates a high-entropy verifier, sends its S256 challenge with exact client and redirect URI, then exchanges the returned one-time code with the verifier. The API validates signature or introspection result, issuer, audience, expiry, and required scope before its resource policy.

GET /authorize?response_type=code&client_id=supplier-cli&code_challenge=...&code_challenge_method=S256
POST /token grant_type=authorization_code&code=...&code_verifier=...
Authorization: Bearer <access-token>

RFC 9700 recommends modern OAuth security practice, including avoiding flows that expose access tokens in authorization responses and using PKCE protections. The API call consumes local process and network resources in this walkthrough; it cannot prove production issuer security. OAuth 2.0 Security Best Current Practice and PKCE, RFC 7636 are the primary references.

The unscored activity completes one valid code exchange, then changes only the verifier and separately presents a token for another audience while a valid token remains the control.

The scored check supplies the trace and asks one unknown: accept or deny this grant at the first failing boundary. Calling OAuth “login” triggers feedback that the client still lacks an identity assertion; Day 04 adds that separate layer. Declined candidates include password grants, implicit-flow trivia, production token minting, and multiple simultaneous token defects.

Record client, redirect URI, challenge method, code ID, grant ID, audience, scope, expected/observed result, denial code, environment, timestamp, immutable trace ID, and cleanup as AUTH-R03. Day 06 consumes it when Better Auth is considered as the authorization server.