What is SSO, or Single Sign-On? Let’s take a look. SSO is an authentication scheme.
It enables a user to securely access multiple applications and services using a single ID. When SSO is integrated into apps like Gmail, Workday, or Slack, it provides a pop-up widget or login page for the same set of credentials. With SSO, users can access many apps without having to log in each time.
SSO is built on a concept called federated identity. It enables sharing of identity information across trusted but independent systems. There are two common protocols for this authentication process.
SAML, or Security assertion markup language, is an XML-based open standard for exchanging identity information between services. It is commonly found in the work environment. The other common protocol is OpenID Connect.
We should all be familiar with this. When we use our personal Google account to sign into applications like YouTube, we are using OpenID Connect. It uses JWT, or JSON Web Token, to share identity information between services.
Let’s walk through a typical SSO login flow and learn how it works. In this walkthrough, we will focus on SAML. An office worker visits an application like Gmail.
In SAML terms, Gmail in this example is a Service Provider. The Gmail server detects that the user is from a work domain, and returns a SAML Authentication Request back to the browser. The browser redirects the user to the Identity Provider for the company specified in the SAML authentication request.
Okta, Auth0, and OneLogin are some common examples of commercial identity providers. The Identity Provider shows the login page where the user enters the login credentials. Once the user is authenticated, the identity provider generates a SAML response and returns that to the browser.
This is called a SAML assertion. The SAML assertion is a cryptographically-signed XML document that contains information about the user, and what the user can access with the service provider. The browser forwards the signed SAML assertion to the service provider.
The service provider validates that the assertion was signed by the Identity Provider. This validation is usually done with public key cryptography. The service provider returns the protected resource to the browser based on what the user is allowed to access as specified in the SAML assertion.
This completes the walkthrough of a basic SSO login flow. Let’s see what happens when the user navigates to another SSO-integrated application, say, Workday. The Workday server, as in the previous example with Gmail, detects the work domain and sends a SAML authentication request back to the browser.
The browser again redirects the user to the Identity Provider. Since the user has already logged in with the Identity Provider, it skips the login process, and instead, generates a SAML assertion for Workday, detailing what the user can access there. The SAML assertion is returned to the browser and forwarded to Workday.
Workday validates the signed assertion and grants the user access accordingly. Earlier, we mentioned that OpenID Connect is another common protocol. The OpenID Connect flow is similar to SAML, but instead of passing signed XML documents around, OpenID Connect passes around JWT.
JWT is a signed JSON document. The implementation details are a little bit different, but the overall concept is similar. So which one of these SSO methods should we use?
Both implementations are secure. For an enterprise environment where it is common to outsource identity management to a commercial identity platform, the good news is that many of these platforms provide strong support for both. The decision then depends on the application being integrated and which protocol is easier to integrate with.
If we are writing a new web application, integrating with some of the more popular OpenID Connect platforms like Google, Facebook, and Github is probably a safe bet. If you like to learn more about system design, check out our books and free weekly newsletter. Please subscribe if you learn something new.
Thank you so much and we'll see you next time.