Everything I Wish I Had Known About Enterprise SSO

Sorry xkcd fans, no mouseovers on Medium. Go check it out at lightstep.com/blog

Single sign-on (SSO) makes it easy for users to get started with an application. For enterprise applications, support for SSO is critical: many corporate security policies require that all applications must use approved SSO methods. While the experience of using SSO is simple, its specification is anything but simple. It’s easy to get lost in a sea of jargon: OAuth 1.0, 1.0a, 2.0, SAML, JWT, OpenID, OpenID Connect, JIT, and tokens: bearer tokens, refresh tokens, access tokens, authorization tokens, skeeball tokens. Standards documents are too specific to allow you to generalize, and content from vendors is designed to make you think it’s all too complicated to do yourself. When I was tasked with building SSO for LightStep, I spent days researching. Below are some lessons that I hope will save you time and headaches. It boils down to knowing your market, your vocabulary, your standards, and your platform.

Know your market

This is both the most important and most time consuming task before designing your application’s SSO. All other considerations are moot if you don’t understand the ways (there can be more than one) your customers are already managing their accounts. It is worth probing a bit deeper than simply asking “What do you use for SSO?” because you may discover that there are multiple options available.

Some important questions to consider are:

• Do they use Gmail or Google Apps?
• Does everyone in the company have an account with Github using their work email address?
• Do they have a vendor for Single Sign-on such as Okta, OneLogin, or Ping Identity? Do they have an LDAP/Active Directory server or other internally managed Identity Provider?
• How do they log in and manage user accounts with their other SaaS vendors?

Know your vocabulary

There is a lot of jargon in SSO standards, tutorials, and documentation, including the ways of referring to the parties in an SSO transaction. Sometimes the same term is used with different meanings! For example, I have seen Service Provider used to refer to at least two distinct roles in the authentication transaction.

These are the three most important concepts in SSO:

• The User (or Principal or Client) is the individual whose identity is being verified so that you can grant them access to your application.
• Your application is the Service Provider (or Consumer or Relying Party), which uses a third-party to verify the User’s credentials.
• The Identity Provider (or Server or OpenID Connect Provider) is the authority responsible for verifying the identity of the User and furnishing claims or assertions of the User’s credentials to the Service Provider.

Know your standards

There are many shared authentication and authorization schemes and standards, though the term “standard” is often used loosely. Some sound a lot alike but are actually quite different. Here are the important standards used in Enterprise SSO:

• SAML: Security Assertion Markup Language is an XML-based data format and protocol for user authentication. SAML has been around the longest, and it is more common in larger enterprises. Even companies such as Google that have embraced newer standards still support SAML-based workflows for SSO.
• OpenID: OpenID 1.0 and 2.0 are obsolete standards for maintaining a digital identity with an Identity Provider, which would verify your identity to other websites, also known as Service Providers. They have been replaced by OpenID Connect.
• OpenID Connect is the latest standard authentication protocol and data format from OpenID. It was originally based on the design of Facebook Connect and has now been embraced by Google and other large providers of user authentication. The standard relies on the OAuth 2.0 protocol for the User to grant the Service Provide access to their identity data, and JSON Web Tokens (JWT) to package identity and other claims in the token payload.
• OAuth 1.0a was deprecated in favor of OAuth 2.0 but is still in use by large companies, including Twitter. Revision A was released to close security holes in the original standard. It is considered more secure but more difficult to implement than its successor, OAuth 2.0.
• OAuth 2.0 is the current OAuth standard as of this writing. OAuth 2.0 introduced a wider variety of data flows to support clients beyond the standard in-browser web application. OAuth 2.0 also removed the requirement for the client to encrypt the request, falling back on the built-in encryption of https communication. Even with the updated protocol, OAuth is an authorization scheme, not an authentication scheme. When you use OAuth for authentication, you are using it to get authorization from the User to access their credentials stored with the Provider, and you are trusting the provider to have verified those credentials.

Know your platform

Many of these standards and protocols were developed with a focus on the canonical web app in a browser. If your application does not fit that mold, you may have fewer choices of how you implement SSO.

• Mobile: Mobile Apps do not have access to the stored cookies in the phone’s web browser when making http requests in a webview, but these cookies are how Identity Providers maintain the logged-in state of the User. Without that state, the mobile app may be able to use the credentials from the Identity Provider, but the User will have to log in again for each new app, taking you from single sign-on to everytime sign-on. Newer protocols, such as OpenID Connect, are working to support native mobile applications without this limitation through NAPPS support. NAPPS provides capabilities that enable the application to register a custom callback URL to support a flow from the app into and back out of the core system web browser.
• Single-page apps: The standard SSO authentication flows involve at least one communication step between the application’s server and the Identity Provider, but in a single-page app you may want to avoid the server altogether. Even if you don’t, you may not want to go through losing the application state through the standard redirect-based approach. This is where the alternative flows for OAuth 2.0 and OpenID Connect come in. You need to be even more careful when implementing the serverless flows, since the entire flow is happening in client-side JS and you don’t have the out-of-band server-to-server channel to exchange secure credentials. For this reason, big Identity Providers such as Google want you to use their JS toolkits.

I hope you found the distillation of my research on SSO useful. If there’s anything I missed, feel free to add to it in the comments and I will add it to the post and attribute it to you. Now that you have a solid foundation of SSO in enterprise, the next step is product design. Good luck!

Originally published at lightstep.com.