API Authentication
The AegisWire Go control plane API supports multiple authentication methods depending on the caller type. All API requests must be authenticated except health checks (/healthz, /readyz).
Authentication Methods
Session Cookie (Admin Interface)
The admin web interface authenticates using HTTP-only session cookies. This method is used by the browser-based admin UI at /admin/ and is not recommended for programmatic access.
Session properties:
- Cookie:
HttpOnly,Secure,SameSite=Strict - Inactivity timeout: configurable
- Absolute timeout: configurable
- All sessions are audit-logged with: admin user ID, session start, source IP, user agent
To authenticate, submit credentials to the admin login page at /admin/login. On success, the server sets a session cookie.
API Key (Machine-to-Machine)
For programmatic access and automation, use an API key:
Authorization: Bearer <api_key>
API keys are generated in the admin interface or via POST /v1/admin/api-keys. Each key is:
- Scoped to a specific tenant context
- Assigned an RBAC role
- Revocable at any time
- Audit-logged on every use
List existing keys via GET /v1/admin/api-keys.
Device Credential (Client Devices)
Client devices authenticate using credentials received during enrollment (/v1/enroll). The device credential is cryptographically bound to the device and used for policy refresh, gateway directory fetch, and session establishment.
OIDC / SAML (Federated Identity)
When an external identity provider is configured, users and devices can authenticate via:
- OIDC: Login redirect at
/admin/login/oidc, enrollment at/v1/enroll/oidc - SAML: Login redirect at
/admin/login/saml, enrollment at/v1/enroll/saml
The control plane validates tokens against the configured provider. Any validation failure results in immediate rejection with no fallback to a weaker authentication mode.
Security Rules
Rate Limiting
All authentication endpoints are rate-limited:
- Login: Maximum failed attempts per source IP within a time window
- API requests: Per-key rate limits configurable by the administrator
- Exceeding the rate limit returns HTTP
429 Too Many Requests
Account Lockout
After a configurable number of consecutive failed login attempts:
- The account is locked
- An admin notification is generated
- The account remains locked until an administrator unlocks it or the lockout timeout expires
- The lockout event is audit-logged
Audit Logging
Every authentication event is audit-logged:
| Event | Logged Fields |
|---|---|
| Successful login | user_id, source_ip, user_agent, auth_method, timestamp |
| Failed login | username (attempted), source_ip, user_agent, failure_reason, timestamp |
| API key used | key_id, source_ip, endpoint, timestamp |
| Session expired | session_id, user_id, reason (timeout/manual), timestamp |
| Lockout triggered | username, source_ip, attempt_count, timestamp |
Error Responses
All authentication errors return structured JSON:
{
"error": "unauthorized",
"detail": "Invalid credentials",
"request_id": "req_abc123def456"
}
HTTP Status Codes
| Code | Meaning |
|---|---|
401 Unauthorized |
Missing or invalid credentials |
403 Forbidden |
Valid credentials but insufficient permissions |
429 Too Many Requests |
Rate limit exceeded |
The response body does not include specific details about which credential component failed (to prevent enumeration attacks).
RBAC Model
API permissions follow the control plane's role-based access control model. Roles are managed via the admin interface and can be granted or revoked via /v1/admin/rbac/grant and /v1/admin/rbac/revoke.
Request Format
All API requests that include a body must use:
Content-Type: application/json- UTF-8 encoded JSON body
All API responses use:
Content-Type: application/json- UTF-8 encoded JSON body