Directory. / developers

Security

Defense in depth, not a checklist

Authentication, credential binding and auditability are protocol-level mechanisms, not middleware bolted on afterward. This page describes each one directory-go actually enforces.

Password authentication

Passwords are hashed with bcrypt and never logged or returned by any endpoint. Login is rate-limited per source IP, independently of registration. A forgotten password is recovered through POST /password-reset, which always responds identically whether or not the email is registered — the endpoint cannot be used to enumerate accounts — and issues a single-use, time-limited reset token.

Passkeys (WebAuthn)

As an alternative to a password, an account can register one or more passkeys — a device's fingerprint, face, or a hardware security key authenticates the login, and the private key never leaves the device. There is nothing to intercept, replay, or phish: the credential is bound to the exact origin it was registered against. Registration and login are each a two-step challenge/response ceremony built on the standard PublicKeyCredential browser API. A passkey is always additive — password login stays available as a fallback.

Durable audit trail

Every write against the registry — issuing or revoking a certificate, a status change, a new webhook subscription — is recorded to a persistent, queryable log: actor, action, timestamp, and enough detail to reconstruct what happened. A record outlives the institution it describes; deleting an institution clears the record's reference to it, never the record itself.

Sender-constrained tokens (RFC 8705)

Covered in full on the Certificates & mTLS page: a session or service credential can be bound to a client certificate's thumbprint at the moment it's issued, so a leaked bearer token alone stops being sufficient to authenticate.