Topic starter
16/08/2026 1:12 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Descope: “Add Passkeys to Firebase / GCP Identity Using Descope”.
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.
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.
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.
Practitioner guidance
- Require verified first-login binding Make email or phone verification mandatory before a new passkey can be associated with an existing user record.
- 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.
- 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.
Bottom line: Passkeys do not remove identity governance requirements, because the real risk sits in how the new factor is bound to an existing account.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
16/08/2026 1:14 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Passkeys in Firebase and GCP change account linking assumptions