Set up SAML Single Sign-On (SSO) – Help Center

Otter supports SAML-based single sign-on (SSO) for enterprise organizations, allowing IT admins to securely authenticate users through their identity provider. This article explains how to set up SAML SSO in Otter, outlines the requirements, and covers common configuration and troubleshooting steps.

Getting Started: Contact your Otter account manager to enable SSO, or if the option is not available in your Workspace.

Otter SAML capabilities

Only the admin can configure SSO for the team. Once configured, SSO is available to every team member.

Identity Provider (IdP)–initiated flow
Service Provider (SP)–initiated flow
Just-in-Time (JIT) provisioning: Otter accounts are automatically created from SAML attributes when users sign in via an IdP-initiated login.
Assertion and NameID encryption
Session duration enforcement based on settings configured in your IdP

Step 1: Configure your Identity Provider (IdP)

Know your Team Handle

Navigate to Manage Workspace > Settings.
Under SAML Authentication, click Configure.
Each Workspace will have its own unique team handle. Click Copy to copy your Workspace's team handle.

Note: In the following instructions, replace yourhandle with your team’s handle (e.g., https://otter.ai/saml/yourhandle → https://otter.ai/saml/workspace-team-handle).

Single Sign-On (SSO) URL

In SAML, the Single Sign-On (SSO) URL is commonly referred to as the Assertion Consumer Service (ACS) URL, sometimes called the SSO post-back URL.

https://otter.ai/saml/yourhandle

Entity ID

In SAML, the Entity ID is commonly referred to as the Audience value in the SAML assertion.

https://otter.ai/saml/metadata/yourhandle

NameID

NameID must be unique, pseudo-random, and will not change for the user over time — like an employee ID number. The NameID Format must be persistent. Learn more about setting

<saml2:Subject>
    <saml2:NameIDFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
        userName
    </saml2:NameID>
</saml2:Subject>

Attributes

Otter requires the following SAML Attributes:

first_name
last_name
email

And supports the following SAML Attribute formats:

urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified
urn:oasis:names:tc:SAML:2.0:attrname-format:uri

first_name: User’s first name (required)

<saml2:Attribute Name="first_name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">    
    <saml2:AttributeValue xsi:type="xs:string">        
        first_name_value   
    </saml2:AttributeValue>
</saml2:Attribute>

<saml2:Attribute Name="urn:oid:2.5.4.42" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">    
    <saml2:AttributeValue xsi:type="xs:string">        
        first_name_value    
    </saml2:AttributeValue>
</saml2:Attribute>

last_name: User’s last name (required)

<saml2:Attribute Name="last_name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">    
    <saml2:AttributeValue xsi:type="xs:string">        
        last_name_value   
    </saml2:AttributeValue>
</saml2:Attribute>

<saml2:Attribute Name="urn:oid:2.5.4.4" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">    
    <saml2:AttributeValue xsi:type="xs:string">        
        last_name_value   
    </saml2:AttributeValue>
</saml2:Attribute>

email: User’s email address (required)

<saml2:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">    
    <saml2:AttributeValue xsi:type="xs:string">        
        email_value    
    </saml2:AttributeValue>
</saml2:Attribute>

<saml2:Attribute Name="urn:oid:0.9.2342.19200300.100.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">    
    <saml2:AttributeValue xsi:type="xs:string">        
        email_value    
    </saml2:AttributeValue>
</saml2:Attribute>

<saml2:Attribute Name="urn:oid:1.2.840.113549.1.9.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">    
    <saml2:AttributeValue xsi:type="xs:string">        
        email_value    
    </saml2:AttributeValue>
</saml2:Attribute>

SAML Metadata

If your IdP asks for the SAML metadata XML file during setup, it can be downloaded at

https://otter.ai/saml/metadata/yourhandle

Step 2: Set up SAML SSO for Otter

Navigate to Manage Workspace > Settings.
Under SAML Authentication, click Configure.
Enter your SAML Endpoint URL (this was set up earlier when you configured your identity provider). This is where Otter's authentication requests will be sent.
Enter your Identity Provider Issuer URL (also known as the IdP Entity ID).
Copy the entire x.509 Public Certificate from your identity provider.
(Optional) In advanced settings, you can choose to sign AnthNRequest. You can also choose to require SAML Assertion and NameID encryption. Make sure the configuration in your IdP matches the selections in Otter.
To save changes, click “Save and Test”. A test authentication will be attempted to verify your configuration.
Once testing is complete and everything looks correct, toggle Enable SAML on for your workspace. You’ll have two options when enabling SSO:
- Allow other login options: SSO is optional; team members can continue using their preferred sign-in methods. Recommended during the testing phase to ensure uninterrupted access.
- Require SSO for all Team members: All team members must sign in using SSO. Other sign-in methods are disabled.

Note: When ready, ensure you select Require SSO for all Team members to prevent other sign-in methods.

FAQs

What is SAML SSO?

SAML Single Sign-On (SSO) is an authentication method that allows users to sign in to Otter using their organization’s identity provider, such as Microsoft Entra ID, Okta, Google Workspace, or other. Instead of creating a separate Otter password, users authenticate via their company’s existing login system, and access is granted securely based on the identity provider’s verification.

Who should use SAML SSO?

SAML SSO is recommended for organizations that:

Use a centralized identity provider (such as Microsoft Entra ID, Okta, or Google Workspace).
Want to manage user authentication and access from a single system.
Manage access for larger teams or enterprise environments.
Prefer automated user provisioning.

What's a good example of a NameID?

✅ Recommended: 9f3a2c71-84e2-4c1d-a8e1-3f6b92a01d77

A good NameID should:

Uniquely identify one user
Remain consistent across logins
Never be reassigned to a different person

🚫 Not recommended: john.smith@company.com

A bad NameID may:

Cause Otter to create a new account instead of recognizing an existing user
Change when a user’s email or attributes change, such as during:
- Name changes
- Domain migrations
- Mergers and acquisitions
- Email alias updates
Result in duplicate user accounts
Lead to loss of access to data
Require administrators to spend time cleaning up user accounts

Why must NameID be unique, pseudo-random, and not change for the user over time?

Uniquely identify one user
Stay the same across logins
Never be reassigned to a different person

It guarantees:

Stability over time (same user → same value)
Uniqueness within the IdP
No semantic meaning (it’s just an ID, not personal data)

A pseudo-random value:

Avoids exposing personal information
Prevents collisions
Stays valid even if user attributes change

Can I use email for NameID?

Using an email address as the SAML NameID is not recommended because email addresses can change over time. When a NameID changes, Otter treats the user as a new account instead of the same person. Common reasons email addresses change include:

Name changes
Domain changes or migrations
Company mergers or rebranding
Email alias updates

The NameID should be a unique, stable identifier that remains unchanged throughout the user's lifetime, similar to an employee ID number. For this reason, a persistent, pseudo-random identifier is recommended instead of an email address.

What identity providers are supported?

Otter supports a variety of Identity Providers.

Contact your Otter account manager if you have any questions about whether your Identity Provider is supported.

Note: If your organization uses Okta as the identity provider, please read the setup guide here.

What is the difference between "Unspecified" and "URI" in the attribute formats?

NameID format	Description	Typical behavior in an IdP	Recommended for Otter
Unspecified	No enforced format for the identifier	Often uses a stable, opaque user ID such as a GUID	Yes
URI	Uses a URI-style identifier (URN format)	Represents a unique, persistent identifier (not a real URL)	Yes
Default	Uses IdP's default NameID mapping	Commonly maps to an email	No

If you encounter problems or have questions during the setup, please contact our Otter Support Team for further assistance.

Related to