An auth server is not one thing

#What I set out to build

Guardian was an authentication server in Rust: OAuth, sessions, email templates, the standard set. I wrote it to learn the domain properly rather than to ship a product, and the thing it taught me was structural rather than cryptographic.

#Every method is a different shape

Password authentication needs a hashing configuration, a password policy, a reset flow with tokens and email, and a history table if you enforce reuse rules. Its storage is a hash and some metadata.

OAuth needs client registration, redirect URI validation, scopes, and one configuration block per provider [1]. Its storage is provider identities linked to local accounts, and its routing includes a callback endpoint per provider.

Passkeys need a relying party identifier, attestation preferences, and a challenge store with a short lifetime [3]. Its storage is credential identifiers and public keys.

Those have almost nothing in common beyond producing a session at the end. I tried to express them as configuration options on one server, and the resulting configuration surface had options that were meaningless in combination and no way to say so.

#The cost of carrying what you do not use

A server that supports every method contains the code for every method, whether or not a deployment uses it. That is a maintenance cost and, more importantly, an attack surface cost. Economy of mechanism is on Saltzer and Schroeder's list for exactly this reason [2]: a simpler mechanism has fewer places to be wrong, and code that is present is reachable if something else goes wrong.

An application that will never use SAML should not ship SAML parsing.

#The design that came out of it

Years later I built the same domain again with methods as plugins. Core identity, users, sessions, organisations, roles and devices, sits in the middle. Each authentication method is a separate module that registers its own routes, its own storage and its own configuration, and you compile in the ones you use.

This is Parnas applied to a security domain [4]. The module boundary follows the decision being hidden, and the decisions each method hides really are independent.

#The thing I still find hard

Account linking cuts across every method. If a user signs up with a password and later signs in with Google using the same email address, what happens is a policy question with security consequences, and it cannot live inside either plugin.

It sits in the core, and it is the part of the design I am least happy with, because it is the one place where the plugins have to know about each other.