Explore

Building Coda’s single-sign-on

Welcome to the world of authentication through single-sign-on (or lovingly known as SSO)!

Originally published 12/11/2019 by Jaime Hwacinski

Most blogs you read from Coda range from our 50,000ft view of the world to a single new feature that we are excited to share with you. This blog is about a somewhat dry, yet highly critical Enterprise feature, and how we made decisions during development.

Welcome to the world of authentication through single-sign-on (or lovingly known as SSO)!

An abridged history of authentication.

What does authentication actually mean? Authentication is rooted in how we trust one another. We need to be able to prove we are who we say we are.

The notion of authentication dates at least as far back as the Ancient Roman Empire, where soldiers would use watchwords to prove loyalty. Watchwords, passwords literally etched into a block of wood, were physically transported from place to place. Unfortunately for those soldiers, watchwords were slow, easy to steal, and scenario-specific.

Proving your identity became increasing more complicated as the digital age evolved and people all over the planet started connecting via the Internet. Without the physical manifestation of a password, how do you prove you are YOU? We rely on a short string of characters—a digital password.

Protecting and using that little password has evolved many times, from using a salted hash (no, it’s not a morning breakfast food) to captchas (those things you thought were mini-games for choosing the images with birds in them) to biometrics (which movies portray cooler than reality). The key is to remember that all authentication technology will evolve over time to ensure your identity is protected and to keep pace with fast changing technology in the era of SaaS.

At Coda, your company’s employees and content are serious business to us. We are thrilled to provide the ability to authenticate with Coda via SSO through the open standard Security Assertion Mark-up Language (SAML) 2.0 protocol.

Building SSO behind the scenes.

As Coda’s popularity in large organizations has grown, the requests to IT-manage Coda like other corporate software has also increased. Even though our Business Platform team just shipped our billing platform and the new Workspace/member model, we knew we needed to provide it fast.

As context, our current authentication method only supports customers signing up with their Google accounts. As a relatively new company, we leveraged a well known authentication and permission provider to get up and running fast. We started by leveraging Google Authentication, which also provided the ability to use a known file system solution for storing access permissions, providing full text search, etc. To provide a new authentication mechanism for Coda, we needed to re-examine our existing Google Drive integration, where we authoritatively store doc access control lists (ACLs) or who has what level of access to the doc, and how workspaces/domains are managed.

Every possible SSO choice was analyzed and discussed (in a Coda doc, of course). After we answered the higher-level questions, we drew out an end-to-end outline to map user experience. These scenarios included a set of UI mocks that helped us brainstorm ways to support both Google Drive ACLs and Coda ACLs.

Ultimately, from a prioritization perspective, SSO helped us accomplish a few things:

Build some of the common components that we will leverage for enabling other login mechanisms in the future

Slipstream into existing best practices for companies that use a single-sign in solution

Facilitate login via Azure AD & Okta for Coda’s Enterprise Customers

Storing ACLs.

By introducing SSO, our users would not be signing in via Google, and we would not have a Google authentication token for them — meaning we could not store ACLs in Google Drive for these users. So, when creating a new doc or changing the sharing settings for a doc, we’d need to provide a way to ensure the user has permission to edit permissions on the doc.

We had a few models to consider, each with a list of effects and pros and cons. We took our investigation to a weekly meeting called the “Coda Catalyst” to pull feedback from other Codans through the

topic voting template⁠

and the

sentiment template⁠

. (Highly recommend using these templates for gathering quality feedback.)

⁠

After incorporating the feedback we received, we landed on a model that looks at the user account and Organization settings to determine where to store the ACLs for the doc. This model left us with the most flexibility to extend the experience in future scenarios and also continues the current benefits of Google Drive integration for existing Google users.

So now a user may see docs in a workspace whose ACLs are stored in either Coda or Google (though, never both at the same time).

⁠

Sounds great. How do I setup SSO?

Through our Enterprise plan, your company can now choose to manage Coda in your app portfolio with your favorite identity provider (e.g., Okta or Azure Active Directory).

⁠

We will walk your Organization admin through SSO setup and management. If your company chooses to use SSO, your document permissions will be stored in Coda instead of Google Drive. Find

more information here⁠

What’s next?

The Business Platform team is working on many great new features for Workspaces and Members. We are also working on simplifying the ability to add and remove members in Coda with the SCIM protocol … but that’s another story. Stay tuned!

Thanks to Christopher Eck.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.