Adding another sign-in provider to an existing account is a sensitive account change. It should start from a current authenticated app session, require deliberate user intent, and complete through a fresh verified provider callback. The newly verified issuer-and-subject pair must be unique across local accounts. A matching email is not consent to merge histories. Unlinking can strand a user without a recovery method, so policy must confirm another usable sign-in path before removal. Logout is similarly layered: clearing an app session does not necessarily end the identity provider’s browser session or revoke every issued token.
Federated Account Linking, Logout, and Revocation
Working case
Reviewer 47 wants to add a second work identity. A different reviewer, 62, already has an account with the same email alias at that provider. The link flow returns a verified subject belonging to reviewer 62. The portal refuses to move or merge it automatically and records a safe conflict without revealing the other account’s cases. Later reviewer 47 signs out while the provider still has an active browser cookie. The app invalidates its own session and clears account-scoped private UI state immediately; if the product supports provider logout, it initiates that distinct protocol and explains that other provider sessions or devices may remain.
Implementation boundary
function mayLinkIdentity(activeAccountId, ceremony, externalIdentity) {
return ceremony.accountId === activeAccountId && !ceremony.consumed &&
externalIdentity.verified && !externalIdentity.ownerAccountId;
}
console.log(mayLinkIdentity(47, { accountId: 47, consumed: false }, { verified: true, ownerAccountId: 62 }));
// Output: falseBegin linking only after recent app authentication where risk warrants it. Store the target local account ID, initiating session, provider issuer, state, verifier, and expiry in one-use server state. On callback, verify the identity assertion, then inside a transaction enforce uniqueness of the issuer-and-subject pair and confirm the initiating app account is still current. Require a user-facing confirmation before changing the account’s sign-in methods. Log a minimal audit event without raw tokens. On unlink, check for another usable credential or a defined recovery path, then revoke sessions if policy requires it. For logout, invalidate the local server session and clear private browser state regardless of whether remote logout succeeds. Provider-wide sign-out or token revocation needs supported endpoints and separate success reporting.
Cost and boundaries
A unique link lookup is O(log N) with an index over N external identities; transaction cost is small relative to the damage of a wrong merge. Recent-authentication prompts add friction and should match account risk. Calling provider logout or revocation adds network latency and may be unavailable or partial, so local session invalidation must not wait for it. Audit and notification retention carry privacy costs. Measure link conflicts, abandoned ceremonies, last-method unlink denials, local sign-out-to-denial time, and remote logout failures without retaining subject identifiers in broad analytics.
Failure trace
Start a link flow from reviewer 47, sign out, then complete its callback under reviewer 62’s session; reject it. Try to link an issuer-and-subject pair already owned by another local account; the unique constraint and application response must both block the merge. Attempt to unlink the last usable method and require a recovery decision. Force remote logout to time out while local logout succeeds; private case requests still fail. Use the browser back button after logout and confirm cached case content does not appear as an active signed-in page.
Verification
- Linking is bound to a current app session and fresh provider assertion.
- An external subject cannot belong to two local accounts.
- Local logout denies access even if provider logout fails.
Practice drill
Create local accounts 47 and 62. Give them the same email alias but different provider subjects, then try to link reviewer 62’s subject to account 47. Verify conflict handling and that neither account’s case list changes. Complete a valid link from a fresh session, sign out, and simulate provider logout failure. Retry a protected request, a restored page, and an old tab. Remove the linked identity only after confirming another usable credential. Record what local and remote logout each actually achieved.
Decision note
Account links require verified identity and current local intent; logout reports only the sessions it actually ended.
Common Mistakes
- Auto-merging accounts because their emails match.
- Leaving a stale linking callback valid after account switch.
- Claiming local logout revoked every provider session.
Related lessons
Federated Identity and Session Lifecycle; Authorization Code, PKCE, and Callback Binding; ID Token Verification and Stable Account Identity; Refresh Token Rotation and App Session Boundary; Account Recovery and Session Revocation; Browser Storage Cleanup on Account Change.
Apply and check
Build Project: federated permit reviewer sign-in and review Web Development: federated identity and session contracts quiz.
