Application API Keys

Application keys identify a subject in access checks — whether that subject is one of your end users, or one of your own internal services. Create a key for each subject, assign roles that define what it's allowed to do, and pass the key when calling has-access.

How it works

The subject (your end user or one of your internal services) holds an application key. Your backend extracts it from incoming requests. Your backend asks WardenAuth: can this key do this? WardenAuth resolves the key's assigned roles and returns true or false.

The application key never calls WardenAuth directly. Your backend does, using a management key.

Creating a key

cURL

curl -X POST https://api.wardenauthz.com/v1/scope/workspace-eng/api-key/application \
  -H "x-api-key: YOUR_MANAGEMENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Alice",
    "roles": ["editor"],
    "autoRotationEnabled": true,
    "autoRotationIntervalDays": 30,
    "autoRotationOverlapDays": 7
  }'

{
  "keyId": "key_x9y8z7w6",
  "rawKey": "sk_live_eJx1VUd...",
  "maskedKey": "sk_live_****Ud...",
  "name": "Alice"
}

Prerequisites

• You need api-key.application:create permission.
• Roles are optional. A key without roles authenticates as a subject but grants no permissions — every has-access call returns false.
• A management key with access-check:evaluate must exist before you can check access for any application key.

Checking access

Your backend receives a request from Alice. Extract her application key, then ask WardenAuth:

cURL

curl -X POST https://api.wardenauthz.com/v1/access/has-access \
  -H "x-api-key: YOUR_MANAGEMENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "subjectId": "key_x9y8z7w6",
    "resource": "documents",
    "action": "write",
    "scopeId": "workspace-eng"
  }'

{ "allowed": true }

Edge cases

• Application keys cannot call the management API. They authenticate subjects for access evaluation only. They can't create scopes, manage roles, or mint other keys.
• The raw key is shown once. Issue keys programmatically and store them in your database, secret store, or environment variables.
• A key without roles returns allowed: false on every check. Assign roles before distributing the key.
• Service-to-service pattern. When your internal services act as subjects (e.g. Checkout API checking if it can process an order), use application keys — not management keys. Management keys are for administering the system.

In the dashboard

[Screenshot: Application Keys tab showing list with masked values and assigned roles]

Navigate to Application Keys. Click New Application Key, name it after your user, and assign roles. The raw key appears once.