Skip to main content

Security & Compliance Track

Use this track when you are reviewing LumoAuth for procurement, a security audit, or a compliance program (GDPR, SOC 2, FAPI 2.0). It surfaces the pages you need and skips the rest.

1. Start here​

  • Security Overview — threat model and defense-in-depth layers
  • Credentials and access model — which credential reaches which surface; API keys and tokens never become browser sessions
  • Best Practices — the short checklist for integrators and admins
  • Security audits — review history, including the 2026-09-16 independent review (no cross-organization data access found; same-day remediation; weekly dependency audit in CI)

2. Data protection & GDPR​

3. Authentication hardening​

  • Adaptive MFA — risk-based step-up
  • Passkeys / WebAuthn — phishing-resistant login; user verification is always required
  • Rate Limiting — shared lockout accounting across form, hosted OAuth and LDAP login
  • SCIM provisioning — the per-organization policy toggles (creation, updates, deletion, group operations, protected attributes) are enforced by the API

4. High-assurance OAuth​

5. AI agent security​

Standards implemented​

LumoAuth implements the following IETF and OpenID standards. The standards reference lists every specification with a link to the official text; the table at the end of this page maps the names below to their specification numbers.

  • OAuth 2.0 — The core sign-in and token protocol that defines the authorize and token endpoints and the standard grant types.
  • OpenID Connect 1.0 — An authentication layer on top of OAuth 2.0. Adds ID tokens and the userinfo endpoint.
  • SAML 2.0 — An XML-based single sign-on protocol used widely in enterprise environments.
  • SCIM 2.0 — The standard API for provisioning users and groups from an identity provider (one part defines the user and group schema, the other the HTTP protocol).
  • PKCE — A one-time secret that protects the sign-in code: an intercepted code cannot be exchanged for tokens. Required for public clients (SPAs, mobile apps).
  • Sender-constrained tokens (DPoP) — Binds an access token to a client-held key, so a stolen token cannot be replayed from another host.
  • Pushed authorization requests (PAR) — The client sends authorization parameters over a back-channel POST instead of a front-channel URL, avoiding URL-length limits and request tampering.
  • Rich authorization requests — Lets the client request fine-grained, structured permissions (e.g., "transfer €500 to IBAN X") instead of coarse scope strings.
  • Token exchange — Allows a service to exchange one token for another — the building block for delegation and impersonation.
  • Device authorization — The flow used by CLIs, smart TVs, and other input-constrained devices: the device shows a code, the user enters it on a second device.
  • CIBA — Client-initiated backchannel authentication. The client initiates login, the user authenticates out-of-band (e.g., via a push notification), and the client polls for the result.
  • FAPI 2.0 — A security profile from the OpenID Foundation tightening OAuth for financial-grade and regulated use cases.
  • Passkeys (WebAuthn / FIDO2) — Standard for hardware-backed, phishing-resistant authentication (passkeys, security keys).

Standards used on this page​

Plain nameStandard
OAuth 2.0 (the core sign-in and token protocol)RFC 6749
OpenID Connect (OIDC)OpenID Connect Core 1.0
SAML 2.0OASIS SAML 2.0
SCIM 2.0 (user and group provisioning)RFC 7642, RFC 7643, RFC 7644
Proof Key for Code Exchange (PKCE)RFC 7636
Sender-constrained tokens (DPoP)RFC 9449
Pushed authorization requests (PAR)RFC 9126
Rich authorization requestsRFC 9396
Token exchange (delegation)RFC 8693
Device authorization (sign in on another device)RFC 8628
Client-initiated backchannel authentication (CIBA)OpenID CIBA Core 1.0
Financial-grade API (FAPI) 2.0FAPI 2.0 Security Profile
Passkeys (WebAuthn and FIDO2)W3C Web Authentication, FIDO CTAP

See the standards reference for what each one covers and how LumoAuth uses it.