In this article, we will see about Single Sign-On (SSO) and the 2 protocols which are widely used for SSO namely SAML and OAuth2.This is one of the complicated areas to understand for any programmer and I will try my best to keep it simple.
Single sign-on (SSO) is the process by which a user can log in to multiple applications using a single set of credentials. This is a handy feature and efficient considering the number of websites these days and most of them asking for authentication. We all know that we can’t keep track of so many credential sets for each of the applications. SSO came to the rescue!!!
Instead of establishing their identity over and over, the user is authenticated once and can then access several different services and applications.
An example of one such feature is Google. With a single login, you can access all of their services like Gmail, Photos, Drive, and many more. Other applications also allow users to use Google login for authentication provided they have their system integrated with Identity Providers like Google, Facebook, etc
There are a lot of standards and protocols that provide SSO and some of the famous ones are
- Security Access Markup Language (SAML)
- Open Authorization (OAuth)
- Open ID Connect (OIDC)
- Web Services Federation (WS-Federation)
In the later part of this article, we will be looking at SAML, OAuth2 with OIDC in detail.
There are many benefits of SSO as follows
- Mitigate risk for access to 3rd-party sites
- Reduce time spent re-entering passwords for the same identity
- Simpler administration and use of audit
- Better administrative control
- Improved user productivity
- Better network security
- Decreased attack surface
- Seamless and secure user access
SAML is an XML-based standard for exchanging authentication and authorization data between IdPs and service providers to verify the user’s identity and permissions, then grant or deny their access to services.
SAML is an open standard that has become one of the core standards for SSO. SAML uses an XML document called Assertion( that contains the user authorization) that the Identity Provider sends to the service provider. SAML 2.0 was introduced in 2005 and remains the current version of the standard. SAML 2.0 is specifically optimized for use in web applications, which enables information to be transmitted through a web browser
A sample SAML Assertion in the XML file
- IdP — Identity Provider
- SP — Service Provider
- User — User who uses the system to access service from Service Provider
A typical SAML workflow consists of an IdP, SP, and user. User information is sent as an assertion.
Let us assume that the user has an account with the Idp and has valid credentials in place
Let’s break the above diagram into multiple steps for easier understanding
- The user goes to the Service Provider and clicks on SAML login
- The SP redirects the request to the Identity Provider
- The Identity Provider shows the login page to the user to enter credentials
- Upon entering the credentials, the SAML IdP verifies the credentials in its Active Directory or Database
- Once verified, a SAML response is sent with Assertions in XML format as seen above
- Then the user will log in to the application
OAuth is a newer standard than SAML, and it was jointly developed by Google and Twitter beginning in 2006. It was developed in part to compensate for SAML’s deficiencies on mobile platforms and is based on JSON rather than XML. OAuth2 uses JWT tokens widely and hence is lighter and faster than SAML.
Before we deep dive into OAuth2 and OIDC, let’s look at the terminologies used
- Authorization Server — (eg: Google)
- Resource Server — (eg: Bitbucket)
- Resource Owner — User who uses the system to access service from Resource Server (eg: Bitbucket user)
The OAuth2 protocol allows the authorization server to issue access tokens to third-party applications after getting the consent of the resource owner (user) These access tokens are used by third-party applications like Bitbucket, Slack, etc to access resources provided by the resource server.
You must have already used OAuth2 if you have signed up for a new application and agreed to import contacts from Google / Facebook etc. You might have used a feature that has asked you to share your post or photos on Facebook / Instagram etc. This is the OAuth2 protocol, which provides secure delegated access without sharing the credentials
OAuth2 is used only for Authorization and not for Authentication
With OpenID, the user’s credentials are used only by the Authorization server after the browser routes the request. Upon verification, an access token is issued to the user by which the user can access multiple applications without sharing their credentials with every application.
You must have already used OIDC if you have signed in to applications using your Google / Facebook / Twitter login. OpenID Connect is an open standard that organizations use to authenticate users.
OIDC is used for Authenticating the users
OAuth is an open-standard authorization protocol that is used to Authorize users and OIDC is used to Authenticate users. OIDC sits on top of OAuth 2.0 to add information about the user and enable the SSO process. It allows one login session to be used across multiple applications. For example, as seen below, you can use the social media login to access the applications without creating an account in the application
OAuth2 flow with OIDC Integrated
The above diagram explains the whole process that happens when you log in to an application using Google. The number of steps might look complicated but this overall process ends in a matter of milli seconds to seconds. Let’s break it down step by step.
Assume that the user already has a login account with Google
- The user goes to the Bitbucket page to login
- User clicks on Sign in with Google
- The browser redirects the user to the Google login page
- Google shows the credentials page for users to enter credentials
- The user enters the google credentials and clicks submit
- Google verifies the credentials and generates Access Token and sends it to the browser
- The browser embeds the Access Token (Bearer Token) in the Authorization Header and sends the user’s login request to the BitBucket server
- The Bitbucket server will contact Google to verify the access token and responds to the browser
- Now the user logins to the Bitbucket application
Although SAML may seem superior in enterprise settings, there are some scenarios where OAuth makes sense.
- Identity management for a government application: The confidential, sensitive nature of government data needs to have stronger security and SAML will be apt for this scenario. For eg: The Singapore Government uses a SAML-based system called SingPass as a digital login for its residents to use all the government-based services
- User experience is a priority: OAuth2 works best for User experience as it works well on mobile. And it’s lightweight.
- Mobile and consumer applications: OAuth2 works well on mobile, and consumer applications as the sessions tend to be shorter
- Virtual desktop infrastructure (VDI) implementation: Use SAML. The VDI will be used by a number of employees within the enterprise.
- Temporary access is needed for resources: OAuth2 works very well for temporary access as it is intended for this purpose
In this article, we saw the types and benefits of SSO. Then we dived deep into two of the famous SSO protocols namely SAML and OAuth2. When exploring OAuth2, we saw what is the minor difference between OAuth2 and OIDC and then saw the use case with both of them combined. The article ended with which protocols can be used for some use cases.
I have tried my best to explain SSO, SAML, and OAuth2. Hope you have enjoyed this article and thanks for reading.!!!
I work as a freelance Architect at Ontoborn, who are experts in putting together a team needed for building your product. This article was originally published on my personal blog.