Notifications
Clear all
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.
NHIMG editorial — based on content published by Descope: Add passkeys to Firebase / GCP Identity using Descope
Questions worth separating out
Q: How should security teams prevent passkey enrollment abuse in federated login flows?
A: Security teams should require proof of account ownership before allowing a new passkey to be attached, and they should log enrollment as an identity lifecycle event.
Q: Why do passkey and password coexistence models create account governance risk?
A: They create risk because the same person can arrive through multiple authentication paths, which can produce duplicate records or ambiguous ownership if linking is not deterministic.
Q: What breaks when same-email account linking is not tightly controlled?
A: You get split identities, overwritten credentials, or a merge that does not reflect the true account owner.
Practitioner guidance
- Treat passkey enrollment as a privileged identity event Require verified email or phone ownership before any new passkey can be bound to an existing account, and log the enrollment as an auditable identity change.
- Test account-linking collisions before production rollout Simulate same-email sign-ins across password and OIDC paths, then validate the exact linkWithCredential behaviour and resulting user record state.
- Define one authoritative account resolution rule Decide whether FirebaseUI or a custom SDK flow owns identity merging, and make the merge rule deterministic for duplicate identities.
What's in the full article
Descope's full blog covers the implementation detail this post intentionally leaves for the source:
- Step-by-step Firebase console configuration for OIDC provider setup and redirect handling
- Sample React and FirebaseUI code for building the passkey login path
- Manual SDK account-linking logic using linkWithCredential for duplicate-email cases
- Practical flow design notes for first-login verification and passkey enrollment
👉 Read Descope's tutorial on adding passkeys to Firebase and GCP Identity →
Passkeys in Firebase and GCP: are your account-linking controls ready?
Explore further
16/08/2026 1:14 pm
Passkey rollout is an account-binding governance problem, not just an MFA upgrade. The article shows that stronger authentication still depends on who is allowed to bind a new factor to an existing identity. In human IAM, the failure mode is not weak cryptography but weak enrollment governance. Teams should treat passkey enrollment as a controlled identity event, not a user preference setting.
A few things that frame the scale:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable for passkey binding and recovery decisions in a federated IAM flow?
A: The IAM owner is accountable for defining the rules, while application teams are accountable for implementing them consistently. Federated authentication does not transfer governance responsibility to the identity provider. It only changes where the control is enforced and where the audit evidence must be collected.
👉 Read our full editorial: Passkeys in Firebase and GCP change account linking assumptions
