Auth

SSO introduction

SSO (Single Sign-On) is a technology that enables users to log into multiple apps with one login, boosting security by reducing password fatigue, streamlining access for better productivity, and giving IT central control for easier management and compliance. It's crucial because it improves user experience by eliminating forgotten passwords and enhances security by minimizing risks from weak, reused passwords, while simplifying IT's job to manage access centrally.

Why is SSO Important

Enhanced Security

  • Fewer Passwords: Reduces password fatigue, meaning users are less likely to create weak or reused passwords.
  • Centralized Control: IT can manage access, enforce strong policies (like Multi-Factor Authentication), and quickly disable access for departing employees from one place.
  • Reduces Shadow IT: Helps IT monitor and control which apps employees are using, minimizing risks from unauthorized apps.

Improved Productivity & Experience

  • Frictionless Access: Users save time logging in repeatedly, allowing them to focus on their work.
  • Better Adoption: A seamless login experience encourages users to adopt and use more applications.

Simplified IT Management

  • Reduced Support Costs: Fewer forgotten passwords mean fewer help desk tickets.
  • Streamlined Onboarding/Offboarding: Quick provisioning and de-provisioning of access for new and departing staff.
  • Better Compliance & Auditing: Centralized logging of access attempts simplifies audits for regulations like GDPR or HIPAA.

Supported protocols

21RISK supports two industry-standard SSO protocols:

  • OpenID Connect (OIDC) — built on OAuth 2.0. This is the recommended option for most organizations. Setup guides: Microsoft Entra · Google
  • SAML 2.0 — a widely adopted XML-based federation protocol, commonly used in organizations with existing SAML infrastructure. For Microsoft Entra, 21RISK can automatically fetch and renew certificates via the Federation Metadata URL. Setup guides: Microsoft Entra (SAML) · Generic SAML

If you don't have a strong preference, we recommend OIDC — it's simpler to configure and maintain.

How OIDC works at 21RISK

For OIDC connections, 21RISK uses the OAuth 2.0 Authorization Code Flow with Proof Key for Code Exchange (PKCE). You can read more about the standard here .

  1. Initiation : When a user clicks "Login", 21RISK generates a cryptographically random secret called a code_verifier and hashes it to create a code_challenge .
  2. Redirect : The user is redirected to the Identity Provider (e.g., Azure AD) along with the code_challenge . We request the following scopes openid email profile .
  3. Authentication : The user enters their credentials at the Identity Provider's secure login page.
  4. Callback : Upon success, the Identity Provider redirects the user back to 21RISK with a temporary authorization_code .
  5. Exchange : The 21RISK server sends this authorization_code plus the original code_verifier directly to the Identity Provider's token endpoint.
  6. Verification : The Identity Provider verifies that the code_verifier matches the initial code_challenge . This ensures the authorization code wasn't intercepted.
  7. Session : If valid, the Identity Provider returns an ID Token. 21RISK validates this token and establishes a secure session for the user.

How SAML works at 21RISK

For SAML connections, 21RISK acts as a Service Provider (SP) that redirects users to your Identity Provider (IdP) for authentication.

  1. Initiation : When a user clicks "Login", 21RISK generates a SAML AuthnRequest and stores a random state value in the user's session.
  2. Redirect : The user is redirected to the Identity Provider's SSO URL with the AuthnRequest. 21RISK does not impose any authentication method requirements — the IdP is free to authenticate the user however it sees fit (password, MFA, X.509 certificates, passkeys, etc.).
  3. Authentication : The user authenticates at the Identity Provider's login page using whatever method the IdP requires.
  4. Response : Upon success, the Identity Provider POSTs a signed SAML Response back to 21RISK's Assertion Consumer Service (ACS) URL.
  5. Validation : 21RISK validates the SAML Response signature using the IdP's X.509 certificate, and verifies the state to prevent cross-site request forgery.
  6. Session : If valid, 21RISK extracts the user's email from the SAML assertion and establishes a secure session.

Multi-Page Application

21RISK is a Multi-Page Application, not a Single Page Application (SPA). We use secure HTTP-only Cookies to store state, nonce, and the PKCE. This protects the implementation against:

  • CSRF
  • Login mixup attacks
  • Wrong authorization server returning to your callback
  • Attacker forcing a victim user to log in as someone else
  • Replays of the ID token
  • Token substitution (attacker injects their own ID token)
  • Stolen ID token injection

To read more about our SOC2 Type 2 certification and IT security in general at 21RISK, please consult our compliance docs here

previous How access is controlled
next Setting up SSO with Microsoft Entra