Configuring SSO in the admin panel

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. 

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.

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.

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.

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

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.

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.

NOTE

All collaborators are automatically logged out after selecting SSO as required for their organization’s domain.

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.

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

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.

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.

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.

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.

Recheck the SSO required option. In some cases, your organization may leave this off, in which case, you can skip this step.

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

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

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

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.

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.

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

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.

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.

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.

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.

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.

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.