Why Passwordless Alone Is Not an Identity Strategy
Why WebAuthn needs federation, recovery flows, and lifecycle design to become a real identity strategy
When teams adopt WebAuthn or FIDO2, the excitement is understandable:
No passwords.
No phishing.
No credential stuffing.
Biometric UX.
Public-key cryptography.
It feels like the final answer.
But WebAuthn answers exactly one question:
Can this device prove control of a credential for this origin right now?
It does not answer:
Who is this user across systems?
What happens if the device is lost?
How do we bootstrap identity?
How do we link accounts?
How do we recover?
How do we federate across institutions?
Passwordless authentication solves proof of possession.
Identity strategy solves continuity over time.
Those are different problems.
The Illusion of “Pure Passwordless”
It’s tempting to imagine a system that:
Only uses WebAuthn
Has no identity provider
Has no fallback
Has no recovery flow
On paper, that sounds maximally secure.
In reality, it’s brittle.
Let’s walk through real scenarios.
Scenario 1 — Device Loss
User registers WebAuthn credential.
All good.
Then:
Phone is lost.
Laptop is replaced.
Browser storage is cleared.
Now what?
Without fallback:
The account is inaccessible.
Support must intervene manually.
Or recovery becomes weak (email-only reset).
If recovery is ad hoc, security erodes.
If recovery is absent, usability collapses.
This is why fallback is not compromise — it is necessity.
Fallback Is a Design Requirement
Fallback should not mean:
“Use a weaker method.”
It should mean:
“Use an alternate trust anchor.”
In your architecture, that trust anchor was Feide (OIDC).
WebAuthn provided:
- Device-bound possession proof.
Feide provided:
- Federated identity continuity.
That layering is deliberate.
Passwordless Without Federation Breaks at Scale
In a real system:
Users change devices.
Users move institutions.
Accounts are deactivated upstream.
Identity policies change.
Without federation:
You must manage identity lifecycle yourself.
You must build account verification logic.
You must build secure recovery flows.
You must handle identity merging.
That is significantly more complex than integrating an IdP.
Enrollment Is Identity Design
Enrollment is often treated as a one-time setup.
It is not.
Enrollment defines:
Who is allowed to create a credential?
How is that identity verified?
What trust anchor validates the user at registration?
Example (ASP.NET Core + OIDC bootstrap):
var externalUserId = claims.FindFirst("sub")?.Value;
var user = await FindOrCreateUser(externalUserId);
if (!user.WebAuthnCredentials.Any())
{
return Redirect("/enable-passwordless");
}
Notice what happened:
OIDC verified identity.
Only then did WebAuthn credential get registered.
WebAuthn did not create identity.
It attached to it.
That ordering matters.
Recovery Is Where Identity Strategy Is Tested
The real test of maturity is not login success.
It’s failure recovery.
Lost device flow:
User authenticates via OIDC.
System validates
subclaim.Existing WebAuthn credentials are revoked.
New device registers fresh credential.
Example revocation logic:
_db.WebAuthnCredentials.RemoveRange(user.WebAuthnCredentials);
await _db.SaveChangesAsync();
Then redirect to registration.
This is structured recovery.
Without OIDC, you would need:
Email-only verification
Manual admin override
Or permanent account loss
None of those scale securely.
Device-Bound Authentication Is Not Portable Identity
WebAuthn credentials are bound to:
Origin
Device
RP ID
They are intentionally non-transferable.
That’s why they’re secure.
But identity is portable.
Identity must:
Survive device turnover
Integrate with external systems
Be recognized across services
That’s federation.
Federation Is Not the Enemy of Passwordless
There’s a misconception:
“If I use OIDC fallback, I weaken passwordless.”
That only happens when fallback bypasses verification.
In your architecture:
OIDC never created a session automatically.
Backend validated ID token.
Internal user mapping occurred.
HTTP-only cookie issued by your system.
OIDC proved identity.
WebAuthn proved possession.
The trust boundaries remained intact.
Architectural Maturity Means Layering
Let’s describe the trust model clearly.
Layer 1: Federation (Feide)
Asserts institutional identity
Manages upstream lifecycle
Provides recovery
Layer 2: Passwordless (WebAuthn)
Proves device possession
Phishing-resistant
Per-origin authentication
Layer 3: Session (HTTP-only cookie)
Server-controlled
Revocable
Protected from JS
Layer 4: Authorization
Application-level access control
Role management
Each layer solves a different problem.
No single layer replaces the others.
The Real Question
When designing authentication, the mature question is not:
“How do we eliminate passwords?”
It is:
“How do we design identity continuity over time?”
Passwordless improves authentication strength.
Federation ensures identity stability.
Together, they create resilience.
What Happens If You Ignore This
If passwordless stands alone:
Enrollment becomes fragile.
Recovery becomes weak.
Identity merging becomes manual.
Device loss becomes support nightmare.
Organizational integration becomes impossible.
The system becomes secure in theory, brittle in reality.
The Strategic Insight
Passwordless is a mechanism.
Identity strategy is a lifecycle.
Mechanisms can be secure.
Lifecycles must be resilient.
Your architecture works because:
It does not idolize passwordless.
It positions WebAuthn as primary.
It retains OIDC as structured fallback.
It treats recovery as planned, not emergency.
It separates identity from possession.
That separation is the mark of architectural maturity.
Final Reflection
Passwordless alone is not enough.
Not because it’s weak.
But because identity is larger than authentication.
A secure system must answer:
Who are you?
Can you prove it now?
What happens if you lose your device?
How do we recognize you tomorrow?
How do we integrate with your organization?
WebAuthn answers one of those questions exceptionally well.
Federation answers the rest.
Designing both — intentionally — is what turns passwordless from a feature into an identity strategy.
☰ Series Navigation
Core Series
Article 7 — A Real Passwordless PWA Flow (Architecture Walkthrough)
Article 9 — Integrating OIDC (Feide) as Fallback and Recovery
Optional Extras
→ Why Passwordless Alone Is Not an Identity Strategy
