Atono supports SAML 2.0-based Single sign-on (SSO) for workspaces on paid plans. SSO allows your organization to manage user authentication through your existing identity provider (IdP), providing centralized access control and enhanced security.

SSO is commonly used by teams that want tighter control over user access and fewer credentials for users to manage across tools.

Only Workspace Administrators and Workspace Owners can access the SSO configuration page.

Before you begin

Before setting up SSO, make sure that you have:

A paid Atono plan - SSO isn't available for Free workspaces.
Admin access - You must be a Workspace Administrator or Workspace Owner.
IdP admin access - You’ll need permission to create and configure a SAML application in your identity provider.
A corporate email domain - Workspace users must have email addresses from a verified domain.

Access SSO settings

In Atono, click your workspace name in the header.
Select Settings.
Under Workspace, click Single sign-on.

From this page, you can configure SSO, update identity provider settings, and control how SSO is applied to users in your workspace.

Configure single sign-on

Setting up SSO requires configuring both Atono and your identity provider.

On the Single sign-on (SSO) page, click Configure SSO.

The steps below describe the generic SAML configuration required for any supported identity provider. If you're using Okta, see the Okta configuration example for provider-specific instructions.

Step 1 — Set up your SAML application

In this step, you’ll create a SAML application in your identity provider using values provided by Atono.

Copy Atono SAML values

On the SSO configuration page, copy the following values:

SAML response URL
Audience URI

You’ll use these values when configuring your identity provider.

Configure your identity provider (generic)

Create a new SAML 2.0 application in your identity provider and configure it with the following values:

Single sign-on / ACS URL: Use the SAML response URL from Atono.
Audience / Entity ID: Use the Audience URI from Atono.
User identifier: Email address
Attribute mapping: Send an attribute named email containing the user's email address.

🚧
Field names and UI labels vary by provider, but these values are required for Atono SSO to work.

Step 2 — Provide metadata from your identity provider

In this step, you’ll connect your identity provider to Atono.

In your identity provider, copy the application metadata URL (typically an XML endpoint).
In Atono, return to the SSO configuration page (Settings > Workspace > Single sign-on).
Paste the URL into the Application metadata URL field.
Click Save.

📘
SSO configuration settings are retained even if SSO is later disabled.

Apply your SSO configuration

After configuring SSO for the first time, Atono sets your workspace to Testing mode.

In Testing mode:

Workspace Owners and Workspace Administrators authenticate using SSO.
Other users continue signing in with email-based login links.

This allows you to validate the configuration before enabling SSO for everyone. For details on Testing mode and other authentication options, see Single sign-on modes.

Single sign-on modes

Single sign-on modes control how users authenticate in your workspace. You can change the mode at any time from the SSO configuration page.

On: All users authenticate using SSO.
Off: All users sign in using email-based login links. Your SSO configuration is retained but not applied.
Testing: Only Workspace Owners and Workspace Administrators authenticate using SSO. Other users continue signing in with email-based login links.

What happens when you change modes

When you switch modes, Atono asks you to confirm the change before applying it.

Turning SSO On invalidates any existing email-based login sessions, and affected users must sign in again using SSO.

Update an existing configuration

If you edit an existing SSO configuration, Atono prompts you to choose how the update should be applied:

Test SSO: Switches the workspace to Testing mode so only Owners and Administrators use SSO. Other users continue signing in with email-based login links.
Update SSO for everyone: Applies SSO immediately to all users and invalidates existing email login sessions.

Okta configuration example

This example shows how to configure SSO in Atono using Okta as your identity provider.

Atono supports any identity provider that implements SAML 2.0. If you’re using a different provider, the required values are the same, but field names and UI may differ. Additional provider-specific guides may be added in the future.

Use the steps below to complete Step 1 and Step 2 using Okta.

1. Create a SAML app integration in Okta

Sign in to the Okta Admin Console.
In the left navigation, click Applications, then select Applications.
Click Create App Integration.
Select SAML 2.0 as the sign-in method.
Click Next.

2. Configure general settings

On the Create SAML Integration screen, on the 1. General Settings tab:

App name: Enter Atono (or a name that helps you identify the app).
(Optional) Upload an App logo.

Click Next.

3. Configure SAML settings

On the 2. Configure SAML tab:

Under General:

Single sign-on URL: Paste the SAML response URL from Atono.
Audience URI (SP Entity ID): Paste the Audience URI from Atono.
Application username: Select Email.

Leave all other fields at their default values unless your organization requires additional security constraints.

4. Configure attribute statements

Still on the 2. Configure SAML tab:

Under Attribute Statements (optional), add the following mapping:

Name: email
Name format: Basic
Value: user.email

This is the only attribute required for Atono SSO to work.

🚧
Do not rename this attribute or change its value mapping. Atono uses the email attribute to identify users during SSO.

Click Next.

5. Complete the app setup

On the 3. Feedback tab:

If Okta asks how you plan to use the app, select the option indicating that you’re adding an internal application for your organization.
Click Finish.

This creates the app and opens the Sign On tab, where you can copy the metadata URL.

6. Provide Okta metadata to Atono

In the Atono application in Okta, open the Sign On tab.
Under Settings > Sign on methods > SAML 2.0, copy the Metadata URL.
Return to the SSO configuration page in Atono.
Paste the URL into the Application metadata URL field.
Click Save.

After saving, Atono places your workspace in Testing mode so you can verify the configuration before enabling SSO for everyone.

7. Assign users to the Okta application

Users must be assigned to the Okta application before they can sign in using SSO.

In the Atono application in Okta, click the Assignments tab.
Assign users or groups who should be able to access Atono.
Save your changes.

Only users who are assigned in Okta and already exist in Atono will be able to sign in.

Troubleshooting tips

If users are unable to sign in after SSO is configured, check the following.

Users are redirected back to the sign-in page

This usually indicates a configuration issue with the identity provider.

Verify that:

The identity provider is sending an attribute named email.
The email attribute value exactly matches the user’s email address in Atono.
The SAML response URL and Audience URI configured in the identity provider match the values shown in Atono.
The correct Application metadata URL is saved in Atono.

Workspace Owners or Administrators can’t sign in during testing

Confirm that SSO is in Testing mode and not Off.
Make sure the user signing in has a Workspace Owner or Workspace Administrator role.
Verify that the user exists in Atono and is using the same email address configured in the identity provider.

Users can’t sign in after SSO is turned on

Ensure the user is assigned to the SAML application in your identity provider.
Confirm the user already exists in Atono before attempting to sign in.
Check that the user is signing in with the correct email address.

Admin access during identity provider outages

Workspace Owners and Workspace Administrators receive a backup login email that can be used if the identity provider is unavailable. This email is intended for emergency access only; users should normally authenticate through their identity provider.