Skip to content
AITroveRead. Build. Understand.
Reading list
Make this comfortable

ID Token Verification and Stable Account Identity

Last updated: 5 Oct 20268 min read
tutorial
IntermediateBy AITrove Editorial

An identity token is a signed assertion from a configured identity provider to a specific client. Its claims are input to a local account mapping only after cryptographic and contextual verification. The stable external key is the pair of issuer and subject. An email can change, be recycled, be absent, or carry different verification semantics across providers. Matching local accounts by email alone can hand one person another person’s history. The app still owns its own roles, tenant membership, and record permissions; external sign-in establishes identity, not a blanket grant to local resources.

Working case

The permit portal stores reviewer 47 under a verified work address. An external provider later returns that same address with a different subject for a new employee. Email auto-match would attach the newcomer to reviewer 47’s cases. The app instead searches the exact issuer-and-subject pair and finds no existing link. It offers an approved enrollment path without revealing whether the email owns an account. A separate token from the correct subject but intended for another client application also fails because its audience does not include this app. The name shown on the page may update; the subject key does not silently change.

Implementation boundary

javascript
function externalIdentityKey(verifiedClaims) {
  if (!verifiedClaims.issuer || !verifiedClaims.subject) throw new Error("Missing identity key");
  return JSON.stringify([verifiedClaims.issuer, verifiedClaims.subject]);
}
console.log(externalIdentityKey({ issuer: "issuer-6", subject: "reviewer-47", email: "[email protected]" }) === externalIdentityKey({ issuer: "issuer-6", subject: "reviewer-62", email: "[email protected]" }));
// Output: false

Use a maintained identity-token verifier for the configured issuer. Verify its signature against that issuer’s trusted keys and an allowed algorithm; reject a token that only decodes successfully. Require the exact issuer, expected audience, valid time window, and nonce when the flow sent one. Handle multi-audience client and authorized-party conditions according to the chosen protocol profile. Use the issuer and subject together as a unique database key. Treat email, display name, picture, and group claims as profile data requiring separate policy and freshness decisions. A successful verification may create or load a local account, but resource access still checks current tenant membership. Do not accept arbitrary key URLs or issuer metadata supplied by a browser request. Plan for provider key rotation without making signature failure a silent success.

Cost and boundaries

Cryptographic verification is effectively O(1) per token for fixed-size claims, plus cached-key lookup and occasional key-set refresh. A remote key fetch on every login increases latency and makes the app brittle during provider outages. A unique compound index on issuer and subject keeps account lookup efficient. Group claims can be large and stale; copying them into local authorization without a refresh rule creates hidden revocation delay. Measure verification failure categories, key-refresh behavior, duplicate-link attempts, and time from external membership removal to local denial. Keep diagnostic events coarse enough not to expose raw tokens or profile data.

Failure trace

Present a token with a valid-looking JSON body but no valid signature; reject it. Repeat with wrong audience, wrong issuer, expired time, and nonce from another tab. Change the email while keeping issuer and subject; the existing local account remains the same. Reuse the email with a new subject; no automatic account merge occurs. Rotate signing keys and confirm a valid new-key token succeeds only through trusted issuer key discovery. Remove a user’s local tenant membership after sign-in and verify access is denied even if the identity token remains valid.

Verification

  • Signature, issuer, audience, time, and flow nonce are verified by a trusted verifier.
  • Local mapping uses issuer plus subject.
  • Local record permission remains separate from sign-in.

Practice drill

Create two issuer configurations, two subjects that report the same email, and a local account for only one pair. Feed the verifier signed fixtures for correct and wrong audiences, expiry, nonce, and key rotation. Record the local account selected for each accepted token. Then remove case-47 access and try a direct case request with an active app session. Count account-mapping decisions and authorization decisions separately; a single “login passed” test misses the later boundary.

Decision note

Accept identity only from a verified issuer-to-client assertion, then apply local permission policy.

Common Mistakes

  • Parsing token JSON without verifying its signature.
  • Using email as the unique federated identity key.
  • Turning a provider group claim directly into permanent local access.

Related lessons

Federated Identity and Session Lifecycle; Authorization Code, PKCE, and Callback Binding; Refresh Token Rotation and App Session Boundary; Federated Account Linking, Logout, and Revocation; Object-Level Authorization for Reads and Writes; Passkey Registration Challenge and Credential Binding.

Apply and check

Build Project: federated permit reviewer sign-in and review Web Development: federated identity and session contracts quiz.

web-tech
web-development
Storage details