Prompt and context
You own the enterprise sign-in entry point for a multilingual site. Product wants the browser to offer an identity-provider account only after the user makes a clear choice, while privacy requirements prohibit relying on third-party cookies for tracking. Design the collaboration between the relying party (RP), identity provider (IdP), and server, including unsupported browsers, user denial, multiple IdPs, session creation, and sign-out.
What the interviewer is testing
A strong answer treats FedCM as a browser-mediated identity-federation interface, not as a replacement for token validation. The RP requests identity with navigator.credentials.get(), the browser presents account choices, and the IdP returns a short-lived assertion or authorization result. The server still validates the signature, issuer, audience, nonce, and state before creating a local session. The answer should also separate third-party-cookie limits, permission policy, user choice, and a traditional OAuth/OIDC redirect fallback.
Clarifying questions to ask first
Protocol and trust model
Confirm whether the IdP uses OAuth, OIDC, or a custom assertion, whether multiple IdPs are allowed, and how the server manages JWKS, issuer, and audience configuration. FedCM does not replace key rotation or token validation at the IdP boundary.
Browser and privacy requirements
Confirm target browsers, embedded iframes, enterprise policies, and the current third-party-cookie posture. FedCM support and UI behavior are browser-dependent; Chrome behavior cannot be assumed everywhere.
Account linking and logout policy
Confirm whether one external subject may map to one local account, how duplicate email addresses are handled, whether global logout must notify the IdP, and whether a denied request may fall back to password or email sign-in.
30-second answer framework
“I treat FedCM as a browser-controlled identity-choice layer. The RP obtains one-time state from its server, then calls navigator.credentials.get(). The browser presents an IdP account chooser, and the IdP returns a protocol-bound identity result. The server validates issuer, signature, audience, nonce, state, and account mapping before creating the site session. Unsupported browsers, permission blocks, cancellation, and server rejection are distinct states. The fallback is OAuth/OIDC with CSRF protection and PKCE. Sign-out must distinguish the site session from the IdP session; clearing one cookie is not global logout.”
Step-by-step deep answer
Step 1: Configure the RP and IdPs
The server stores issuer, client ID, JWKS endpoint, allowed protocol, and callback policy for every trusted IdP. The frontend receives only a server-approved configuration identifier and never accepts an arbitrary IdP URL from the user. For multi-tenant deployments, bind an allowlist to each tenant to prevent open redirects or cross-tenant token delivery.
Step 2: Create one-time login state
After the user starts sign-in, the RP server creates unpredictable state, nonce, and a short-lived flow record bound to the browser session, tenant, and return path. The frontend sends server-provided parameters to FedCM. State and nonce remain server-owned, single-use values; the frontend must not mint or reuse them.
Step 3: Make the browser-mediated request
The frontend calls navigator.credentials.get() in a secure context and under the required permission policy. The browser presents an account chooser and continues only after explicit user selection. FedCM requests carry a dedicated fetch destination so the server can identify the identity flow; the frontend must not treat the appearance of UI as authentication success.
Step 4: Validate the identity result on the server
The server checks issuer, signature, expiry, audience, nonce, state, and subject, then maps the external identity using an explicit policy. Email is an auxiliary attribute, not an automatic account-merge key. Only after validation does the server issue the site session and record the IdP, subject, authentication time, and relevant risk signals.
Step 5: Design fallback and failure states
Unsupported browsers, permission blocks, user cancellation, and network failures need separate handling. An OAuth/OIDC redirect fallback uses PKCE, an exact redirect URI, state, and nonce; it returns through the same server-side account-mapping layer. The UI explains the next action without exposing issuers, tokens, or internal validation errors.
Step 6: Handle multiple IdPs and account linking
When several IdPs are allowed, the page presents a business-approved list and the browser and IdP complete account selection. The server uses (issuer, subject) as the stable external key and never silently merges by email alone. Adding an IdP requires an authenticated session or step-up verification and produces an auditable link or unlink event.
Step 7: Logout, revocation, and gradual rollout
Site logout revokes the local session, clears secure cookies, and invalidates refresh tokens; if the protocol and IdP support it, the client can also invoke IdP logout. FedCM may not cover every cookie-dependent logout capability, so explain the difference between signing out of the site and signing out of the provider. Roll out by browser capability and error rate with an observable fallback switch.
High-quality sample answer
I would separate browser identity choice, IdP proof, and RP session creation. The RP server creates short-lived state, nonce, and tenant-bound flow data. The frontend starts FedCM in a secure context; the browser shows the account chooser, and the IdP returns a result after user confirmation. The server validates the issuer’s JWKS signature, audience, nonce, state, expiry, and subject, then maps (issuer, subject) to a local account before creating a site session.
Unsupported browsers, policy blocks, cancellation, and network failures remain separate states and fall back to OAuth/OIDC with PKCE. The fallback keeps the same server validation and linking policy. Multiple IdPs come only from a server allowlist, and email is not an automatic merge key. Logout revokes the site session; provider logout is a separate capability explained to the user. During rollout I would monitor success, cancellation, fallback, and account-link conflicts by browser and IdP, with a switch that disables only the FedCM entry point if errors rise.
Common mistakes
- Mistake: Treating the FedCM result as an authenticated session. → Why it fails: Browser-mediated choice does not validate issuer, signature, or nonce. → Fix: Send every result through one server validation and session-creation path.
- Mistake: Matching an existing account only by email. → Why it fails: Email may be unverified, recycled, or duplicated across IdPs. → Fix: Use
(issuer, subject)as the external key and require explicit confirmation for email-based linking. - Mistake: Storing a token in frontend storage after FedCM fails. → Why it fails: It expands XSS exposure and bypasses the existing session policy. → Fix: Let the server exchange the result and set a protected session cookie; the frontend handles status only.
- Mistake: Assuming site logout logs the user out of the IdP. → Why it fails: The sessions have different lifecycles and protocol capabilities. → Fix: Revoke each session separately and communicate the scope of logout.
Follow-up questions and answers
Follow-up 1: How does FedCM relate to an ordinary OAuth redirect?
FedCM changes how the browser mediates account choice and cross-site interaction; OAuth/OIDC still provide authorization and identity proof. They can share issuer, nonce, state, PKCE, and server-side account mapping. A fallback must not remove those checks.
Follow-up 2: Why do third-party-cookie restrictions affect federation?
An embedded IdP may previously have used a third-party cookie to recognize a signed-in user. Partitioned or blocked cookies require an explicit, user-visible choice instead. FedCM reduces implicit cross-site recognition but does not decide application permissions.
Follow-up 3: Can a denied IdP be silently replaced with another?
Do not treat denial as silent consent. Offer another approved IdP or password entry as an explicit user action, and create fresh state, nonce, and flow data for the selected provider instead of reusing a completed request.
Follow-up 4: How do you prove a gradual rollout did not hurt sign-in?
Segment success, cancellation, policy-block, fallback, account-conflict, and completion-time metrics by browser, IdP, region, and embedding context. Alert on issuer anomalies, signature failures, and nonce replay. Keep a server switch that disables only FedCM while leaving the established OAuth validation path intact.