Validate a federation transaction, then create a local session deliberately

The problem federation solves — and the bill it sends you

Single sign-on is a user experience: one authentication session unlocks multiple applications. Federation is the trust arrangement and protocol through which an identity provider (IdP or OpenID Provider) makes assertions to a relying party (RP or SAML service provider). OAuth 2.0 delegates API authorization; OpenID Connect adds authentication and identity claims on top of it.

The pitch is that applications stop handling passwords. The bill is that every RP now validates cryptographic assertions from a party it doesn't control, maintains its own session policy, and owns local authorization anyway. A valid access token is not automatically an identity token, and neither protocol decides the application's local authorization policy.

What interviewers probe here: whether you think federation removes security work or moves it. A weak answer sounds like "we use SSO so we don't have to worry about auth" — that's the answer that fails the follow-up "so what does the RP still have to get right?" The strong answer names the RP's residual duties: assertion validation, session hardening, local authorization, lifecycle, and recovery from trust failure.

SAML end to end: actors, artifacts, and both ways in

SAML browser SSO involves four roles: the user agent (browser), the IdP, the SP (your application), and optionally an identity broker. The artifacts are the <Response> (a signed envelope) containing one or more <Assertion> elements. Two bindings carry them, and they differ in what the browser transports:

• HTTP POST binding: the IdP returns an auto-submitting HTML form to the browser, which POSTs the base64-encoded XML to your Assertion Consumer Service (ACS) URL.
• HTTP Redirect binding: the message is DEFLATE-compressed, base64url-encoded, and placed in a URL query parameter — the browser makes a GET. Because URLs end up in logs and Referer headers, the Redirect binding is typically used for the unsigned AuthnRequest, while the signed Response usually travels via POST.

SP-initiated SSO starts at your application: you generate an AuthnRequest with an ID, redirect the browser to the IdP, and the response comes back with InResponseTo matching that ID. IdP-initiated (unsolicited) SSO starts at the IdP with no outstanding request — no InResponseTo, and you must decide whether to accept unsolicited responses at all.

Interview filter: "walk me through what the browser actually carries in a SAML login." A weak answer stops at "the IdP sends a signed assertion." The strong answer traces the redirect chain and names the two bindings, because the binding determines what an attacker can tamper with in transit.

What must be validated on a SAML assertion, and why each check exists

Every check answers a specific attack:

• Signature against trusted metadata — otherwise anyone can forge assertions. Validate the signature over the assertion itself, and make sure the application consumes the same signed element it validated (XML wrapping attacks substitute a different assertion under a valid signature).
• Issuer — against your allowlist, not a string the token handed you.
• Audience restriction — the assertion must name your SP's entity ID, or it was minted for someone else.
• Recipient / ACS URL — the assertion must be delivered to the ACS it was issued for, defeating assertion injection into a different endpoint.
• InResponseTo for SP-initiated flows — binds the response to your request, defeating unsolicited login injection.
• SubjectConfirmationData with NotOnOrAfter** — the confirmation method is bearer, so the window must be short.
• NotBefore/NotOnOrAfter with bounded clock skew — replay and future-token attacks.
• Unique response/assertion IDs, tracked — replay detection; without an ID cache, a captured assertion works twice.
• Hardened XML parsing — no external entity resolution, strict schema, signature reference checking. XXE and wrapping are the two classic SAML CVE classes.

Likely follow-up: "what's the difference between validating the signature and validating the signed content?" If you can't explain wrapping attacks, you haven't done this in production.

OIDC as a layer on OAuth 2.0: the code flow with PKCE

OAuth 2.0 gives you delegated authorization: the client gets an access token for a resource server. OIDC adds the authentication layer: an ID token (a signed JWT) asserting who authenticated and when, plus standardized claims via the userinfo endpoint.

Prefer an RP-initiated authorization code flow with PKCE for new browser and native integrations. The browser carries a short-lived code; the client redeems it through the back channel and proves possession of a transaction-specific verifier. Bind the response to the initiating browser with state, and for OIDC add a nonce that lands in the ID token. Register redirect URIs exactly and reject open redirectors. Do not use implicit or resource-owner-password grants for new systems.

OIDC validation is allowlist-driven. Fetch configuration from a pinned HTTPS issuer, require the returned issuer to match exactly, and select supported algorithms deliberately. Validate the ID token signature with the issuer's current trusted key; validate issuer, audience, azp where applicable, expiry, issued time, nonce, and authentication requirements such as max_age/auth_time or requested assurance. Never choose an algorithm from an untrusted token (algorithm confusion), and never accept an access token where an ID token is required.

ID token vs access token — the distinction interviewers use as a filter

This is the single most common federation screening question, and it separates people who have shipped SSO from people who have read about it.

• ID token: audience is the client. It answers "who authenticated, when, for which transaction." You validate it, extract the subject, create a session — and then you're done with it. It is not a credential for APIs.
• Access token: audience is a resource server. It answers "what is the bearer allowed to do at this API." It proves nothing about a user session at your client.

The failure mode interviewers fish for: sending the ID token to an API as a bearer token, or treating an access token's presence as proof of login. A weak answer conflates them; a strong answer states the audience difference and adds that neither token decides your local roles.

Federation identifiers, account linking, and provisioning

Federation identifiers are contracts. Use the protocol subject identifier plus issuer as the stable external identity key; email is mutable, reusable, and often not globally unique. Account linking is high-risk: require proof of control of both identities or an explicitly trusted administrative workflow. Never merge merely because two providers return the same email. Map external groups or claims through a local allowlisted entitlement policy, deny-by-default for unknown values.

SSO is not lifecycle provisioning. Disabling an IdP session may prevent the next login, but an RP's existing session, refresh token, API token, cached authorization, or local account can remain active. Use SCIM or another governed lifecycle channel for create/update/deactivate, combined with short, risk-appropriate local sessions, token revocation where supported, event-driven invalidation, and periodic reconciliation. Just-in-time provisioning creates on login but does not provide timely deprovisioning.

Follow-up you will get: "the CISO says the user was terminated at 9:00; when does your app actually deny them?" If your answer is "at next login," that's a deprovision-to-deny latency gap you should be measuring.

Rotation, logout, and operational honesty

Key and metadata rotation must overlap safely. Cache discovery and keys with bounded refresh, refetch on an unknown key identifier subject to rate limits, retain old verification keys through the maximum valid token/assertion window, and reject unknown issuers or endpoints. For SAML, publish overlapping signing certificates in metadata and validate the exact metadata source. Emergency compromise requires invalidating trust, sessions, refresh tokens, and affected mappings — not merely uploading a new certificate.

Logout is not one atomic global operation. Local logout must invalidate the RP session first. Front-channel or RP-initiated federated logout can improve experience but may fail because of blocked frames, unavailable parties, or unrelated IdP sessions. Define what is guaranteed, validate post-logout redirects, and never claim one redirect revoked every downstream token. Step-up or forced reauthentication should use protocol controls and verified auth_time or assurance claims, not a fresh-looking browser redirect.

Clock skew and environment isolation are operational, not cosmetic. Bound assertion and token time windows to a documented skew, synchronize RP and IdP clocks independently of user devices, and refuse to widen the window to hide a failing time source. Separate production, staging, and partner registrations completely: a staging client secret, redirect, or ACS that accepts a production assertion is a mix-up waiting to happen.

Measure login success, validation-stage denials, mix-up and replay rejections, unknown-kid storms, deprovision-to-deny latency, and logout honesty — rather than treating a green IdP dashboard as proof that every RP session died.

The adversarial test list — and how interviewers turn it into follow-ups

Every item below is also a follow-up question in disguise. Interviewers who know this domain probe by naming an attack and asking what in your design stops it:

• wrong issuer/audience/recipient — "an assertion minted for your staging SP hits production; what rejects it?"
• expired and not-yet-valid assertions, clock skew — "your NTP drifts 90 seconds; what breaks first?"
• nonce/state mismatch, replay, duplicate assertion IDs — "the same login POST arrives twice; what happens?"
• code injection, PKCE downgrade, redirect confusion — "an attacker intercepts the redirect; what binds it to the victim?"
• algorithm confusion, unknown or rotated keys — "the token says alg: none or an unknown kid; what does your validator do?"
• XML wrapping, external entities — "the signature is valid but over a different assertion; do you notice?"
• IdP-initiated unsolicited responses, multi-IdP mix-up — "two IdPs are configured; which user just logged in?"
• account-link collision, deprovision delay, logout failure — "two providers return the same email; do you merge?"

A weak answer to any of these is a shrug toward "the library handles it." The strong answer names the specific check and where it's enforced. Federation removes password handling from each application; it does not remove the RP's duty to validate assertions, protect sessions, authorize locally, and recover from trust failure.