Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Security Model

Aero2 implements multiple layers of security to protect your users and applications.

Authentication Security

Token Signing

All tokens are signed with RS256 (RSA + SHA-256). Signing keys rotate automatically every 24 hours, with previous keys retained for verification continuity. The public keys are available via the JWKS endpoint for token verification.

Token Type Enforcement

Each token includes a token_use claim that identifies its purpose:

  • access — API authorization
  • id — User identity claims
  • session — Internal session management

Aero2 rejects tokens used for the wrong purpose, preventing token confusion attacks.

PKCE Required

PKCE (Proof Key for Code Exchange) with the S256 method is mandatory for all authorization requests. The plain method is not supported. This protects against authorization code interception attacks.

Refresh Token Security

Refresh tokens are hashed before storage. If the database is compromised, the stored hashes cannot be used to forge tokens. Refresh token rotation is enforced — every use invalidates the previous token.

CSRF Protection

  • OAuth state validation — State tokens are stored server-side with expiration and consumed atomically on callback
  • Cookie binding — State is bound to an HttpOnly cookie to prevent login CSRF
  • Origin/Referer checking — State-changing requests validate the Origin header matches the expected host
  • SameSite cookies — Session cookies use SameSite=Strict to prevent cross-site request forgery

Session Security

  • HttpOnly cookies — Session tokens are stored in HttpOnly cookies, inaccessible to JavaScript
  • Secure flag — Cookies are only sent over HTTPS
  • Session tracking — Every session is tracked in the database with user agent and IP
  • Revocation — Sessions can be individually revoked or bulk-revoked
  • Proactive invalidation — When a user is disabled, all active sessions are immediately revoked

Access Control

Aero2 uses role-based access control (RBAC) with granular permissions:

  • Two built-in roles: admin (full access) and user (basic self-service)
  • Custom roles with specific permission sets
  • Permission-based endpoint protection
  • Permissions follow a resource:action naming convention (e.g., users:read, clients:write)

Transport Security

  • HSTS — Strict-Transport-Security header with a 1-year max-age
  • CSP — Content Security Policy restricting script and resource loading
  • X-Frame-Options — Prevents clickjacking via framing
  • X-Content-Type-Options — Prevents MIME-type sniffing
  • Referrer-Policy — Limits referrer information in cross-origin requests
  • Permissions-Policy — Restricts unused browser features (camera, microphone, geolocation)

Input Validation

  • SSRF protection — Identity provider URLs are validated to block private IPs and localhost
  • Open redirect prevention — All redirect URIs are validated against an allowlist
  • Schema validation — All API inputs are validated against strict schemas before processing
  • SQL injection prevention — All database queries use parameterized statements

Cryptography

  • Token signing — RS256 (RSA 2048-bit + SHA-256)
  • Secret hashing — PBKDF2 with 100,000 iterations, random salt, SHA-256
  • Token hashing — HMAC-SHA256 for refresh token storage
  • Key rotation — Automatic 24-hour key rotation with bounded key storage

Application Isolation

Each application runs in its own isolated environment:

  • Separate user pools — Users in one application cannot access another
  • Subdomain isolation — Each application has its own subdomain for cookie and CORS separation
  • Per-app settings — Authentication methods, MFA policies, and branding are configured independently

See Also