What is SSO?

Single sign-on (SSO) allows users to log in to many websites or apps with one set of login details. This works through connecting with an identity provider (IdP).

IdPs store and manage users' digital identities for digital or cloud-based apps. An IdP can check identities or just provide a list of identities that another service provider (like an SSO) stores. Airtable uses the Security Assertion Markup Language (SAML 2.0) protocol to facilitate connection with SSO IdPs.

In addition to sharing user login credentials with Airtable, IdPs can also create Airtable user accounts on behalf of users. Airtable typically supports Just-in-Time (JIT) provisioning, which means that if a user does not yet have an existing Airtable user account, the IdP will create one for them the first time they access Airtable via SSO.

Airtable also supports System for Cross-domain Identity Management specification (SCIM). SCIM provisioning allows IdPs to pass additional user metadata into Airtable and provision user accounts when users are granted access to Airtable in the IdP. Airtable offers default SCIM integrations for Okta and Microsoft Entra ID. Additionally, customers can build their own custom SCIM integrations for other IdPs.

Airtable SSO and organization domains and memberships

When SSO is configured for an Airtable organization, its configuration is specific to that domain’s level—which is owned and verified by the parent organization. Suppose an organization has more than 1 domain. In that case, enterprise admins can configure SSO for one, some, or all domains owned by the organization.

At a high level, SSO grants users access to Airtable; it does not assign organization user licenses or grant specific organization permissions for workspaces, bases, or interfaces. Managing user licenses and permissions occurs in the admin panel and can’t be controlled via SSO.

SSO configuration, account linking, and SSO enforcement are separate steps. You can allow external users to authenticate through your IdP without turning on SSO required. First configure the email attribute and configuration-specific URLs, then have each external user complete account linking. See Let contractors and partners sign in through your SSO.

Airtable SSO log-in flows

Airtable supports both Service Provider (SP)-initiated login and IdP-initiated login, representing the 2 paths a user can take to log into Airtable using Single sign-on.

• In SP-initiated logins, users navigate to airtable.com, click Sign in, select the Sign in with Single Sign On, and are redirected to the IdP's signin URL.

• In IDP-initiated logins, users navigate directly to their SSO IdP, where they are presented with a list of applications or SPs to choose from. After selecting Airtable, they are logged into their Airtable home screen.

When SSO is first configured for an email domain owned by an organization, the login requirement defaults to optional—meaning that organization members have the option to log in via SSO or email and password.

If the SSO login requirement is set to required, all organization members must log in using SSO. If they attempt to log in any other path, they will be redirected to the SSO sign in URL.

Choose your SSO setup

If you already use basic SSO with email addresses as the NameID, you can continue using that setup. Expand Basic SSO with the legacy ACS URL below for those instructions. To add the newer capabilities to an existing setup, follow Upgrade an existing SSO configuration.

SSO required is a separate choice. You don’t need to turn it on to configure SSO or allow external users to sign in through your identity provider. Decide whether to require SSO after testing.

Set up SSO with a separate email attribute

Before you start, you’ll need:

• An Airtable Business or Enterprise Scale plan and permission to manage SSO. In Enterprise Hub, work with your organization’s super admin.

• Access to your identity provider’s Airtable SAML application.

• A verified domain owned by your organization to host the SSO configuration.

• The identity provider’s sign-in URL and X.509 signing certificate.

• A SAML application that lets you configure the email attribute, Reply URL, and Entity ID.

You don’t need to own or verify external users’ email domains. For example, your organization can configure its IdP under example.com and use it to authenticate contractors whose email addresses end in partner.example.

If you already have an SSO configuration, use the upgrade instructions below before changing its settings.

1. Configure the email attribute in your identity provider

   1. Open the Airtable SAML application in your identity provider.

   2. Add a SAML attribute named mail and map its value to the user’s real email address. For an existing Airtable user, this should be the email on the account they intend to use.

   3. If your app already sends email under another attribute name, you can keep that name. You’ll enter the exact same name in Airtable. For example:

      <Attribute Name="mail">
        <AttributeValue>alex@partner.example</AttributeValue>
      </Attribute>

   4. In this example, enter mail in Airtable’s Email attribute name field. Don’t enter alex@partner.example.

   5. The attribute name is also different from the source field in your identity provider. For example, an Entra ID claim might take its value from user.mail but send it under the name mail or a full claim URI. Airtable needs the name sent in the SAML response.

      If your SAML response sends the email under this attribute name	Choose or enter this in Airtable
      mail	mail
      email	email
      http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress	The full URI
      urn:oid:0.9.2342.19200300.100.1.3	The full OID string
      Another attribute name	Enter the exact custom name

      These are examples, not provider-specific defaults. Check what your application actually sends. Match spelling and capitalization, and make sure the value contains a valid email address for every assigned user.

2. Configure the NameID

   1. Choose a unique identifier that will remain stable for each person, such as an employee ID. A NameID can also be an email address, but changing that address also changes the identifier unless you keep its value stable.

   2. Adding an email attribute does not automatically change the NameID your IdP sends. If your goal is to preserve identity through email changes, choose a NameID value that won’t change with the email address. A UPN is suitable only if your organization keeps it stable.

   3. For a non-email identifier, use the Unspecified NameID format.

3. Save the matching settings in Airtable

   1. Open Admin panel → Settings → Security & compliance.

   2. Find Email domains and SSO configuration.

   3. Select Set up SSO for your verified domain.

   4. Enter your IdP’s Sign-in URL and X.509 certificate.

   5. Select V2 for the Airtable metadata version.

   6. Set Email attribute name to the exact name from step 1, such as mail.

   7. Save the configuration.

      If the email attribute setting is unavailable, confirm that the domain is verified and that you’ve selected V2.

4. Copy Airtable’s URLs into your identity provider

   1. After saving, copy these values from the Airtable SSO configuration into the same SAML application you configured above:

      Airtable field	Field in your identity provider
      Reply URL (ACS)	Reply URL, ACS URL, or Single sign-on URL
      Audience URI (Entity ID)	Identifier, Audience, or Service provider Entity ID

   2. For this setup, the URLs have these shapes:

      Reply URL (ACS):
      https://airtable.com/auth/ssoCallback/{enterpriseAccountId}/{ssoIdentityProviderId}
      
      Audience URI (Entity ID):
      https://airtable.com/sso/metadata/idp/{enterpriseAccountId}/{ssoIdentityProviderId}.xml

   3. Copy the actual values displayed in Airtable; don’t construct them from these examples. Keep the ACS URL and Entity ID together as a matching pair.

   4. If the dialog still shows the legacy ACS URL after you save V2 and an email attribute on a verified domain, contact Airtable Support before continuing.

   5. The Sign-in URL supplied by your IdP is a different field: it tells Airtable where to send users to authenticate. The Reply URL (ACS) tells your IdP where to send its response back to Airtable.

5. Assign a test user and test sign-in

   1. Assign a test user to the Airtable application in your IdP.

   2. Have the user launch Airtable from that application.

   3. Complete any email confirmation or account-linking steps Airtable shows.

   4. Confirm that the user reaches the intended Airtable account and has the correct email address.

   5. For an existing account, check that its expected workspaces and bases are still available.

   6. Sign out and test Sign in with Single Sign On from Airtable, using the account’s email address.

      For an external user who hasn’t linked their account yet, start from the IdP’s application dashboard. Airtable cannot discover your organization’s IdP from an unrelated external email domain alone.

6. Decide whether to require SSO

   1. After testing, turn on SSO required if your organization wants to enforce SSO.

   2. This requirement also applies to external users linked to an IdP when a domain associated with that IdP requires SSO. It doesn’t discover, invite, or link external users for you.

   3. Leave SSO optional if you want users to have the choice of using it.

Upgrade an existing SSO configuration

Use this path when you already have working basic SSO and want to add external users or use an identifier separate from email.

1. Record your existing settings in Airtable and your IdP: sign-in URL, certificates, metadata version, ACS URL, Entity ID, NameID mapping, and any SCIM mappings.

2. Coordinate the changes with your IdP administrator. Keep a working admin sign-in method available. Follow your organization’s change process for temporarily making SSO optional while editing.

3. Add the email attribute to the existing IdP app and verify that it sends the intended email addresses.

4. Edit the existing Airtable SSO configuration. Select V2, configure the matching Email attribute name, and save.

5. Update the IdP app with the configuration-specific Reply URL (ACS) and Audience URI (Entity ID) shown in Airtable. If the IdP validates Airtable’s signed requests, update its trusted Airtable metadata/certificate for V2 as part of the change.

6. Test IdP-initiated and Airtable-initiated sign-in with a current user. Then test an external user, if that’s your goal.

7. If you use SCIM, align userName with the SAML NameID and send the account email in the primary emails entry. Test matching and updating an existing user before provisioning a larger group.

8. Re-enable SSO required, if appropriate, after tests pass.

Let contractors and partners sign in through your SSO

External users can authenticate through your organization’s identity provider even when you don’t own their email domains.

First complete Set up SSO with a separate email attribute, or upgrade your existing configuration. Use an IdP configuration attached to your own verified domain. Don’t add a contractor’s or partner’s domain as though your organization owns it.

Onboard a user

1. Assign the person to the Airtable app in your IdP. Confirm that the email attribute contains the email for the Airtable account they intend to use.

2. Ask them to launch Airtable from your IdP’s application dashboard.

3. Ask them to open Airtable’s account-linking email, review the organization’s access, and confirm if they want to connect their account.

4. Have them sign in again through the IdP.

5. In the admin panel’s user list, confirm the account appears as External SSO. Also check that the person has the intended collaborator access and seat, if needed.

For an eligible existing account, this links the account instead of creating another one. For a new account, the email confirmation completes the required mailbox verification and consent.

An account already managed by another organization may not be eligible for this linking flow. Contact Airtable Support if the user can’t proceed.

Provision external users with SCIM

If you use SCIM, configure the same email-attribute setup first. Send:

• userName: the identifier used as the user’s SAML NameID.

• emails: a primary entry containing the user’s Airtable email address.

• The Airtable SSO extension, with emailDomain identifying your organization’s verified domain for the chosen IdP, not the external user’s domain.

For example, if your IdP is configured under example.com and the user’s email is alex@partner.example, the extension’s emailDomain is example.com.

See the SCIM API documentation for request details. Creating the user doesn’t complete their first sign-in: ask them to complete the email confirmation and account-linking steps Airtable sends before trying SSO.

What external SSO changes

• The organization can manage the linked user’s SSO login and supported account actions. The user remains external: the SSO link doesn’t make them an organization member, add them to user groups or org units, grant access to content, or assign a license.

• SSO required is optional for this setup. If you turn it on for a domain associated with the linked IdP, the requirement extends to its linked external users. Turning on the setting alone won’t onboard external users.

• An unlinked external user should start from the IdP. After linking, they can choose Sign in with Single Sign On from Airtable and enter their Airtable email.

If the first sign-in doesn’t work

Use one configuration for multiple company domains

If your organization owns multiple verified domains, select Use existing SSO configuration when adding SSO to an additional domain. Choose the configuration already used by your organization. This shares an IdP across your own domains; it is not necessary to add an external contractor’s domain.

SSO Configuration options

• Requiring SSO in Airtable - Before requiring SSO for your organization’s domain, we recommend testing your current SSO configuration by signing in using that email domain to prevent SSO misconfiguration.

• Making SSO optional in Airtable - Admins must make SSO optional before editing the SSO metadata to prevent misconfigurations, which won't allow users to sign in. Once SSO is optional, collaborators can sign in with using their email addresses and passwords.

• Deleting SSO requirements in Airtable - Deleting an SSO configuration for a domain removes users' ability to sign in using SSO for that domain; organization members revert to email and password. Deleting an identity provider also revokes access for any SSO-managed external users linked to it — they are notified by email and can no longer sign in through your IdP — and any pending account linking invitations are canceled.

Managing rotating SAML certificates

1. Uncheck SSO required option - Navigate to Admin Panel, click the Settings option on the left sidebar, then click the Security & Authentication tab. From here, make sure that the domain that you are updating has the SSO required checkbox unchecked.

2. Remove the previous certificate - Click the Edit button under the SSO metadatacolumn, then highlight and delete all of the previous SAML signing certificate, called the x.509 certificate in Airtable.

3. Get the new x.509/SAML certificate - Access the new x.509 certificate from your IdP. In some cases, this may be referred to as a SAML signing certificate within the IdP that your organization uses. You'll want to copy this certificate for use in the next step.

4. Paste the content into admin panel - Paste the contents of the new certificate that you just copied into the x.509 field in the metadata configuration window of the admin panel. This information should already be blank after following Step 2. Click Save after pasting the content. After editing your IdP metadata, the changes may take up to 5 minutes.

5. (Optional) Re-enable the SSO required option - Recheck the SSO required option. In some cases, your organization may leave this off, in which case, you can skip this step. After rotating your certificate, you may be prompted to log in via SSO to verify that SSO is functioning correctly with the new certificate. Once you have successfully logged in, you will be able to re-enable the SSO required setting.

Troubleshooting SSO issues and error messages

• “I changed a user's email address in the IdP and now they can't see any of their workspaces, bases, or interfaces.”

  • For SSO configurations using Just-in-Time (JIT), it is necessary to first update the user account’s email address in Airtable via the "User details" page of the admin panel or the Enterprise API (API documentation) before updating the email address in the user’s profile in the IdP.

  • If a duplicate account was created because the email address was updated in the IdP first, you can take the following steps to rectify the issue:

    • Delete the user’s new duplicate account via the Enterprise API( API documentation).

  • For SSO configurations using SCIM provisioning, emails can be updated on the IdP side, which will update the email address attribute of the associated Airtable user account.

  • To avoid this issue in the future, consider configuring an email attribute in your SSO settings. An email attribute lets you separate email from the NameID. To preserve identity through email changes, the NameID must remain stable, existing accounts must be matched correctly, and the new email must meet your organization’s domain and account-management requirements. Test these mappings before a migration.

• “SAML Certificate Signature Check”

  • This error message indicates that the x.509/SAML certificate stored in your enterprise account’s admin panel under “SSO metadata” does not match the x.509/SAML certificate currently supplied by your IdP.

    • To resolve this error, admins must update the x.509/SAML certificate with the correct one from your IdP. See the Managing rotating SAML certificates section for instructions.

• "SSO isn’t set up for your account”

  • This error message may indicate any of the following scenarios:

    • Your Airtable user account is an unclaimed member of an SSO-configured organization.

    • The email address associated with your Airtable user account does not match any domains owned by the SSO-configured organization.

    • You haven’t been granted access to the Airtable application on the side of your organization’s IdP.

    • If you’re an SSO-managed external user (your email domain isn’t owned by the organization), choose Sign in with Single Sign On on airtable.com — your linked identity provider is found automatically.

      • Signing in with a password instead will direct you to the SSO sign-in page.

      • If neither works, start from your IdP’s application dashboard.

• "403 app not assigned" or something similar

  • Errors like these indicate the user hasn’t been granted access to the Airtable application on the side of your organization’s IdP.

  • To resolve this, please get in touch with one of your organization’s enterprise admins or your organization’s IT department to request that your user profile be granted access to Airtable in your IdP.

• “I received an email asking me to link my Airtable account to an organization’s SSO”

  • An organization whose identity provider asserted your email address attempted to sign you in via SSO. Because you already have an Airtable account with that email, Airtable asks for your confirmation before connecting anything.

    • If you expected this (for example, your company or a client is onboarding you to their SSO): click the link, review what the organization will be able to manage, and confirm. Then sign in again through their identity provider.

    • If you didn’t attempt to sign in: you can ignore the email. Your account is not connected, and nothing changes without your confirmation.

• Troubleshooting name or attribute changes that don't sync from your IdP

  • If you update a user's first or last name in your identity provider (Okta or Microsoft Entra ID) and the change doesn't appear in Airtable, check the following:

    • Confirm the name attribute is included in your identity provider's attribute mapping to Airtable. If first and last name aren't mapped, updates you make in your identity provider won't push through.

    • Confirm that pushing user updates is turned on for your Airtable app integration in your identity provider. If it's off or paused, changes won't sync until it's turned back on.

    • Allow time for the next sync cycle, since attribute changes don't sync instantly.

    • Remember that your identity provider is the source of truth for any field it pushes to Airtable. If a name was previously edited directly in Airtable, the next sync overwrites that local edit.

Resolving duplicate accounts after an IdP email change

When a user's email address changes in your identity provider (for example, due to a last name change), some IdP configurations trigger Airtable's JIT provisioning to create a new Airtable account under the updated email rather than updating the existing one. This results in a duplicate account, and the original account's email may appear "in use" even after the duplicate is deactivated in the admin panel.

1. Delete the duplicate account - Contact Airtable Support to request deletion of the duplicate account. Deactivating alone doesn't free the email address at the platform level; the account must be deleted by a support engineer.

2. Update the original account's email - In admin panel, click Users, open the original account (the one with the old email), and update the email address to match the user's current IdP email. You can also do this via the Enterprise API.

3. Have the user log in again - Once the original account's email is updated, the user can log in through their IdP.

4. If the original account was also deactivated during troubleshooting, reactivate it before updating the email address.

SSO glossary

FAQs