Enterprise SSO Configuration

Enterprise SSO allows organizations to use their corporate identity provider — Okta, Azure AD, Google Workspace, OneLogin, and others — to authenticate users in Auris. Instead of managing separate Auris credentials, users sign in through their employer’s existing login page and are automatically granted access to your application.

SSO connections are configured per-organization. Each organization can have one or more SSO connections (for example, SAML for the main workforce and OIDC for a subsidiary using a different IdP).

Access via Console → Organizations → select an organization → Enterprise SSO tab.

Creating an SSO Connection

Open the organization detail page

Go to Console → Organizations and click on the organization you want to configure SSO for.

Navigate to the Enterprise SSO tab

Click the Enterprise SSO tab (the fourth tab on the organization detail page).

Click Add SSO Connection

Click the Add SSO Connection button.

Select the connection type

Choose SAML 2.0 or OIDC depending on what your customer’s identity provider supports. Most enterprise IdPs support both, but SAML is more common in large organizations.

Enter a connection name

Give the connection a descriptive name (for example, “Acme Corp Okta SAML”, “Contoso Azure AD OIDC”). This name is for administrative reference only and is not shown to end users.

Configure provider-specific settings

Fill in the settings for your chosen protocol. See the configuration tables below.

Save

Click Save. The connection is created in Inactive status. You must activate it after testing.

SAML 2.0 Configuration

When creating or editing a SAML 2.0 connection, the following fields are available:

Field	Required	Description
SSO URL	Yes	The IdP’s Single Sign-On URL (also called “Login URL” or “SSO Service URL”). This is where Auris redirects the user to authenticate.
Entity ID	Yes	The IdP’s Entity ID, also called the “Issuer”. A unique identifier for the identity provider, typically a URL.
Certificate	Yes	The IdP’s X.509 signing certificate in PEM format. Auris uses this to verify that SAML assertions are genuinely from the IdP.
Name ID Format	No	The format of the user identifier in the SAML assertion. Default: `emailAddress`. Alternative: `persistent` (opaque identifier).
Sign AuthnRequest	No	Whether Auris should sign its SAML authentication request. Some IdPs require signed requests. Default: off.

Where to find these values in your IdP:

Okta: Go to Applications → your SAML app → Sign On tab → View SAML setup instructions
Azure AD: Go to Enterprise Applications → your app → Single sign-on → SAML configuration
Google Workspace: Go to Admin Console → Apps → Web and mobile apps → your SAML app → Service provider details

After saving, Auris provides the following values that you need to enter in the IdP:

Auris Value	Where to Enter in IdP
ACS URL (Assertion Consumer Service)	Reply URL / ACS URL field
Entity ID / Audience	SP Entity ID / Audience Restriction field
Metadata URL	SP Metadata URL (if the IdP supports automatic configuration)

OIDC Configuration

When creating or editing an OIDC connection, the following fields are available:

Field	Required	Description
Discovery URL	Yes	The IdP’s OpenID Connect Discovery URL (`.well-known/openid-configuration`). Auris fetches the authorization, token, userinfo, and JWKS endpoints from this URL automatically.
Client ID	Yes	The Client ID assigned to Auris by the IdP when you register it as an application.
Client Secret	Yes	The Client Secret assigned to Auris. Stored encrypted in the Auris database.
Scopes	No	The OpenID scopes to request during authentication. Default: `openid email profile`. Add additional scopes if you need custom claims.

Where to find these values:

Azure AD: App registrations → your app → Overview (Client ID) + Certificates & secrets (Client Secret) + Endpoints (Discovery URL)
Okta: Applications → your OIDC app → General tab (Client ID, Client Secret) + Issuer URI + /.well-known/openid-configuration
Google Workspace: Google Cloud Console → APIs & Services → Credentials → OAuth 2.0 Client. Discovery URL: https://accounts.google.com/.well-known/openid-configuration

After saving, Auris provides a Redirect URI that you must add to the IdP’s allowed redirect URIs list.

Connection Status

Each SSO connection has a status badge:

Status	Badge Color	Meaning
Inactive	Gray	The connection is saved but not active. Users cannot log in via this connection.
Testing	Yellow	The connection is configured and available for test logins but is not the default for the organization’s domains.
Active	Green	The connection is live. Users matching verified domains are automatically redirected to this IdP.
Error	Red	The connection encountered a configuration error (for example, expired certificate, unreachable discovery URL).

Testing an SSO Connection

Before activating a connection for all users, test it to verify the configuration is correct.

Click Test Connection

On the SSO connection detail, click the Test Connection button.

Authenticate with the IdP

A new browser window opens with the identity provider’s login page. Sign in with a test account.

Review the test results

After successful authentication, the test window displays the attributes received from the IdP:

Attribute	Description
Subject / Name ID	The user identifier returned by the IdP
Email	The user’s email address
First Name	Given name (if provided)
Last Name	Family name (if provided)
Groups / Roles	Any group or role claims (if configured in the IdP)
Raw Assertion	The full SAML assertion or OIDC ID token (expandable, for debugging)

Verify the attributes

Confirm that the email, name, and other attributes are correct. If attributes are missing, check the IdP’s attribute mapping or claims configuration.

If the test fails, the window shows the error message. Common failure reasons are listed in the Troubleshooting section below.

Domain Verification

Domain verification links email domains to SSO connections. When a user enters their email on the hosted login page, Auris checks whether the email domain is verified for an SSO connection. If it is, the user is automatically redirected to the corporate IdP — no manual “Sign in with SSO” button required.

Adding a Domain

Click Add Domain

On the Enterprise SSO tab, click Add Domain in the Verified Domains section.

Enter the domain

Enter the email domain (for example, acme.com, contoso.io). Do not include the @ symbol.

Copy the DNS TXT record

Auris generates a verification record that you (or your customer’s IT team) must add to the domain’s DNS:


_auris-verification.acme.com  TXT  "auris-verify=abc123def456ghi789"

Copy the full record value.

Add the TXT record to DNS

In the domain’s DNS management panel (Cloudflare, Route 53, GoDaddy, etc.), create a new TXT record with:

Host / Name: _auris-verification
Value: auris-verify=abc123def456ghi789 (the value from the previous step)
TTL: 3600 (or default)

Click Verify

After the DNS record has propagated (typically 1-15 minutes), click the Verify button next to the domain. Auris performs a DNS TXT lookup to confirm the record exists.

Domain Status

Status	Badge Color	Meaning
Pending	Yellow	The domain has been added but not yet verified. The DNS TXT record has not been confirmed.
Verified	Green	DNS verification succeeded. Users with this email domain are redirected to the SSO connection.
Failed	Red	DNS verification failed. The TXT record was not found. Check DNS propagation and record values.

DNS propagation can take up to 48 hours in some cases, though most providers propagate within minutes. If verification fails, wait a few minutes and try again. Use a tool like dig _auris-verification.acme.com TXT to check whether the record is visible.

When a user enters their email on the Auris hosted login page, the following flow occurs:

The user types their email address and clicks Continue (or the email field loses focus)
Auris calls the SSO detection endpoint with the email domain
If the domain is verified and linked to an active SSO connection, the user is automatically redirected to the corporate IdP
After authenticating with the IdP, the user is redirected back to Auris
Auris processes the SAML assertion or OIDC callback and issues an Auris session

This detection is transparent to the user — they simply enter their email and are redirected to their company’s login page.

POST/api/auth/sso/detect

Just-In-Time (JIT) Provisioning

When a user logs in via SSO for the first time and does not have an existing Auris account, Auris automatically creates one. This is called Just-In-Time provisioning.

The provisioned user account is populated with:

Email: From the SAML Name ID or OIDC email claim
First Name / Last Name: From the SAML attributes or OIDC profile claims
Organization membership: Automatically added to the organization that owns the SSO connection
Roles: Default roles for the organization (configurable in the organization settings)

JIT provisioning means you do not need to pre-create user accounts for SSO users. The first login creates everything automatically.

SSO users do not have an Auris password. They authenticate exclusively through their corporate IdP. This means SSO users cannot use the “Forgot Password” flow — there is no password to reset. If an SSO user needs to log in without their IdP (for example, during an IdP outage), an administrator must manually set a password for them in Console → Users.

Managing SSO Connections

Activating and Deactivating

Toggle the Active switch on any connection to enable or disable it. Deactivating a connection prevents users from logging in via that IdP but preserves the configuration. This is useful during IdP maintenance or when troubleshooting issues.

Deleting a Connection

Click Delete on a connection to permanently remove it. A confirmation dialog appears — type the connection name to confirm. Deleting a connection does not delete the users who were provisioned through it.

Connection Statistics

The connection detail view shows:

Metric	Description
Last Login	Timestamp of the most recent SSO authentication through this connection
Total SSO Logins	Cumulative count of successful SSO authentications
Error Count	Number of failed SSO attempts (certificate errors, misconfigurations, etc.)

IdP Setup Quick Reference

Okta (SAML)

In Okta Admin, go to Applications → Create App Integration → SAML 2.0
Set the Single sign-on URL to the ACS URL from the Auris Console
Set the Audience URI (SP Entity ID) to the Entity ID from the Auris Console
Under Attribute Statements, map email, firstName, lastName
Copy the Identity Provider SSO URL, Entity ID, and download the Certificate
Paste these into the Auris Console SAML connection form

Azure AD (SAML)

In Azure Portal, go to Enterprise Applications → New Application → Create your own
Select Integrate any other application and name it
Go to Single sign-on → SAML
Set Reply URL (ACS) to the ACS URL from Auris
Set Identifier (Entity ID) to the Entity ID from Auris
Download the Certificate (Base64) and copy the Login URL and Azure AD Identifier
Paste these into the Auris Console SAML connection form

Google Workspace (SAML)

In Google Admin Console, go to Apps → Web and mobile apps → Add app → Add custom SAML app
Copy the SSO URL and download the Certificate
Set the ACS URL and Entity ID from the Auris Console
Map the email, firstName, lastName attributes
Paste the SSO URL and Certificate into the Auris Console

Troubleshooting

Issue	Cause	Resolution
”Invalid SAML response”	Certificate mismatch — the IdP’s signing certificate has been rotated	Download the new certificate from the IdP and update it in the Auris Console
”Discovery URL unreachable”	The OIDC discovery endpoint is not accessible from the Auris server	Verify the URL is correct and that the Auris server can reach it (check firewall rules)
User created but no name	The IdP is not sending name attributes	Configure attribute statements / claims in the IdP to include `firstName` and `lastName`
”Redirect URI mismatch” (OIDC)	The redirect URI in the IdP does not match the one Auris provides	Copy the exact Redirect URI from the Auris Console and add it to the IdP’s allowed redirect URIs
Domain verification fails	DNS TXT record not found	Verify the record exists with `dig` or `nslookup`. Check for typos in the record name and value. Wait for DNS propagation.
Users not redirected automatically	Domain is not verified, or SSO connection is not Active	Verify the domain status is Verified (green) and the connection status is Active (green)

Permissions

Permission	Description
`manage:sso_connections`	Create, edit, delete, activate, and deactivate SSO connections. Manage domain verification.
`view:sso_connections`	View SSO connections, domains, and statistics. Cannot modify configurations.

Enterprise SSO Setup — Step-by-step guide for configuring SSO with major IdPs
Single Sign-On Concepts — How SSO works at a conceptual level
Organizations — Managing organizations in the Console
SCIM Provisioning — Automated user provisioning alongside SSO
Hosted Login Pages — How the hosted login page detects and redirects SSO users