API Keys
WardenAuth has two key types with hard boundaries between them: a role that manages application keys can never mint a management key, and vice versa. Each type has its own dashboard tab and its own API endpoints.
Application keys
Application keys identify a subject — the entity asking "can I do this?" You use them any time your system needs to answer an access question about someone or something other than itself.
Two common patterns:
SaaS / multi-tenant. Your customers get API keys to interact with your platform. Create one application key per end user, assign roles that match their plan or permissions, and hand them the key. When they call your API, your backend passes the key to WardenAuth's access check to decide whether the request is allowed.
Internal microservices. You're running a handful of services — Cart API,
Checkout API, Search API — and each one needs to evaluate permissions before
acting. Create an application key per service (CART_API_KEY,
CHECKOUT_API_KEY, etc.), assign the roles that define what that service is
allowed to do, and have each service call has-access with its own key as
the subject. No need to build your own RBAC.
The key itself never calls WardenAuth directly. Your backend does, using a management key.
Management keys
Management keys authenticate callers of the WardenAuth management API.
Use them to create scopes, manage roles, mint new keys, and evaluate access
rules. Give them roles like access-checker or platform-admin.
Most teams use one management key for runtime access checks and a separate admin key for configuration changes.
| Application | Management | |
|---|---|---|
| Who holds the key | Your end users, or your own services | Your backend |
| What it does | Answers "is this subject allowed?" | Calls WardenAuth's API directly |
| Can create other keys? | No | Yes (with api-key.management:create) |
| Permitted roles | api-key.application:* | api-key.management:* |