Enterprise SSO

Auris enables enterprise customers to authenticate using their existing corporate identity provider (IdP) — Azure Active Directory, Okta, Google Workspace, OneLogin, PingIdentity, or any SAML 2.0 or OIDC-compliant IdP.

SSO connections are scoped to organizations. Each organization in Auris can have one or more SSO connections, and the appropriate connection is detected automatically by the user’s email domain.

Overview

When a user with an email matching a verified domain attempts to sign in, Auris:

1. Detects the SSO connection via the email domain
2. Redirects the user to the corporate IdP login page
3. Receives the SAML assertion or OIDC token from the IdP
4. Maps IdP user attributes to Auris user fields
5. Provisions the user account in Auris if it does not exist (JIT provisioning)
6. Issues an Auris access token and refresh token

From your application’s perspective, the flow is identical to any other Auris login — you use the same SDK, the same callback URL, and receive the same token format.

SAML 2.0 Setup

OIDC Provider Setup

Domain Verification

For SSO detection to work, you must verify ownership of the email domain(s) used by the organization’s members.

Type:  TXT
Name:  _auris-verify.acme.com
Value: auris-verify=abc123xyz456...

SSO Detection

Auris automatically detects SSO availability when a user enters their email on the hosted login page. The detection flow is also available as an API call for custom login UIs:

// Custom login UI: check for SSO before showing the password field
async function checkSso(email) {
  const domain = email.split('@')[1]
  const response = await fetch('/api/auth/sso/detect', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ email }),
  })
  const data = await response.json()
 
  if (data.ssoEnabled) {
    // Redirect to SSO — skip the password field
    window.location.href = `/api/auth/sso/login/${data.connectionAlias}`
  } else {
    // Show password field
    showPasswordField()
  }
}

JIT Provisioning

Just-in-time provisioning automatically creates a new Auris user account the first time an SSO user authenticates. This eliminates the need to pre-create accounts or synchronize user lists manually.

On first SSO login:

• Auris creates a user account with the attributes mapped from the SAML assertion or OIDC token
• The user is assigned any default roles configured for the organization
• A user.created audit log event is recorded with source: 'sso_jit'

On subsequent SSO logins:

• Auris updates the user’s attributes from the IdP (name, email) if they have changed
• Role assignments from previous sessions are preserved
• A user.login audit log event is recorded

To disable JIT provisioning: Toggle JIT Provisioning off in the SSO connection settings. With JIT disabled, users must be pre-created in Auris (manually or via SCIM) before they can use SSO.

Role Mapping

By default, SSO users receive no roles in Auris. You can configure automatic role assignment based on IdP group membership:

1. In the SSO connection settings → Role Mapping tab
2. Map IdP group values (from a groups SAML attribute or OIDC claim) to Auris roles
3. Role mappings are applied on every login — if a user is removed from an IdP group, they lose the corresponding Auris role on their next login

Example mapping:

• IdP group AurisAdmins → Auris role Administrator
• IdP group AurisViewers → Auris role Viewer

API Endpoints

Security Considerations

SAML signature verification — Auris validates SAML assertions using the IdP’s signing certificate. Unsigned or improperly signed assertions are rejected.

OIDC state and nonce — The OIDC flow uses a state parameter for CSRF protection and a nonce claim to prevent token replay.

Domain takeover protection — A verified domain can only be claimed by one organization per tenant. Re-verification after domain transfer requires explicit admin action.

Bypass prevention — Once a domain is verified and SSO is active, users with that email domain are directed to the SSO flow. They cannot bypass SSO and log in with a password unless the connection is deactivated.

Related Guides

• Organizations — Setting up organizations for B2B multi-tenancy
• Hosted Login (PKCE) — The OAuth2 flow your application uses (unchanged for SSO)
• User Management — Managing SSO-provisioned user accounts