Authentication
The auth module provides JWT/OIDC verification, API key auth, RBAC, and session
context propagation via AsyncLocalStorage. It is framework-agnostic: the same
verifyAuth() works with raw Node.js® HTTP, Express, and NATS™ messages through
a single HeaderProvider abstraction.
Auth modes
Two operating modes control who validates the token and how the user identity reaches the service:
| Mode | Who uses it | Token verification | Ports needed |
|---|---|---|---|
STANDALONE | BE | Service validates JWT against IDP via OIDC discovery | UserResolverPort, RoleMappingPort |
GATEWAY | Microservices | BE already resolved the user; microservice verifies gateway secret + deserializes headers | None |
AuthConfig
Auth configuration is loaded once at startup from the service's config table and cached in memory. The config determines the mode, OIDC settings, gateway secret, and the header names used for serialization.
Code
Call invalidateAuthConfig() to force a reload on the next loadAuthConfig().
STANDALONE mode (BE)
The BE validates the JWT, resolves the IDP subject to an internal UUID, and
expands roles into permissions using the role_mappings table.
Code
GATEWAY-RESOLVED mode (microservices)
Microservices do not validate JWTs or touch the database. The BE serializes the
fully resolved AuthUser into headers (HTTP proxy or NATS™), and the microservice
verifies the gateway secret and deserializes the user.
Code
For NATS™ subscribers:
Code
The BE publisher side uses buildNatsAuthHeaders() to serialize the user into
NATS™ headers with the gateway secret:
Code
AuthUser
The AuthUser type is the result of all auth verification — regardless of mode:
| Field | Type | Description |
|---|---|---|
id | string | Internal Primebrick UUID (or "system" for system API keys) |
idp_code | string | Original IDP subject (JWT sub) — traceability only |
email | string | null | User email |
name | string | null | Display name |
roles | string[] | Normalized role names from the IDP |
permissions | Set<string> | Flattened permissions derived from roles |
isAdmin | boolean | Bypasses all permission checks (admin role) |
isSystem | boolean | System API key — bypasses RBAC, actor = "system" |
idp_org | string | null | IDP organization |
idp_username | string | null | IDP username |
raw_access_token | string | undefined | Raw token (STANDALONE only, for proxy forwarding) |
API keys
API keys are machine-to-machine credentials stored in the api_keys table with
a SHA-256 hash. The SDK provides verifyApiKey(), hashApiKey(), and
generateApiKey().
Code
API keys accept two header formats:
Authorization: ApiKey <key>Authorization: Bearer <key>(when the key starts withpbk_)
RBAC
RBAC evaluates whether an authenticated user has the permissions required by an
endpoint. The Permission constant defines all known permissions. Three
sentinels are handled specially:
Permission.PUBLIC— endpoint reachable without authenticationPermission.AUTHENTICATED_USER— any authenticated caller passesPermission.AUTHENTICATED_ADMIN— only callers withisAdmin === truepass (admin-only operations, e.g. admin change-password)
Code
Admin users (isAdmin=true) and system API keys (isSystem=true) bypass all
permission checks. Wildcard patterns in role mappings (e.g. customers.read.*)
are supported via matchesWildcard().
For NATS™ subscribers, use enforceNatsRbac() — same logic, semantic separation.
The non-throwing variant checkRbac() returns { allowed, missing? } instead
of throwing.
Session context
Session context uses AsyncLocalStorage to propagate the authenticated actor
through the async chain without passing it through every method signature. The
auth middleware sets the session; DAL code reads it via requireActor().
Code
getSession() returns the full Session object or undefined if no session is
in scope. runWithSession() is the low-level primitive — prefer runAsSystem()
or the auth middleware unless you are writing infrastructure code.
AuthError
All auth failures throw AuthError with an internal_code field. The HTTP
server's error handler reads internal_code and status from the error to
produce RFC 7807 responses. Common codes:
| Code | Meaning |
|---|---|
AUTH_TOKEN_MISSING | No Bearer token in Authorization header |
AUTH_TOKEN_INVALID | JWT verification failed (expired, bad signature, etc.) |
AUTH_GATEWAY_SECRET_INVALID | Gateway secret header mismatch |
AUTH_GATEWAY_HEADERS_MISSING | Required identity header not present |
AUTH_API_KEY_MISSING | No API key in Authorization header |
AUTH_API_KEY_INVALID | API key hash not found |
AUTH_API_KEY_INACTIVE | Key marked inactive |
AUTH_API_KEY_EXPIRED | Key past expires_at |
Next steps
- NATS Client — publish/subscribe with auth headers
- Service Registration — lifecycle events over NATS™
- HTTP Server — how auth errors become RFC 7807 responses
- API Reference — full auth API listing