Expand description
Authentication: turning a wire-level credential into a verified IdentityId the rest of the system can attach
to a transaction. The crate owns the registry of supported authentication methods, the challenge-response state
machine for methods that need it, and the service handle the server tiers route incoming sessions through.
Authorisation - what an identity is allowed to do once authenticated - is not in this crate; that is the policy engine’s responsibility. The split exists so a deployment can swap out authentication methods (token, password, external IDP) without touching the policy enforcement path.
Invariant: a successful authentication produces an IdentityId that resolves through the catalog to a real,
non-revoked identity. Anything that mints an IdentityId outside this crate (test fixtures aside) bypasses
revocation and method requirements and is a security regression.
Modules§
- challenge
- error
- method
- Authentication method implementations. Each method is self-contained - it owns its credential format,
verification logic, and challenge state - and registers with the
registry/so the service can pick the right one for an incoming request. Adding a new method (a new IDP, a new key type) means writing one of these modules and registering it; the rest of the auth surface is method-agnostic. - registry
- service
- Auth service handle wired up by the runtime. Owns the catalog and admin-transaction handles needed to verify credentials, mint tokens, and load identities; exposes the high-level “authenticate this request” entry point that server transports invoke. Per-method specifics (token, Solana key) sit in submodules so the public surface stays method-agnostic.