OpenID Connect Federated Identity

OAuth can authorize a client without giving that client a standard statement about the authenticated user. OpenID Connect (OIDC) adds an identity layer: an OpenID Provider authenticates a subject and issues an ID token to a registered relying party. The ID token describes that authentication event to its client; it is not an API access token.

Today you will validate issuer, audience, signature, expiry, nonce, and stable subject for one Northstar login, then reject a wrong issuer while an unrelated valid login remains healthy. Missing AUTH-R02 routes to Day 02.

The HelixWorks browser needs a durable (issuer, subject) identity link without joining users by mutable email or importing upstream groups as permanent authorization. The result is AUTH-R04, a federation contract consumed by SCIM and Better Auth days.

The corporate OpenID Provider owns upstream authentication. The HelixWorks runtime is the relying party and owns its session and internal identity link. Its API remains a resource server with separate access-token and policy checks. PostgreSQL owns links and sessions; the provider owns credentials and signing keys.

Fetch discovery metadata from the configured issuer, select a trusted key, and validate the ID token against the exact relying-party client and request nonce. Join the internal user on issuer plus sub; treat email and group claims as profile or inputs to current owner state.

{
  "iss": "https://idp.example.com",
  "sub": "00u-stable-subject",
  "aud": "helixworks-web",
  "nonce": "request-bound-value",
  "exp": 1786700000
}

OpenID Connect Core 1.0 incorporating errata set 2 defines the ID token and relying-party validation model. The local JSON inspection proves only the exercise's comparisons, not provider authenticity or production key custody.

The unscored activity validates one assertion, swaps only the issuer, and then presents the original ID token to the supplier API as though it were an access token. Both substitutions must deny while the original relying-party login succeeds.

The scored check supplies every claim except one decision: is this assertion valid for this relying party? Using email as the stable identity or ID token as API permission triggers a targeted issuer/subject/audience replay. Declined candidates include SAML implementation, provider-product comparison, group-to-role auto-grants, and production federation claims.

Record issuer, subject reference, client ID, nonce result, key ID, session ID, expected/observed result, denial code, unaffected control, environment, timestamp, and immutable trace ID as AUTH-R04. Day 05 uses the identity link for lifecycle reconciliation; Day 06 uses it for issuer-role design.