Federated Login Callback Boundary

A federated sign-in callback is not a trusted account assertion merely because it contains a code or an email address. The application begins the flow with an unpredictable state value tied to the initiating browser session; a public browser client also uses an authorization-code flow with PKCE. On return, it verifies state, exchanges the code through the registered redirect route, and validates the identity token through a maintained protocol client: issuer, audience, signature, expiry, and nonce where used. Only then does it map the external subject to a local account. Email can change and is not a safe universal key for joining accounts. The short predicate below checks local callback binding only; it intentionally does not parse or verify tokens, which belongs to a vetted protocol implementation.

Working case

Reviewer 29 starts sign-in to open case 47. The server stores a short-lived state and nonce for that browser session, then redirects to the identity provider. An attacker sends the reviewer a callback link from a flow the attacker started elsewhere. The callback's state does not match the pending session and must be rejected before any local account is created. A valid callback still needs code exchange and identity-token verification. After mapping the provider's stable subject to reviewer 29, the application issues its own session and applies case-level permission as usual.

Implementation boundary

import { timingSafeEqual } from "node:crypto";
function acceptCallbackBinding(callbackState, pendingLogin) {
  if (!pendingLogin || pendingLogin.expiresAt <= Date.now()) return false;
  if (typeof callbackState !== "string" || callbackState.length < 24) return false;
  const received = Buffer.from(callbackState);
  const expected = Buffer.from(pendingLogin.state);
  return received.length === expected.length && timingSafeEqual(received, expected);
}

Cost and boundaries

A redirect adds network hops and may depend on an external provider's availability. Pending state and nonce records consume short-lived storage; cleaning them on success and expiry limits replay and memory growth. Token signature verification has CPU cost and key-cache behavior that a maintained client can manage. Repeated callback failures need careful logging without copying codes or tokens into logs. Plan a sign-in outage message that leaves public pages readable rather than turning every route into a blank screen.

Failure trace

A callback handler trusts the email value in an unverified token and attaches it to an existing account. The attacker supplies a forged token with the victim's email and gains the victim's case list. Another handler accepts a valid code from a different browser because it never checks state. Both faults cross the identity boundary. Reject a mismatched or expired pending flow, let a maintained client validate protocol tokens, and map accounts by provider and stable subject rather than by display email alone.

Verification

Start two login flows in different browser sessions and swap their callbacks; both swaps must fail.
Reject a token with the wrong issuer, audience, nonce, signature, or expiry in protocol-client tests.
Change an external account's display email and confirm it does not silently become another local account.

Decision note

Federation delegates credential verification, not local authorization. The application still owns session lifecycle, account mapping, and each protected record decision.

Common Mistakes

Do not trust callback query fields as proof of identity.
Do not join accounts by an unverified or mutable email alone.
Do not omit state, PKCE, or identity-token validation from the chosen flow.

Connected lessons

Identity and Application Security; Password Verification and Login Budgets; Account Recovery and Session Revocation; Outbound URL Requests and SSRF Boundaries; Sessions and CSRF: keep identity on the server; Authorization: check permission for this record on every request; URLs and origins: separate location, query, and fragment; Environment Configuration and Secret Boundaries.

Apply and check

Build Project: account access and recovery boundary and review Web Development: identity and integration contracts quiz.

Further connections

Federated Identity and Session Lifecycle; Authorization Code, PKCE, and Callback Binding.