Separate API Authority from Login Identity

Day 04 produced an OAuth grant for a protected resource. OpenID Connect (OIDC) adds an identity layer to OAuth: an ID token lets a relying party validate an authentication event, while an OAuth access token carries authority intended for a resource server. Mixing the two can send an identity assertion to an API that was never its audience.

Today you will validate supplied OIDC claims at the browser client boundary and prove that the ID token cannot authorize the Calendar API. This is a standards-grounded boundary exercise based on OpenID Connect Core and Discovery; it does not claim to implement a complete relying party.

The browser callback retrieves the selected issuer's keys and applies a supplied validation checklist: signature, exact issuer, client audience, expiry, issued-at constraints, and nonce bound to the login transaction. A valid result may establish local signed-in context; it does not choose API scopes or bypass resource policy.

{
  "issuer": "https://auth.example",
  "audience": "calendar-browser",
  "nonce": "nonce-d06",
  "expiresAt": "2026-08-14T12:05:00Z",
  "validationPurpose": "login_identity"
}

{
  "idTokenRecipient": "calendar-browser",
  "accessTokenRecipient": "https://calendar.example/mcp",
  "refreshTokenPurpose": "renew_delegated_access",
  "interchangeable": false
}

The normal path validates the ID token at the browser and sends the access token to the Calendar API. The first denial changes only the ID-token audience; the browser rejects it. The second sends a valid ID token to the API; the API rejects it because it is not the required access credential.

GET /v1/events HTTP/1.1
Host: calendar.example
Authorization: Bearer <access-token-for-calendar-resource>

{
  "receipt": "SCG-R06",
  "identity": "accepted_for_calendar-browser",
  "wrongAudience": "denied_at_browser",
  "idTokenAtApi": "denied_wrong_token_purpose",
  "accessTokenAtApi": "accepted"
}

Recovery starts a fresh login transaction with a new nonce; it does not reinterpret the rejected token. The Day 01 public route remains the positive control. Cleanup removes the disposable browser session and retains only the claim-validation receipt with no raw token.

Given token type, issuer, audience, recipient, and desired action, decide only accept or deny at the named boundary. An ID token whose audience is the browser may be accepted for login context there; it is denied at the Calendar API. The one-dimensional evidence is decision plus failed check.

The misconception is “OIDC token means OAuth API token.” Replay the same valid ID token at both boundaries to reveal that validity includes intended recipient and purpose. Decline role inference, tenant policy, or a full relying-party implementation because those are separate capabilities.

SCG-R06 records each artifact's purpose, recipient, lifecycle, valid path, and one-variable denials. Day 07 consumes the access-token reference, never the ID token, when constructing secret-safe REST and MCP upstream requests.