Security
This page outlines authN/Z, CORS and operational knobs.
Authentication
- Bearer JWTs issued by the IDP
- Audience required for the admin SPA:
control-admin - Token validation and audience mapping implemented in the backend guards
See IDP documentation for IDP details and the audience → role mapping.
Authorization
- Guards enforce capabilities at the controller level (e.g.,
@Roles('access-control.admin', 'access-control.manager', 'access-control.auditor')) - Capabilities derive from PermissionAssignments applied to roles
- Platform superadmin (
platform.superadmin) can be mapped by ops to bypass capability checks when desired
CORS
- Defaults permit localhost and
dev.digiwedge.comvariants - Override using
CORS_ALLOWED_ORIGINS(CSV). Each entry may be a full origin or bare host
Sessions (cookies + CSRF)
- Admin SPA keeps the access token in memory and relies on a httpOnly refresh cookie shared across tabs
- CSRF protection: SPA calls
GET /api/auth/csrfto receiveXSRF-TOKENand sendsX-XSRF-Tokenon IDP POSTs - Cookies set/rotated by IDP on login/refresh:
idp_rt=<refresh>;idp_jti=<session id>;HttpOnly; Secure; SameSite=None; Path=/api/auth
Required CORS Headers
Access-Control-Allow-Origin: https://access-control-admin.…
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: content-type, x-client-audience, x-xsrf-token
- WebSocket events for the admin use the API base at
/ws/events(https→wss mapping in the client)
See IDP docs for endpoint details and cookie semantics.