Advanced
OpenID Connect

A · Hardening

• The validation edge cases that break in prod
• Audience wars — aud, azp, multi-audience tokens
• Pairwise / public subject identifiers
• PAR · JAR · JARM · request_uri
• FAPI 2.0 — what it actually requires
• mTLS · private_key_jwt · DPoP — beyond bearer
• Logout, properly — RP-initiated · back-channel · front-channel
• Token Exchange & on-behalf-of

The spec rule, plainly

• aud MUST contain the RP's client_id.
• If aud has more than one value, azp MUST be present and equal to the party who started this flow.
• If aud has more than one value and the RP is not azp, the RP MUST NOT trust the token as identity for itself.

Four guarded patterns

1. Single-aud only. Refuse multi-aud unless you have a specific reason. Most OPs let you turn this off.
2. If multi-aud, require azp and refuse if azp != my_client_id.
3. Distributed claims arrive in a different document fetched via _claim_sources — they have their own iss and aud, validate independently.
4. Aggregated claims are signed JWTs embedded in the ID token. Validate as if they were standalone tokens.

Two subject types

• public — the same sub for that user across every RP at the OP. Easy to correlate; suitable inside one trust boundary.
• pairwise — a per-RP pseudonymous sub. A user looks like a different identifier to every RP. Required for unlinkability (eIDAS, Apple Sign-In).

JAR — JWT-Secured Authorization Request (RFC 9101)

# the request object — a JWS (often signed with RP's
# private_key_jwt key)
{
  "iss":  "client_web_app",
  "aud":  "https://op.example",
  "response_type": "code",
  "client_id": "client_web_app",
  "redirect_uri": "https://app/cb",
  "scope": "openid profile email",
  "state": "X9d…",
  "nonce": "a7c…",
  "code_challenge": "e9k…",
  "code_challenge_method": "S256",
  "claims": { "id_token": { "acr": { "essential": true,
                                     "values": ["urn:mfa"] } } }
}

# delivered either as
GET /authorize?request=eyJhbGc…   (by-value)
# or referenced
GET /authorize?request_uri=https://rp/req/abc   (by-reference)
# (PAR is the formal "by-reference" mechanism — preferred)

FAPI 2.0 Security Profile (the baseline)

• Authorisation Code only — no Implicit, no Hybrid.
• PAR required for all requests.
• PKCE S256 required.
• Client authentication: private_key_jwt or tls_client_auth — no shared secrets.
• Sender-constrained tokens: DPoP or mTLS on every API call.
• Strict redirect_uri string match.
• Resource Indicators (RFC 8707) on every /par.

A private_key_jwt client assertion

POST /token HTTP/1.1
Host: op.example
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=AUTH&code_verifier=…&
client_id=client_web_app&
client_assertion_type=
  urn:ietf:params:oauth:client-assertion-type:jwt-bearer&
client_assertion=eyJhbGc…   ← the JWS

# decoded assertion
{ "iss":"client_web_app", "sub":"client_web_app",
  "aud":"https://op.example/token",
  "jti":"e1b7…", "iat":1800000000, "exp":1800000060 }

The exchange

POST /token HTTP/1.1
Host: op.example
Authorization: Basic base64(api_a:secret)
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange&

# the inbound token API A received from the user
subject_token=eyJ…   &
subject_token_type=urn:ietf:params:oauth:token-type:access_token&

# (optional) act-on-behalf-of identity
actor_token=eyJ…    &
actor_token_type=urn:ietf:params:oauth:token-type:jwt&

# what API A needs at API B
audience=https://api-b.example&
scope=invoices:read

# response — a token usable by API A to call API B,
# with both 'sub' (the user) and 'act' (API A) preserved
{ "access_token": "eyJ…",
  "issued_token_type":
     "urn:ietf:params:oauth:token-type:access_token",
  "token_type": "Bearer",
  "expires_in": 600 }

The architecture (in OIDC terms)

• PID Provider = OIDC OP issuing the citizen's Person Identification Data as a Verifiable Credential (often via OpenID4VCI).
• EUDI Wallet = a Self-Issued OP (SIOPv2) on the citizen's phone that holds the credentials and presents them on demand.
• Relying Party = the bank, employer, gov-service. Talks OpenID4VP to the wallet.
• Trust Framework = OpenID Federation 1.0 + EU-managed trust anchors (one per member state).

Two presentation modes

• In-person (18013-5) — over NFC or BLE. Wallet on phone, reader on the bouncer's terminal. No internet required. CBOR + COSE.
• Online (18013-7) — over the web. The bridge to OIDC: 18013-7 reuses OpenID4VP as its transport.

GitHub Actions → AWS

# GHA mints an OIDC token
permissions:
  id-token: write
steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123:role/deploy
      aws-region: eu-west-1

# AWS STS verifies via
# https://token.actions.githubusercontent.com/.well-known/jwks
# and assumes the role if the token's
# 'sub' = "repo:org/repo:ref:refs/heads/main"
# matches the role's trust policy

The claims request parameter

Most RPs accept whatever default claims the OP sends. The claims parameter (OIDC Core §5.5) lets you ask for specific claims, mark them essential, and even pin acceptable values.

POST /par
claims={
  "id_token": {
    "acr":           { "essential": true,
                       "values": ["urn:mace:incommon:iap:gold"] },
    "auth_time":     { "essential": true },
    "email":         null,
    "email_verified":{ "essential": true, "value": true }
  },
  "userinfo": {
    "given_name":  null,
    "family_name": null,
    "address":     { "essential": true }
  }
}

"Essential" lets the OP know "if you can't satisfy this, prompt the user / step up — don't silently issue a weaker assertion."

RP-side metrics

• oidc.token.validate.failure{reason} — labelled by signature, aud, iss, exp, nonce, kid, at_hash. Spikes in kid-failures = key rotation drama.
• oidc.jwks.refresh{outcome} — alert if more than 1 % of validations trigger a refresh.
• oidc.flow.duration_ms — quantiles by step (par · authorize · token · userinfo). Most outages first show as a token-endpoint p99 climb.
• oidc.refresh.reuse_detected — every event is a probable token theft.

What we covered

• Hardening — validation edge cases, aud/azp, pairwise subjects, PAR, JAR, JARM, FAPI 2.0, mTLS / private_key_jwt / DPoP, three logout specs, Token Exchange.
• Federation — OpenID Federation 1.0 trust chains, eIDAS 2.0 + EUDI Wallet, real-world ecosystems.
• Wallet-era — SIOPv2 + OpenID4VCI + OpenID4VP, ISO mDL, SD-JWT VC vs mDoc.
• Operational — workload OIDC (GHA / GCP / K8s), aggregated/distributed claims, MFA UX (prompt / max_age / acr_values / amr), observability, migration playbooks, domain reference architectures.