Security

Authentication

21RISK supports multiple authentication methods to meet the security requirements of organizations of all sizes. This page documents the technical details of each method and the security properties they provide.

Supported authentication methods

Method Protocol When it is used
SSO — OpenID Connect OAuth 2.0 Authorization Code Flow with PKCE When the organization has configured an OIDC Identity Provider (e.g., Microsoft Entra, Google)
SSO — SAML 2.0 SAML 2.0 SP-initiated flow When the organization has configured a SAML Identity Provider
Email OTP One-time password sent via email Fallback when SSO is not configured for the user's domain

When a user enters their email address, 21RISK determines the authentication method automatically based on the domain. If the domain has an SSO connection marked as primary, the user is redirected to the corresponding Identity Provider. Otherwise, a one-time password is sent to the user's email.

SSO — OpenID Connect (OIDC)

For OIDC connections, 21RISK uses the OAuth 2.0 Authorization Code Flow with Proof Key for Code Exchange (PKCE), as specified in RFC 7636 . The requested scopes are openid email profile .

  1. 21RISK generates a cryptographically random code_verifier and derives a code_challenge .
  2. The user is redirected to the Identity Provider with the code_challenge .
  3. The user authenticates at the Identity Provider.
  4. The Identity Provider redirects back to 21RISK with an authorization_code .
  5. The 21RISK server exchanges the authorization_code and code_verifier at the token endpoint.
  6. The Identity Provider verifies the PKCE challenge and returns an ID Token.
  7. 21RISK validates the ID Token and creates a session.

Security properties:

  • PKCE prevents authorization code interception attacks.
  • The code_verifier is stored server-side and never exposed to the browser.
  • The state parameter is validated to prevent CSRF.

SSO — SAML 2.0

For SAML connections, 21RISK acts as a Service Provider (SP). The flow is SP-initiated:

  1. 21RISK generates a SAML AuthnRequest and stores a random state value (used as RelayState ) in the session.
  2. The user is redirected to the Identity Provider's SSO URL with the AuthnRequest.
  3. The user authenticates at the Identity Provider.
  4. The Identity Provider POSTs a signed SAML Response to 21RISK's Assertion Consumer Service (ACS) URL.
  5. 21RISK validates the XML signature using the IdP's X.509 certificate.
  6. The session is looked up by RelayState (because cross-origin POST requests do not include SameSite=Lax cookies).
  7. 21RISK extracts the user's email from the SAML assertion's NameID and creates a session.

Security properties:

  • The SAML Response signature is validated against the IdP's X.509 certificate configured in 21RISK.
  • RelayState ties the response back to the original session, preventing CSRF.
  • The email in the assertion must match the email the user entered in 21RISK, preventing identity substitution.
  • wantAssertionsSigned is enforced — unsigned assertions are rejected.

Email OTP

When SSO is not configured for a user's domain, 21RISK sends a one-time password (OTP) to the user's email address. The OTP is:

  • Cryptographically random
  • Single-use — consumed on first verification
  • Time-limited — expires after a short period
  • Rate-limited — excessive requests are throttled

Session management

21RISK is a Multi-Page Application (not a SPA). Session state is managed entirely server-side and identified by a secure, HTTP-only cookie.

Cookie properties:

Property Value
HttpOnly Yes — not accessible to JavaScript
Secure Yes — only transmitted over HTTPS
SameSite Lax — prevents cross-site request forgery
Path /

Session lifecycle:

  • Sessions are stored in the database, not in the cookie itself.
  • On login, a new session is created and the previous anonymous session is deleted.
  • Logged-in sessions expire after 3 months.
  • Sessions can be terminated by the user (logout) or by an administrator.

Security protections:

  • CSRF: SameSite=Lax cookies combined with server-side state validation.
  • Session fixation: a new session ID is generated on every login.
  • Replay attacks: the OIDC nonce and SAML RelayState are single-use and tied to the session.
  • Token substitution: the server validates that the authenticated identity matches the session that initiated the flow.

Audit logging

Every SSO login flow is logged end-to-end, including:

  • Flow initiation (email entered, domain matched, redirect to IdP)
  • IdP callback received
  • Validation result (success or failure with reason)
  • Session creation

These logs are available to organization administrators in the 21RISK settings under each SSO connection.

Further reading

previous Vercel platform
next Assets with Uploadcare