Security Assertion Markup Language (SAML 2.0) is a web security standard for logging users into applications. This enables single sign-on (SSO), which allows users to access multiple applications or websites via a single authentication source. This is perfect for large organizations with enhanced security or user provisioning requirements.

Org admins on our Enterprise plan can enable SAML 2.0 SSO for all managed domains in their organization. This article will explain how.

Please note that this article covers SAML SSO, which is only available to customers on our Enterprise plan. Only Enterprise org admins (typically members of your IT team) will be able to enable SSO.

SSO basics

SSO (or single sign-on) is a way for members of your organization to access multiple applications, including Coda, via a single authentication source. SAML is a web security standard that enables SSO. At Coda, SSO and SAML go hand-in-hand.

Common Terms

Below are some common terms related to SSO. We’ve provided descriptions so you can better navigate the process of setting up SSO.

IdP or Identity Provider: The service or product that manages user accounts, credentials, and the login process. It will send "SAML Responses" to the SP (below) to authenticate users. Examples include Okta and Microsoft Azure.
SP or Service Provider: The service or product that the Identity Provider is sending a "SAML Response" to to log in an end user - that's Coda in this case!
JIT or Just-In-Time Provisioning: Creates new users or updates existing users on the fly. When a user first logs into Coda through SSO, Coda will set up a new account for that user. The account will be updated (including avatar, first name, last name, etc.) on subsequent logins to Coda.
Managed Provisioning: An optional form of provisioning using the SCIM protocol. This allows IT administrators via Identity Providers to create, update, import, deactivate, reactivate, and delete users. Most Identity Providers can use this protocol to automate system provisioning, updating, and deprovisioning for your users automatically.

Set up SAML SSO

Part 1: Enable SSO in Coda

The first step to setting up SSO is to enable it for your org. If you’re an org admin, you can follow the steps below to do so:

Go to coda.io/docs
In the lower left corner, click on More options. Then select Organization settings.
Click into the Authentication tab
Scroll down to the Authenticate with SSO (SAML) option, and toggle this on
Click the Configure SAML button, and note the Settings for identity provider at the top. These parameters will be needed for step #2 in the section below.

Part 2: Create a new application in your IDP

The next step is to create a new application in your identity provider (IDP) for Coda. This will be done within your identify provider’s platform.

The steps below can vary slightly between identity providers. Coda currently supports any identity provider supporting SAML 2.0. Please refer to your identity provider's documentation if you’d like more detail on how to accomplish any of these steps.

Create a new application in your identity provider administration console for Coda, and enable SAML SSO.
Copy the SAML Response URL (see steps above) from Coda into the appropriate location in your identity provider setup.
Ensure your application passes user identity to Coda in "email" format; that is, your Identity provider is sending email-address-like user identities to Coda.
Update your application to pass each user's first name and last name into Coda using parameters named "FirstName" and "LastName".
Save your application and note the resulting Identity Provider Single Sign on URL, Identity Provider Issuer, and X.509 Signing Certificate.
Depending on your Identity provider, you may need to assign users or groups to this new application.

Part 3: Configure SAML SSO in Coda

Finally, you’ll take the information you gathered in Part 2 and finish configuring SAML in Coda.

Return to Coda's Configure SAML page (you should have landed here after the steps in Part 1), then fill out the following fields:
1. SAML provider
2. Identity Provider Single Sign on URL (provided by your Identity provider)
3. Identity Provider Issuer (provided by your Identity provider)
4. X.509 Signing Certificate (provided by your Identity provider)
Click Save

That’s it - SAML SSO is now enabled for all Coda workspaces in your organization!

FAQs

What preparation steps should I go through prior to enabling SSO?

To ensure your users' continued access to Coda, ensure everyone in your workspace(s) are all logging into Coda via their company email address. Only accounts under the organization's list of managed domains will be able log in via SSO.

What happens to existing users when SSO is enabled?

Any user currently logging into Coda via an email address in a domain now managed by your Organization will be able to log in via SSO. They will continue to have access to existing workspaces, folders, and docs regardless of the mechanism they log in with.

Note that users will not be logged out of Coda automatically.

Who can enable and set up SAML SSO for my org?

Only Enterprise org admins can enable and set up SAML SSO. Learn more about org admins here.

Can I sign in with Google instead of SAML SSO?

Yes - if your organization uses Google Workspace identities to log in to Coda, then you can use Google’s built-in sign-in functionality as a login mechanism for Coda. This login method is available to customers on all subscription plans - Free, Pro, Team, and Enterprise. Org members can simply look for the “sign in with Google” option when logging into their Coda account.

Learn about other available sign-in methods here.

Can I have multiple forms of authentication enabled?

Yes, this is particularly useful during a transition from non-SSO to SSO-based authentication for testing or onboarding your company. Learn more about managing authentication options for your org here.

What happens when I deactivate or delete a user?

Deactivation of a user will log that user out (if they're currently logged in), prevent that user from logging back into Coda, and will stop accruing costs for that user (if they are a paid Doc Maker). Their docs will become read-only but could be migrated to new owners by org admins. For info on deactivating users and transferring doc ownership, check out this article.

How can I change ownership of a deactivated user's docs?

If you are an org admin, and one of your user's accounts has been deactivated via SCIM, you can transfer all their owned docs to another user in your organization. Learn more here.