Configuring SSO in the admin panel
  • 05 Jun 2024
  • 13 Minutes to read
  • Dark
    Light
  • PDF

Configuring SSO in the admin panel

  • Dark
    Light
  • PDF

Article summary

Plan availability

Business and Enterprise Scale only

Platform(s)

Web/Browser, Mac app, and Windows app

Related reading

Using SSO and SCIM in Airtable videos 

The admin panel is a centralized tool to help Airtable admins manage their organization’s Enterprise account. Learn how to set up SSO logins for your organization.

SSO and Airtable organizations

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. 

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.

Once configured, SSO only manages logins for organization members—which can be set to optional or required. Unmanaged and external users are not subject to an organization's SSO settings.

Note

Check out our Using organizations support article for more information on user relationships within organizations.

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

Setting up SSO in the admin panel

Note

Be sure to add your associated domain before getting started. As a prerequisite, retrieve the SSO metadata (sign-in URL and x.509 certificate) from your SSO identity provider.

Step 1: Navigate to the admin panel

After retrieving your organization's third-party SSO metadata, navigate to the admin panel and click on the Settings page in the navigation sidebar on the left. Next, click Security & Authentication.

Step 2: Adding SSO

Next, provide your sign-in url, certificate and, click Save.

Step 3: Choose the metadata version

The last configuration step is to determine which IdP provider you are integrating with Airtable. Okta and OneLogin configurations will need to be switched to V1 option in the dropdown. Other partner integrations will use the default V2 option.

Step 4: Save and next steps

All that’s left to do now is click Save. This will open a pop-up asking you if you are sure about the changes. Click Save again to allow the SSO login configuration to occur. Changes may take a few minutes to show up.

After clicking save, the Settings page will reload. To log out all users associated with the configured domain and enforce SSO, please navigate back to the SSO & Authentication section and check/uncheck the box under SSO required. Before requiring SSO for your own email domain, you must first log out and back in with SSO to verify that the metadata you've provided is correct.

From here you can also click Edit if future changes are necessary or if you want to delete the configuration.

SSO dependencies

  • If NameID is required, the value must be the user’s email address.

  • If NameID format is required, the value can be EmailAddress or unspecified.

  • Airtable only allows one set of identity provider metadata per email domain globally. For example, if another enterprise account has configured SSO for a domain (saved sign-in URL and x509 certificate to their admin panel for the domain), subsequent organizations must provide matching information.

SSO Configuration

Requiring SSO in Airtable

NOTE

All collaborators will be automatically logged out after enabling SSO for your organization’s domain.

All users within your organization’s verified domains are required to use SSO with 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 a user's ability to sign in using SSO for that domain. Once the SSO configuration is removed, users can sign in using their email addresses and passwords.

Managing rotating SAML certificates

Note

For more information on how to obtain SAML (x.509) certificates from a specific IdP vendor, we suggest you consult one of the articles listed in the Introduction's Related reading section above.

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

Step 2: Remove the previous certificate

Click the Edit button under the SSO metadata column, then highlight and delete all of the previous SAML signing certificate, called the x.509 certificate in Airtable.

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

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.

(Optional) Step 5: 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.

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

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

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

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

SSO glossary 

Single Sign-On (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).

Identity Provider (IdP)


An identity provider stores and manages users' digital identities for a digital or cloud-based app. An IdP can check identities or just provide a list of identities that another service provider (like an SSO) stores.


Service Provider (SP)

A Service Provider (SP) refers to a company or organization that offers services to customers or clients. In the context of technology or telecommunications, an SP typically provides services like internet connectivity, cloud computing, or managed IT solutions.


Security Assertion Markup Language (SAML)



Security Assertion Markup Language (SAML) is an XML-based framework used for exchanging authentication and authorization data between different systems. It allows users to log in once to access multiple applications without the need for separate usernames and passwords.


Just-In-Time provisioning (JIT)


Just-In-Time (JIT) provisioning refers to the process of granting access to resources or services to users only when they need it, and for the duration they require it. It ensures that users have the necessary permissions and privileges at the right time, reducing the risk of unauthorized access and improving security.


System for Cross-domain Identity Management (SCIM)


System for Cross-domain Identity Management (SCIM) is a standardized protocol that simplifies the management of user identities across different systems and domains. It allows for seamless user provisioning, de-provisioning, and synchronization of user data between various applications and directories.

SP-initiated SSO


SP-initiated SSO, or Service Provider-initiated Single Sign-On, is a method that allows users to access multiple applications or services with just one set of login credentials. Instead of logging in separately to each application, users can authenticate themselves once with the service provider and gain access to all the connected applications seamlessly.

IdP-initiated SSO


IdP-initiated SSO, or Identity Provider-initiated Single Sign-On, is a process that allows users to access multiple applications or services using a single set of login credentials. Instead of logging in separately to each application, the Identity Provider takes the lead by initiating the authentication process and securely sharing the user's identity information with the desired applications.

X.509 certificate


An X.509 certificate is a digital document that serves as a form of identification on the internet. It contains information about the identity of an entity, such as a website or an individual, and is used to establish secure communication over a network.

SSO Metadata 

SSO metadata, short for Single Sign-On metadata, is a set of information that allows different systems to communicate and authenticate users seamlessly.

In the admin panel, SSO metadata refers to the IdP's sign-in URL and x.509/SAML certificate. 

Domain  

In the context of technology or computer science, domains refer to a specific area or subject matter. It represents a distinct field of knowledge or expertise within which certain rules, concepts, and terminology are applicable.

Attributes


An attribute refers to any metadata associated with a user's profile in the IdP and/or the SP, including username, department, and cost center. For a list of user attributes (or fields) supported by Airtable's SCIM user object, see our API documentation.

FAQs

Can I manage user license/seat types via SSO?

Assigning and managing user licenses via your SSO IdP is not currently supported.

Can I set users’ collaborator permissions on workspaces, bases, and interfaces via SSO?

Assigning and managing collaborator permissions on enterprise workspaces, bases, or interfaces via your SSO IdP is not currently supported.

What Identity Providers (IdPs) does Airtable support for SCIM provisioning?

Airtable supports out-of-the-box SCIM integrations for Okta and Microsoft Entra ID.

Can I build custom SCIM integration with Airtable?

With developer support, enterprise customers can build custom SCIM integrations via the Enterprise API for their organization, regardless of membership claim setting. See this API documentation for more information.

How are Airtable user accounts created for users who don’t already have one via SSO?

With Just-in-time provisioning (JIT), user accounts are created when a user attempts to access Airtable using SSO. With SCIM provisioning, user accounts are created once granted access to the IdP.

Can external users be authenticated via SSO?

SSO login requirements apply only to organization members. Unmanaged users and external users are not subject to an Organization’s SSO settings.

Can multiple IdPs be configured for the same email domain?

Airtable only allows one set of identity provider metadata per email domain globally. If another enterprise account has already configured SSO for a domain (saved sign-in URL and x509 certificate to their admin panel for the domain), subsequent organizations must provide matching information.

Does Airtable supply unique Entity IDs?

Some IdPs require separate Entity IDs to establish multiple instances of the Airtable application inside a single tenant. Airtable does not offer unique Entity IDs. Instead, we recommend managing different groups inside a single instance and sharing the SSO metadata.

Can I hold off on adding users to my Enterprise account until SSO has been enabled, or bulk deactivate?

We support programmatic disabling/re-activating users via SCIM for Okta (and only Okta). For additional details and setup instructions, please read our support article.

If SSO is enabled on an existing domain, how do I update it to a new domain?

Note

Keep in mind that admins may need to change the user's email in the IdP before the user can log in through the tile.

Update user email addresses in the Admin Panel using these instructions and then have them sign into Airtable using their IdPs. After signing in, users should see their updated workspaces/bases and email addresses on the home screen.

If another team in my company already uses SSO with Airtable, how does this impact my Business or Enterprise Scale account?

In Airtable, our system expects Enterprise Scale accounts using shared domains—domains federated to multiple Enterprise accounts—to use the same SAML metadata for SSO. What this means is that if your company has existing Enterprise Scale accounts with SSO configured, you will need to coordinate with the admins (or IT department) of the other accounts to obtain the current sign-in URLs, x.509 certificates, and ensure that your users have the necessary access to the Airtable tenant present in your company’s identity provider.

You can configure separate tenants or identity providers for domains unique to Enterprise Scale accounts, as each domain can be configured with its own SAML metadata.

If Okta creates a duplicate account while attempting to update a domain, what do I do?

  1. Delete the new account

  2.  Update the old account’s email address in the Airtable Admin Panel or through the Enterprise API.

  3.  Have the user attempt to log in again through their IdP.


Was this article helpful?