Self-Hostable Passkey Login Service with Safe Account Recovery for Small Apps

The problem small apps have with login

Passwords get phished, reused and stuffed. SMS codes get intercepted through SIM swap. Passkeys solve most of this: the private key never leaves the user's device and the browser only uses it on the real site, so a lookalike domain gets nothing. Major platforms now support them.

Small products, such as a school fee portal, a clinic booking app or a fintech startup's dashboard, rarely offer passkeys. The hosted identity providers that do are priced per monthly active user, which becomes painful as a consumer app grows. And every team that tries passkeys hits the same wall: what happens when the user loses their phone? If recovery is "click the email link", the account is only as safe as the email.

What already exists and the gap

• Auth0 and Clerk: hosted identity with passkey support, easy to integrate, priced per active user, with data held by the vendor.
• Hanko: an open source, passkey-first identity service that can be self-hosted under the AGPL.
• Corbado: a passkey specialist layer focused on adoption and recovery tooling on top of an existing identity provider.
• Keycloak: open source identity with WebAuthn support, powerful but heavy to run and configure for a small team.

The gap this project targets is less "another passkey server" and more recovery done carefully and documented: a small, understandable service where the recovery design, the step-up rules and the threat model are the product, and a small team can read every line.

What you build

Roles: end user, app developer (integrates via OpenID Connect), app admin.

1. Sign-up: user creates an account and registers a passkey. The service prompts them to add a second passkey or save recovery codes before they leave.
2. Sign-in: passkey with conditional UI (autofill), falling back to a recovery path only when needed.
3. Recovery: with recovery codes, immediate. With email only, a waiting period (for example 24 hours) during which every registered device and the email are notified and can cancel.
4. Step-up: after recovery or on a new device, sensitive actions in the client app (changing payout details, adding a new passkey) require extra verification.
5. Admin: view and revoke authenticators, see an audit trail of sign-ins and recovery.

The technically interesting part

The engineering centre is the recovery and step-up state machine. Each account has states such as normal, recovering, recently recovered, and locked. Transitions depend on which factors were used and when. Write it as an explicit state machine with property-based tests, and show evaluators that no sequence of events lets an attacker who controls only the email take over an account without the waiting period and notifications firing.

The second interesting part is correct WebAuthn verification: challenge handling, origin and relying party ID checks, signature counter behaviour with synced passkeys, and attestation choices. Explain each decision in your report.

How to evaluate it

• Security: a written threat model with test cases for each threat; run them in CI. Invite classmates to attempt takeover of a test account with only email access, within a scoped exercise on your own deployment.
• Compatibility: a matrix of browsers and operating systems tested with real devices and virtual authenticators.
• Usability: 10 users sign up, sign in on a second device and recover a "lost" device. Measure completion rate and time.
• Performance: sign-in latency at the 95th percentile under a load test.

Suggested plan

1. Weeks 1 to 4: read the WebAuthn spec and Google's passkey user journey guidance; write the threat model.
2. Weeks 5 to 10: registration and authentication, OpenID Connect endpoints, sample app.
3. Weeks 11 to 16: recovery state machine, step-up rules, notifications.
4. Weeks 17 to 20: admin console, audit trail, Docker packaging.
5. Weeks 21 to 26: compatibility testing, user study, scoped takeover exercise, write-up.

Path to a product

Release the core as open source and sell a managed hosting plan with flat pricing, or a support contract for self-hosters. The first customer is a startup or software house building consumer apps that wants phishing-resistant login and is uncomfortable with per-user pricing. Fintech and health apps, which need strong authentication and data control, are the natural next segment.

Scope warning

Do not build a full identity platform with SAML, SCIM and enterprise SSO. Do not support SMS as a recovery factor. Do not implement your own cryptography; use a well-reviewed WebAuthn library and spend your effort on flows and tests.

Learn what you need on Sefism

• Backend roadmap : sessions, tokens and API design for the auth service.
• Backend cheat sheet : quick reference while building endpoints and storage.
• OAuth 2.0 Simplified : the OAuth and OpenID Connect concepts your integration layer uses.
• OWASP ASVS : authentication and session requirements to test your service against.
• MDN: HTTP : cookies, origins and headers that matter for WebAuthn.

Get help with this idea

Scoping a security project is mostly about deciding what you will not defend against and how you will prove the rest works. If you want a second opinion on scope, stack or your evaluation plan, a mentor can review it with you; you still build it yourselves. New to Sefism? Create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session