API Keys
Server-to-server and programmatic access via public/private key pairs.
For machine-to-machine auth — CLIs, integrations, internal tooling — Nest Auth ships an API key system. Each key is a pair: a non-secret public ID and a secret private value. The pair is bound to a user; calls authenticated with the key act as that user.
How calls authenticate
The NestAuthAuthGuard accepts API keys on the same Authorization header it accepts JWTs — which key style is in use is detected from the value's shape.
Generating a key
Through the admin console, or programmatically:
privateKey is returned only once at creation time. After that, the library has only a hash and cannot reveal the original.
Lifecycle
| Operation | Method |
|---|---|
| Create | keys.create({ userId, name, description?, expiresAt? }) |
| List for user | keys.findByUser(userId) |
| Update metadata | keys.update(id, { name, description }) |
| Deactivate | keys.deactivate(id) (key still exists, but rejects auth) |
| Delete | keys.delete(id) |
Each operation emits a corresponding event: AccessKeyCreatedEvent, AccessKeyUpdatedEvent, AccessKeyDeactivatedEvent, AccessKeyDeletedEvent — wire them to your audit log.
Key validation flow
- Guard parses
Authorization: Bearer <publicKey>:<privateKey>. - Service looks up
nest_auth_access_keysbypublicKey. - Compares the hash of the supplied
privateKeyagainst the stored hash. - Checks
isActive,expiresAt. - Updates
lastUsedAt. - Loads the owning user; the request proceeds as that user.
If any step fails, the guard returns 401 INVALID_API_KEY.
Scoping with roles & permissions
API keys inherit the owning user's roles and permissions. If you want a key to have fewer privileges than its owner, store an explicit scope on the key's metadata and read it in your handlers (or in a guards.beforeAuth hook).
Related
- Backend services reference — full
AccessKeyServiceAPI. - Backend events reference —
AccessKey*events. - Admin console — UI for managing keys.