What Is Single Sign-on (SSO)? How It Works

595.78k views667 WordsCopy TextShare
ByteByteGo
To get better at system design, subscribe to our weekly newsletter: https://bit.ly/3tfAlYD Checkout...
Video Transcript:
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.
Copyright © 2024. Made with ♥ in London by YTScribe.com