The problem

Most identity providers still treat passwords as the baseline and passkeys as an optional upgrade layered on top. That leaves the weakest authentication path (a password, however it's stored) permanently available as a fallback, which means it's permanently available as an attack surface too. Multi-tenant setups make this worse: audit logging, token revocation and privilege boundaries need to hold up cleanly across tenants, not just within one.

What I built

An OAuth 2.1 and OpenID Connect server where WebAuthn passkeys are the only credential: there's no password field to fall back to, because there's no password to compromise. It's built multi-tenant from the ground up, issuing both JWT and opaque tokens with named privilege levels, and every authorisation decision is written to an audit log. Standard OAuth 2.1 flows are implemented properly rather than approximately: PKCE is mandatory, introspection and revocation endpoints are real, and rate limiting sits in front of the whole thing. A user portal lets people manage their own passkeys and see what they've authorised without needing to go through an administrator.

Engineering decisions

• WebAuthn-only, no password fallback: removing the weak path entirely rather than merely discouraging it.
• Multi-tenant from the start: tenant isolation is a first-class part of the data model, not retrofitted onto a single-tenant assumption.
• Both token types: JWTs where a resource server needs to validate offline, opaque tokens where centralised revocation matters more than that.
• Audit logging as a core feature, not a bolt-on: every authorisation event is logged in a way that's actually useful under review, not just present for compliance box-ticking.

What it demonstrates

Standards-correct implementation of a genuinely security-critical piece of infrastructure: the kind of system where "mostly right" isn't a meaningful state to be in. It's also a good example of building for the multi-tenant, audit-heavy requirements that come with ISO 27001-adjacent work, rather than adding those constraints in later.