Security
This section covers the security features and protections available in LumoAuth, along with recommended practices for deploying them. The underlying primitives are drawn from OAuth 2.0, JSON Web Tokens (JWT, signed JSON tokens), sender-constrained tokens (DPoP, which ties a token to the client's key so a stolen copy cannot be replayed), and WebAuthn/FIDO2 passkeys for phishing-resistant authentication.
If you only read one page, read Credentials and access model: it explains which credential reaches which surface (browser session, API key, OAuth token, SCIM (automatic user provisioning) token) and why API keys and Bearer tokens never turn into a browser session.
Security Features Overview
| Feature | Description |
|---|---|
| Adaptive MFA | Risk-based multi-factor authentication |
| Brute Force Protection | Account lockout after failed attempts |
| Impossible Travel Detection | Flag logins from geographically impossible locations |
| Rate Limiting | Protect endpoints from abuse |
| Token Security | DPoP, short-lived tokens, revocation |
| Session Security | Secure + HttpOnly + SameSite=Lax cookies, fixation protection, idle timeout; sessions are created only by an interactive login, never by an API key or Bearer token |
| Credential scoping | API keys and OAuth tokens carry per-resource scopes; the Admin API fails closed without one. See Credentials and access model |
| CSRF Protection | Cross-site request forgery prevention, including on POST /logout and on the hosted OAuth login page |
| Password Security | Breach detection, complexity requirements, hashing |
| Organization Isolation | Complete data separation between organizations |
| Audit Logging | Event trail across authentication, admin, and authorization actions |
| Signing Key Rotation | Periodic cryptographic key rotation |
Attack Protection
Brute Force
LumoAuth detects and blocks brute force attacks:
| Setting | Description | Default |
|---|---|---|
| Max Failed Attempts | Failed logins before lockout | 5 |
| Lockout Duration | How long the account is locked | 15 minutes |
| IP-Based Blocking | An IP with 10 failures in 30 minutes is blocked temporarily | Enabled |
When an account is locked:
- An
account.lockedaudit entry is written and a high security alert is raised to your alert channels - A webhook fires if you subscribe to the matching events
The same limiter and lockout accounting (keyed by IP and by normalised e-mail) apply to the form login, the hosted OAuth login page and LDAP sign-in. The per-e-mail budget is spent atomically before the password is checked, so parallel guesses cannot race past the lockout. Re-entering the current password while signed in (change password or e-mail, delete account, forced password change) is limited to 5 attempts per 15 minutes per user, and wrong passwords there count toward the same lockout, so a stolen session cookie cannot be used to guess the password. The MFA challenge API shares the per-user challenge budget with the hosted page (429 rate_limited with Retry-After). See Rate limiting. Failures for unknown e-mails are counted too and every failure returns the same generic message, so an attacker cannot tell a wrong password from a missing account.
Credential Stuffing
LumoAuth mitigates credential stuffing through:
- Breached password detection (checks against known breach databases)
- Rate limiting on login endpoints
- Adaptive MFA that triggers on suspicious patterns
- Anomaly detection for login patterns
Bot Protection
- Rate limiting per IP address
- CAPTCHA integration for suspect requests
- Device fingerprinting for risk assessment
Password Security
| Feature | Description |
|---|---|
| Adaptive hashing | Passwords are hashed with a strong adaptive algorithm (Argon2id or bcrypt, selected automatically) |
| Breach Detection | Passwords checked against known breaches |
| Minimum Length | Configurable minimum password length |
| Complexity Rules | Require uppercase, lowercase, numbers, symbols (each a separate policy option) |
| Applied everywhere | The organization's policy and breached-password check apply to self-service, reset, the portal user editor (an empty password is rejected), the Admin API, SCIM and B2B invitation acceptance |
| Periodic resets | Optional: users must choose a new password once the password rotation interval has passed |
Token Security
| Feature | Description |
|---|---|
| Short-lived access tokens | Default 1-hour expiration |
| Refresh token rotation | New refresh token issued on each use |
| Token revocation | Immediate revocation via API. Blocking, deactivating or deleting a user, Sign out everywhere, and a password change or reset also invalidate that user's already-issued access tokens at once (introspection returns active: false, userinfo and LumoAuth APIs reject them) |
| Sender-constrained tokens (DPoP) | Bind tokens to client cryptographic keys |
| JWT signing | RSA or EC signing with key rotation |
| Audience restriction | Tokens scoped to specific applications |
| JWT access token profile | JWT access tokens follow the standard claim set and application/at+jwt type |
Network Security
| Feature | Description |
|---|---|
| TLS mandatory | All endpoints require HTTPS |
| HSTS | Strict Transport Security headers |
| Secure cookies | HttpOnly, SameSite=Lax; the Secure flag is always set in production, where the session cookie is __Host-lumo_session (no Domain, Path=/), so a sibling subdomain or custom domain cannot plant or shadow it |
| CORS | Configurable allowed origins per application |
| CSP | Content Security Policy headers |
Organization Security
| Feature | Description |
|---|---|
| Data isolation | All queries scoped to current organization |
| Separate signing keys | Each organization has independent signing keys |
| Independent auth config | MFA, password policy, social login per organization |
| Cross-organization protection | Authorization checks prevent cross-organization access; the September 2026 review found no cross-organization read or write (see Security audits) |
| Operator fallback off | LumoAuth operators cannot sign in through your hosted login page unless allow_root_admin_login has been enabled for your organization at your request |
Security Configuration
Configure security settings at (the Security group of the portal sidebar holds Sign-in settings, Adaptive security, Signing keys and Audit logs):
| Setting | Location |
|---|---|
| Password policy | Sign-in settings, sections Password standards and Auth lifecycle (/orgs/{orgId}/portal/settings/authentication) |
| MFA policy | Sign-in settings, section MFA policy (/orgs/{orgId}/portal/settings/authentication) |
| Adaptive security (risk engine, thresholds, detection signals, network guard, trusted IP ranges) | Adaptive security (/orgs/{orgId}/portal/settings/adaptive-auth) |
| Rate limiting | Fixed per deployment — no portal UI; see Rate Limiting |
| Signing keys | Signing keys (/orgs/{orgId}/portal/signing-keys) |
| API keys and scopes | API keys, under Applications & developer tools (/orgs/{orgId}/portal/settings/api-keys) |
| SCIM provisioning policy | /orgs/{orgId}/portal/integrations/scim |
security.dpop_require_nonce | Admin API PATCH /orgs/{orgId}/api/v1/admin/organization; see Organization settings |
allow_root_admin_login | Not configurable by organizations; changed only by LumoAuth operators at your request; see Organization settings |
In This Section
| Guide | Description |
|---|---|
| Credentials and access model | Which credential reaches which surface, scopes, and why sessions are never minted from tokens |
| Rate Limiting | API rate limiting and throttling |
| Security Best Practices | Recommendations for secure deployment |
Standards used on this page
| Plain name | Standard |
|---|---|
| OAuth 2.0 (the core sign-in and token protocol) | RFC 6749 |
| JSON Web Token (JWT) | RFC 7519 |
| Sender-constrained tokens (DPoP) | RFC 9449 |
| Passkeys (WebAuthn and FIDO2) | W3C Web Authentication and FIDO Alliance CTAP |
| JWT access token profile | RFC 9068 |
See the standards reference for what each one covers and how LumoAuth uses it.