Configuring SSO with ADFS

Last updated: September 17, 2026

Plan availability

Business and Enterprise Scale only

Platform(s)

Web/Browser, Mac app, and Windows app 

Related reading

Set up ADFS SSO with an email attribute

Use this setup for a separate login identifier and email address, or to onboard external users. If you already have working SSO, start with Upgrade an existing SSO configuration. Basic email-NameID SSO instructions are in the collapsed section below.

  1. Open the Airtable SAML application in ADFS. You’ll need access to its SAML settings and your organization’s Airtable SSO settings, including a verified domain for the configuration.

  2. Create a claim containing the user’s real email address separately from the NameID claim. If its outgoing name is http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress, use that complete value as Airtable’s Email attribute name.

  3. Choose a stable, unique NameID. For a non-email identifier, use Unspecified as its format. If you keep an email or UPN as the identifier, confirm whether that value will change during email or domain changes.

  4. In Airtable, enter the IdP’s sign-in URL and X.509 certificate. Select V2, set Email attribute name to the exact outgoing attribute name from step 2, and save. See the Airtable setup instructions.

  5. Copy the two values from the saved Airtable configuration into ADFS:

    Airtable field

    ADFS field

    Reply URL (ACS)

    SAML 2.0 WebSSO URL / ACS endpoint

    Audience URI (Entity ID)

    Relying party trust identifier

    Use the configuration-specific pair. Don’t combine the new ACS URL with a legacy Entity ID. If your IdP validates Airtable’s signed requests, use the corresponding V2 Airtable metadata/certificate.

  6. Assign a test user and launch Airtable from the IdP. Complete any email confirmation and linking steps, then confirm the correct email and existing account content. Test Sign in with Single Sign On from Airtable as well.

  7. Decide whether to turn on SSO required after testing. It is not required to enable SSO. For external users, follow the onboarding steps; the first unlinked sign-in starts from the IdP.

If your preconfigured app doesn’t expose the required attribute and endpoint settings, contact Airtable Support before changing an existing integration. If you use SCIM, preserve provisioning and align its userName mapping with the SAML NameID as part of the upgrade.

Basic ADFS SSO with the legacy ACS URL

Use this path when the NameID is each user’s Airtable email address. Leave Email attribute name at Use NameID (default).

Use https://airtable.com/auth/ssoCallback as the ACS URL and the legacy Entity ID shown in the saved configuration: 

  • https://airtable.com/sso/metadata.xml for V1

  • or https://airtable.com/sso/metadata0418.xml for V2

Step 1: Adding a “Relying Party” using the ADFS setup wizard

  1. In the left navigation pane of ADFS, select Relying Party Trust, then Add Relying Party Trust, then Start.

    Picture1.png

  2. Click the radio button option to Enter data about the relying party manually, then click the Next button.

    Picture2.png

  3. You can enter whatever display name you want (like "Airtable") and any optional notes—then click the Next button again.

    Picture3.png

  4. Next, pick ADFS profile as the configuration profile.

    Picture4.png

  5. Click the Next button on the Configure Certificate page.

    Picture5.png

  6. For the Configure URL page, check the Enable support for the SAML 2.0 WebSSO protocol box and paste in the ACS URL shown in your Airtable SSO configuration dialog (for legacy configurations: https://airtable.com/auth/ssoCallback).

    Picture6.png

  7. For the Configure Identifiers page, add the Entity ID shown in your Airtable SSO configuration dialog as a “Relying party trust identifier.” For legacy configurations, use https://airtable.com/sso/metadata0418.xml.

    Picture7.png

  8. On the Configure Multi-factor Authentication Now? page, choose the "I do not want to configure multi-factor authentication settings for this relying party at this time." option.

    Picture8.png

  9. On the Choose Issuance Authorization Rules page, select the "Permit all users to access this relying party" option.

    Picture9.png

  10. On the final screen of the wizard, check the "Open the Edit Claim Rules dialog for this relying party trust when the wizard closes" box. This will open the Edit Claim Rules dialog once you click the Close button.

    Picture10.png

Step 2: Adding a “Claim Rule” in ADFS

  1. Once in the Edit Claim Rules dialog, go to the Issuance Transform Rules tab, then click the Add Rule button. This will open up the Add Transform Claim Rule Wizard.

    Picture11.png

  2. From within the Add Transform Claim Rule Wizard, you will be asked to Choose Rule Type. From the Claim rule template dropdown, select the Send LDAP Attributes as Claims option.

    Picture12.png

  3. Give your claim rule a name (like "LDAP Email") and map the E-Mail-Addresses LDAP attribute in the left column to the E-Mail Address outgoing claim type in the right column.

    Picture13.png

  4. You'll need to add another Transform Claim Rule here. This time, select the Transform an Incoming Claim option from the Claim rule template dropdown.

    Picture14.png

  5. Give this claim rule a name (like "Email Transform"), then set the following values:

    • Set Incoming claim type to E-Mail Address

    • Set Outgoing claim type to Name ID

    • Set Outgoing name ID format to Email

    • Select the Pass through all claim values radio button

  6. Airtable also supports the following additional attribute maps:

    • "urn:oid:2.5.4.4" -> Basic Information; Last Name

    • "urn:oid:2.5.4.42" -> Basic Information; First Name

  7. When you're done, click the OK button to save this Claim rule, and OK again to exit the Transform Claim Rule Wizard.

The claim rules above send the user’s email address as the Name ID (Airtable’s default requirement).

  • If your organization uses a non-email identifier (such as an employee ID) as the Name ID, map that LDAP attribute to Name ID instead.

  • Additionally send each user’s email address as a SAML attribute, and configure that email attribute in Airtable’s SSO settings — see SSO dependencies for more information.

Step 3: Editing Airtable’s relying trust properties in ADFS

  1. Under the Advanced tab, select SHA-256 as the secure hash algorithm. Then, copy the following X.509 certificate and save it to something like airtable.crt:

    -----BEGIN CERTIFICATE-----
MIIDUDCCAjgCCQDZhZQnLjon1zANBgkqhkiG9w0BAQsFADBqMQswCQYDVQQGEwJV
UzELMAkGA1UECAwCQ0ExETAPBgNVBAoMCEFpcnRhYmxlMRUwEwYDVQQDDAxhaXJ0
YWJsZS5jb20xJDAiBgkqhkiG9w0BCQEWFXNlY3VyaXR5QGFpcnRhYmxlLmNvbTAe
Fw0xODA0MjAyMzI1NTJaFw0zODAxMDEyMzI1NTJaMGoxCzAJBgNVBAYTAlVTMQsw
CQYDVQQIDAJDQTERMA8GA1UECgwIQWlydGFibGUxFTATBgNVBAMMDGFpcnRhYmxl
LmNvbTEkMCIGCSqGSIb3DQEJARYVc2VjdXJpdHlAYWlydGFibGUuY29tMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3ORK7AMKzczh2JXWzKq4vI8jaHZ+
GcqNF6WHExEtPWrIN9Rpo/ogguZZ3BJs6dtUkPAt5M722BkJUggMFj9LREK8Vcl/
+3ffXJUhcIcatpXsq3iQE9Otbc5aFxSt6FKg410snTeI+VVYJ3cOgOQzO1ZEBjj8
DA1iB0w9ICd9DRj3LXa9S55B1q9TRPJwicbT9SwMJlF/VqSilS+QhDqhPiSrja7X
WipQN3y0HwhqNlC3oPlBewjvyTLrmR6IGstxm01Wxj2JbHkGA9MgZKCMV5sQgA68
2DoIvbhDPOA/E5vjL5JwsyU/LjDhm0cfX6RiZ/OywGbs+KawLe29As+V9wIDAQAB
MA0GCSqGSIb3DQEBCwUAA4IBAQC/ewo5+TeEGOnT6ko0X1C+Yduiu1IqXZc8Zw6w
+9k06hg9IbO7u9VCevbKI/CwG4Il/6URGwqKKmU3kyUNsRmdsFMHWWrzeCPqa+94
FbRiaTjZcoV3I5++CjObWJgatIC9MLTxVKnQaGDSTk+dxwXOIANZ+iCh3SKQTRM+
r0YZUSIM+5hXWccsdnPtp+2GczzbUJ0rCWA/iQ0OwZrWpU0/XPnzjQguVrdIPDIh
3xPeT40txEg+mHAajGFfh6XhV86P8185fZ8R6G+gehqfByToNiCbb0BqipOaA+ej
SDYXqYh7jx3D6X/gV9MnyGBVRy1t6COzk+OZDosPhkTFgclt
-----END CERTIFICATE-----

  2. Under the Signature tab, click Add, then upload airtable.crt. Click OK to complete. Next, you'll need to export your token signing certificate. In ADFS, click the Certificates folder, then Token Signing certificate.

  3. Click the Details tab, then click the Copy to File button.

    Picture15.png

  4. Next, export as a Base-64 encoded X.509 (.CER) file.

    Picture16.png

  5. After that, submit your sign on URL and x.509 certificate (you can open the .cer file in a text editor and copy-paste it in) following the steps in this article.

  6. After you have completed all of the steps, you should be able to log in from https://airtable.com/sso/login.

Troubleshooting

If you are still having issues, click Get Help on the lower right corner to contact Airtable Support.

Please include any relevant ADFS logs (Control Panel → Administrative Tools → Event Viewer → Applications and Services Logs → AD FS → Admin).

FAQs

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.

What Entity ID do I use when configuring SSO in Airtable

Use the Entity ID shown in your SSO configuration dialog in the admin panel.

For basic SSO, use the legacy Entity ID for the saved metadata version. For the email-attribute setup, use the configuration-specific Entity ID. Copy the displayed pair rather than choosing based on whether the IdP requires a unique identifier.