> ## Documentation Index
> Fetch the complete documentation index at: https://trust.denialbase.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Authentication & access control

> How Denialbase verifies identity and enforces authorization on every request.

## Authentication factors

<CardGroup cols={2}>
  <Card title="Password" icon="key">
    12-character minimum. Complexity validator requires upper, lower, digit, and special character. Checked against breached-password datasets.
  </Card>

  <Card title="TOTP (Authenticator app)" icon="mobile">
    RFC 6238 time-based one-time passwords. Works with Authy, Google Authenticator, 1Password, Bitwarden, etc.
  </Card>

  <Card title="Passkeys (WebAuthn)" icon="fingerprint">
    FIDO2 phishing-resistant authentication. Platform authenticators (Touch ID, Windows Hello) and roaming authenticators (YubiKey, Titan) both supported.
  </Card>

  <Card title="Google OAuth 2.1" icon="google">
    SSO via Google Workspace. Enforced 2-factor at the IdP counts toward our 2FA requirement.
  </Card>
</CardGroup>

<Info>
  **Magic-link sign-in** is also available for recovery and low-friction flows, with short TTLs and single-use tokens. Magic links never substitute for 2FA on PHI-accessing accounts.
</Info>

## Session handling

* **httpOnly Secure cookie** — JWT delivered as `HttpOnly; Secure; SameSite=Lax`. Not readable by JavaScript.
* **No Bearer tokens** in client-side storage (`localStorage` / `sessionStorage`) — session state is cookie-only.
* **Payload TTL** — JWT payload expires in 4 hours; refresh is automatic if the user is active.
* **Cookie TTL** — 1 day, extending on activity.
* **Idle timeout** — sessions terminate after 30 minutes of inactivity.
* **Signout** — server-side revocation plus cookie clear; no stale token can survive logout.

## Brute-force and enumeration resistance

* **Account lockout** after 5 failed password attempts. Auto-unlock after 1 hour. Lockouts are logged to the security audit log.
* **Rack::Attack rate limiting** on every sensitive endpoint, backed by Memorystore Redis for cross-instance consistency:

| Endpoint class                     | Limit              |
| ---------------------------------- | ------------------ |
| General requests                   | 300 / 5 min per IP |
| Auth (login, password reset)       | 5 / 20 sec         |
| 2FA setup                          | 5 / 1 min          |
| Passkey operations                 | 10 / 1 min         |
| Email sending (per target address) | 3 / 5 min          |
| Token verification (magic links)   | 10 / 1 min         |

* **Timing-safe comparisons** for all password and token checks.
* **Indistinguishable responses** — invalid-email and wrong-password return the same generic error and the same latency, to prevent enumeration.
* **Cloud Armor** adds a second layer at the load balancer: 500–1000 req/min per IP with a 5-minute ban on breach, plus OWASP CRS v3.3.

## Authorization

<Info>
  Every API action is gated by object-level authorization via [Pundit](https://github.com/varvet/pundit). No request escapes without an explicit policy decision.
</Info>

* **Global enforcement** — `ApplicationController` sets `after_action :verify_authorized`. Any controller action that doesn't call `authorize` or explicitly `skip_authorization` raises in development and fails in production.
* **48 policy files** cover every PHI-bearing model and every admin action.
* **Role-based authorization** layered on top:

| Role          | Description           | PHI access                                   |
| ------------- | --------------------- | -------------------------------------------- |
| `user`        | Standard user         | Own data only                                |
| `analyst`     | Reporting / analytics | Aggregated or anonymized only                |
| `support`     | Customer support      | Read-only PHI access, scoped to assigned org |
| `admin`       | Org administrator     | Full access within the org                   |
| `super_admin` | Denialbase internal   | Full platform access; actions audit-logged   |

## Delegation and API access

* **Human-to-system delegation** (scoped task tokens, currently in design) — future capability for letting staff authorize Denialbase to take a specific action on their behalf.
* **API tokens** for server-to-server integrations have narrow scopes and short TTLs.
* All authentication and authorization decisions are recorded in the security audit log.

## Identity providers

* **Google OAuth 2.1** — live.
* **SAML 2.0 SSO** (Okta, Azure AD, Google, any SAML IdP) — [see SSO setup](/integrations/sso-saml).
* **SCIM provisioning** — planned for Q3 2026.