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 if SAML SSO has not been enabled for your workspace or the SAML Authentication option is not available.

SAML SSO requirements and capabilities

Only workspace admins can configure SAML SSO. Once enabled, SSO can be used by members of the workspace.

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)Set up the required SAML settings, attributes, and user identifiers in your identity provider

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 choosing a NameID.

The identifier should:

Be unique to one user.
Remain the same across sign-ins.
Never be reassigned to another user.
Remain unchanged if the user's name, email address, or other profile attributes change.

Avoid using an email address as the NameID because email addresses can change. A stable directory identifier, employee identifier, or other immutable user ID is recommended.

<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:

Attribute	Required	Unspecified name	URI name
First name	Yes	`first_name`	`urn:oid:2.5.4.42`
Last name	Yes	`last_name`	`urn:oid:2.5.4.4`
Email	Yes	`email`	`urn:oid:0.9.2342.19200300.100.1.3` or supported alternative

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 Enter your IdP details in Otter, test the configuration, and enable SAML SSO

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 AuthnRequest. 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.

Once SAML SSO is enabled, workspace members can sign in to Otter using your organization’s identity provider (IdP).

For an SP-initiated sign-in, members start from Otter and are redirected to your identity provider to authenticate. After successful authentication, they are redirected back to Otter and signed in.

For an IdP-initiated sign-in, members start from your identity provider or application portal and select Otter. After successful authentication, they are redirected to Otter and signed in.

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 requiring SSO and allowing other login options?

When enabling SAML SSO for your workspace, you can choose whether SSO is required or optional for workspace members.

Allow other login options: SSO is optional. Workspace members can sign in using SSO or other supported sign-in methods. We recommend this option while initially testing your SAML configuration.
Require SSO for all workspace members: SSO is required. Workspace members must authenticate through your organization’s identity provider (IdP), and other sign-in methods are disabled.

You can change this setting later based on your organization’s authentication requirements.

What is the difference between the Unspecified and URI SAML attribute formats?

Attribute format	Typical behavior in an IdP	`NameFormat` value	Example attribute name
Unspecified	Uses a simple attribute name configured by the IdP	`urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified`	`first_name`
URI	Uses a URI or OID-based attribute name	`urn:oasis:names:tc:SAML:2.0:attrname-format:uri`	`urn:oid:2.5.4.42`
Default	Uses the IdP's default attribute format, which may vary by provider or configuration	Varies by IdP	Varies by IdP

Either format can be used as long as the attribute names and values sent by your identity provider match the supported Otter mappings listed above.

Note: Otter supports the Unspecified and URI attribute formats shown above. If your IdP provides a Default option, verify that the resulting SAML assertion uses one of the supported formats.

Why do I see multiple Otter applications in my Identity Provider (IdP)?

You may see multiple Otter applications in your Identity Provider (IdP) if your organization already uses other Otter integrations or sign-in methods. These applications may be separate from the application you create specifically for SAML SSO.

For example, in Microsoft Entra, an Otter application may already exist if your organization uses Continue with Microsoft or has connected Microsoft calendars to Otter. This is separate from the Enterprise application created for SAML SSO.

When configuring SSO, make sure you select or create the application intended specifically for your SAML SSO configuration. Do not modify an existing Otter application used for another integration or sign-in method.

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

Related to