TL;DR: The tutorial shows how to add passkeys to Firebase and GCP Identity through an OpenID Connect flow, according to Descope, then link accounts so password and passkey sign-ins resolve to one user record. The security issue is not the login button but the account-linking and first-login verification logic that prevents credential binding abuse and duplicate identities.
At a glance
What this is: This tutorial shows how passkeys can be integrated into Firebase and GCP Identity with OIDC, and why first-login verification and account linking determine whether the resulting identity model stays trustworthy.
Why it matters: IAM teams need to treat federated passkey onboarding as an account-binding and identity-proofing problem, because the wrong merge logic can create duplicate users or let a passkey attach to the wrong account.
Context
Passkeys change the authentication method, but they do not remove the need to prove which account a user is entitled to bind to. In Firebase and GCP Identity, the governance gap appears at account linking, where an OIDC-based passkey flow can create duplicate identities or overwrite existing provider credentials if the merge logic is weak.
The article’s core message is that the security decision happens at first login, not at the button labelled Sign in with Passkeys. That makes identity proofing, account merge policy, and redirect handling part of the access-control design, not just the login experience.
Key questions
Q: What breaks when passkey account linking is not configured in Firebase?
A: Without account linking, the same person can end up with separate user records for password and passkey sign-ins, or one provider may overwrite the other. That breaks auditability, offboarding, and access reviews because the identity record no longer represents a single authoritative account state.
Q: Why do passkey onboarding flows need first-login verification?
A: Because the first login is the point where a new authenticator becomes attached to an account. If the user’s entitlement is not verified at that moment, an attacker can attempt credential binding abuse by linking their own passkey to someone else’s identity record.
Q: How can teams tell whether federated sign-in is creating duplicate identities?
A: Watch for the same email address appearing under multiple providers, users losing access to previously linked methods, or the same person receiving different user IDs depending on sign-in path. Those are signs that linking logic is incomplete or provider precedence is undefined.
A: Both, but the governance part is usually the one that fails first. Passkeys improve the login factor, yet the real risk sits in identity proofing, linking policy, and account lifecycle handling, especially when federated providers share or replace credentials.
Technical breakdown
How OIDC passkey flows federate into Firebase and GCP Identity
In this integration pattern, an external identity provider handles the user authentication ceremony and Firebase or GCP Identity stores the resulting user record and JWT-based session state. OIDC sits on top of OAuth 2.0 and lets the application trust an authenticated assertion from the provider rather than re-implementing local credential checks. Passkeys add MFA by binding a user to a device and a biometric or other inherence factor, but the trust boundary still shifts through federation. That means the important control is not the passkey itself, but the claims, redirects, and account-binding logic around it.
Practical implication: validate the federation path and account-binding rules before exposing passkeys to production users.
Why first-login verification controls passkey enrollment risk
The blog’s design relies on verifying the user by email or phone the first time they arrive through the flow. That verification step is what prevents a malicious actor from attaching a new authentication method to someone else’s account. Without that check, a passkey becomes a credential-binding mechanism as much as an authentication mechanism, because the system may accept a valid login ceremony while still linking it to the wrong identity record. In identity governance terms, enrollment and binding must be treated as one control point, not two separate features.
Practical implication: require verified first-login binding before allowing passkey enrolment for any existing account.
How duplicate user records emerge during account linking
When Firebase links identities that share an email address, the platform may merge federated and password-based sign-ins into one user record. If that linking is not configured, the application can create two records for the same person or preserve only the last provider used. The article also notes that, in federated linking, the original Firebase credential can be replaced by the federated credential, which changes how the account behaves on later password sign-ins. The technical risk is not merely duplication; it is unintended identity precedence.
Practical implication: test provider precedence and linking behaviour before rollout so duplicate identities do not become a production normal.
Breaches seen in the wild
- Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Passkey deployment in Firebase exposes an account-binding control problem, not an authentication novelty problem. The authentication factor may be stronger, but the identity lifecycle decision still depends on whether the system can prove the user is entitled to bind that factor to the target account. In practice, the security boundary moves to first-login verification and merge logic. Practitioners should treat passkey onboarding as part of identity governance, not as a front-end feature change.
Verified enrollment is the control that separates legitimate passkey adoption from credential-binding abuse. The article’s requirement to verify email or phone on first login is doing governance work, because it stops an attacker from attaching a passkey to an account they do not own. That is the decisive point for IAM teams: if binding can happen before proof of entitlement, the authentication method becomes an account takeover enabler rather than a defence.
Duplicate identities are a governance failure mode, not just a user-experience defect. When password and federated passkey sign-ins can create separate records, access reviews, audit trails, and offboarding all become less reliable because the same person may now exist in more than one state. The named concept here is identity binding drift: the account relationship changes faster than the governance model tracks it. Practitioners should assume every linking path creates audit consequences.
Federated passkey flows change credential precedence, which means lifecycle controls have to be tested at the merge layer. The article shows that once OIDC is used for linking, provider ordering and linking behaviour can alter which credential remains active. That matters for IAM teams because account recovery, reauthentication, and revocation all depend on knowing which credential currently owns the identity record. The practical conclusion is that binding precedence is an access-control design choice, not an implementation detail.
Passkeys in Firebase and GCP are a reminder that identity assurance lives in the transition, not just the factor. The industry often treats passkeys as a phishing-resistant endpoint, but in federated deployments the highest-risk moment is the handoff between authentication, account linking, and user record creation. That transition deserves explicit policy, logging, and review. Practitioners should evaluate the merge path with the same rigor they apply to authentication itself.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- Read next: NHI Authentication Guide
What this signals
Identity binding drift: passkey adoption in federated apps can outpace the governance model that decides which credential owns the account. If account linking is loose, the programme can end up with duplicate identities, inconsistent recovery paths, and revocation ambiguity that security teams will only notice after support escalations or audit review.
For IAM teams, the practical lesson is to move passkey governance left into enrollment, not leave it in application support. That means defining binding rules, logging provider precedence, and making sure lifecycle actions apply to the merged account rather than to whichever login method happened to be used last.
For practitioners
- Require verified first-login binding Make email or phone verification mandatory before a new passkey can be associated with an existing user record. This reduces the chance that a malicious actor can bind a valid authenticator to the wrong account during the first federated login.
- Test account-linking precedence Validate what happens when a user signs in with password first, then with an OIDC passkey flow, and reverse the sequence as well. Confirm whether the same user ID persists and whether the original credential remains active or is replaced.
- Review duplicate identity handling Check whether your Firebase configuration creates separate records for the same email under different providers, and decide whether automatic linking is enabled. Duplicate records undermine offboarding, auditability, and access certification.
- Instrument redirect and callback paths Log the redirect target, provider selection, and linking outcome so you can detect failed OIDC handoffs and unexpected provider switches. The control gap often appears in the transition between the login page and the federated callback.
- Document provider precedence rules Define which credential source wins when password and federated sign-ins collide, and make that rule visible to support and identity teams. Without explicit precedence, troubleshooting and account recovery become inconsistent.
Key takeaways
- Passkeys do not remove identity governance requirements, because the real risk sits in how the new factor is bound to an existing account.
- The article shows that first-login verification and account linking decide whether a federated passkey flow strengthens or weakens account integrity.
- Practitioners should test merge behaviour, duplicate identity handling, and provider precedence before rolling passkeys into production.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article focuses on federated passkey authentication and first-login proofing. |
| NHI-10 — Human Use of NHI | The flow lets people use passkeys as authenticators for managed accounts. | |
| Recommendation — Verify entitlement before binding a new passkey and log every federated login path. Govern how humans enroll and reuse passkeys so account ownership stays explicit. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle and linking behavior are central to the account-binding problem. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | The article concerns external user authentication through federated identity. | |
| Recommendation — Apply authenticator management controls to enrollment, linking, and replacement events. Use external-user authentication controls to validate federated identities before account creation. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Linking decides which account entitlements survive the sign-in transition. |
| Recommendation — Review entitlement assignment whenever identity providers are linked or replaced. | ||
| NIST SP 800-63 | SP 800-63B — Authentication | Passkeys and first-login verification are authentication and binding concerns. |
| Recommendation — Treat passkey onboarding as an authentication event with explicit binding assurance. | ||
Key terms
- Account linking: Account linking is the process of tying multiple login methods or sessions to one user profile so the same person does not become several separate records. In consumer IAM, it preserves identity continuity across email, social login, device handoff, and guest-to-registered transitions.
- Identity Binding: The process of linking an external credential or login method to an internal account record. Strong binding prevents duplicate accounts, broken recovery paths, and unsafe merges when users authenticate through different identity sources or wallet-based credentials.
- Federated Identity: Federated identity lets one organisation trust an external identity provider so a user can access another service without creating a separate account. It simplifies access, but it also expands the trust relationship that must be monitored. Weak federation settings can turn a single compromise into cross-domain access.
- Credential Precedence: Credential precedence is the order a client uses to decide which secret or token to trust when more than one is present. In practice, a higher-priority variable, cached login, or settings block can override the intended value, which makes silent misrouting and unintended billing a real operational risk.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 16, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org