Single Sign-On: OAuth vs OIDC vs SAML— Part 1

Photo by Joseph Barrientos on Unsplash

User authentication is a critical component of online services and applications, enabling users to access secure resources while protecting against unauthorized access. Traditionally, user authentication has been implemented using local authentication, where users have to provide their credentials to access a specific application or system.

However, this approach has its limitations: Developers often find it burdensome to handle local authentication as their primary concern is the business logic, rather than ensuring the security of the user store and preventing it from being compromised. End users also face challenges as they have to repeatedly enter passwords for various applications, which can lead to the creation of weak passwords or password reuse. In addition, administrators are impacted as they need to create user accounts in each application and disable them individually when an employee leaves, which can be a cumbersome process.

Single Sign-On (SSO) provides a solution to address these limitations.

1. Single Sign-On (SSO)

SSO is an authentication process that allows a user to log in to multiple applications or systems with just one set of login credentials, such as a username and password. SSO enables users to authenticate once and gain access to multiple applications or systems without the need to provide their credentials again. This can save time and reduce the need to remember multiple login credentials.

For IT teams, SSO simplifies administration by reducing the need to manage multiple sets of user credentials across different systems. SSO also improves security, as it enables strong authentication policies to be enforced centrally, reducing the risk of credential theft and reuse.

In addition to authentication, SSO solutions often include mechanisms for managing user permissions and access control across multiple applications or services. This typically involves establishing a centralized identity management system, such as a directory service or identity provider, that can maintain a record of user identities and their corresponding roles or permissions. When a user accesses a protected resource or application, the SSO solution can then authenticate the user and authorize access based on their stored identity and permissions.

Key components of an SSO solution:

1. Identity Provider (IdP): The Identity Provider is the system that authenticates the user’s identity and provides the user’s credentials to the service provider. The IdP manages the user’s identity and access privileges.
2. Service Provider (SP): The Service Provider is the system or application that the user wants to access using SSO. The SP relies on the IdP for authentication and authorization.
3. Authentication Protocol: An authentication protocol is a set of rules that define how the IDP and SP communicate with each other to establish trust and exchange authentication information. Common protocols used in SSO include SAML (Security Assertion Markup Language), OAuth 2 and OpenID Connect.

SSO works by using a centralized identity provider, which manages user authentication and identity information, and by providing a secure method of federated authentication, where authentication is trusted across multiple service providers. Note that since each of the trusted service providers have re-authenticate user separately, so signing off from one service provider will not necessarily sigh you off from the other ones.

In this blog post, we’ll explore how Single Sign-On (SSO) works in different protocols, including SAML, OAuth 2.0, and OpenID Connect.

It’s important to note that while OAuth 2.0 and OpenID Connect are related, OAuth 2.0 is primarily an authorization protocol, while OpenID Connect is an identity layer built on top of OAuth 2.0 that provides authentication and identity management capabilities.

By understanding how SSO works in each of these protocols, you’ll gain a deeper understanding of the concepts and technologies that underpin SSO solutions, and be better equipped to choose the right solution for your organization’s needs.

2. OAuth 2.0 and OpenID Connect

Suppose you have a mobile application Health that allows users to access their fitness data from different fitness tracking devices and apps, such as Fitbit. To access this data, your application needs to authenticate the user with each of these services and request permission to access their fitness data.

The typical whole authentication and authorization is depicted in the below diagram.

The above diagram may appear difficult or complicated at first, but there is no need to worry because, we will break down the whole process so that you can understand how everything fits together.

2.1 OAuth 2.0

OAuth 2.0 is an authorization protocol that allows third-party applications to access a user’s data without requiring the user to share their login credentials. It provides a standardized way for users to grant access to their resources on one website to another website or application, without exposing their username and password.

The OAuth 2.0 protocol involves several parties: resource owner, client, authorization server and resource server. Let us look at each of them and other key elements in the diagram above.

Resource Owner

In OAuth 2.0, the resource owner refers to the entity that has control over the resource being accessed by a client application. This entity can be an end-user, an organization, or a device. The resource owner has the ability to grant or deny access to the resource, and OAuth 2.0 protocol provides a mechanism for delegating this authority to a third-party application, known as the client.

The resource owner is typically authenticated by the authorization server (here OpenID Connect is used in conjunction with OAuth 2.0 to provide authentication and identity management) before granting access to the client. The authentication is implemented using OpenID connect. The authorization server issues an access token to the client on behalf of the resource owner, which can be used to access the protected resource.

Client

In OAuth 2.0, the client is an application or service that requests access to a protected resource on behalf of the resource owner. The client can be a web application, a mobile application, a desktop application, or any other type of application that can interact with the OAuth 2.0 protocol.

OAuth 2.0 defines two types of clients:

1. Confidential Clients: These are clients that can keep the client credentials (client ID and client secret) confidential. They can securely authenticate with the authorization server and obtain access tokens. Examples of confidential clients include web applications that run on a server and mobile applications that use a secure storage mechanism to store the client credentials. To obtain a client ID and client secret for use in OAuth 2.0 or OpenID Connect, you typically need to register your client application with the authorization server.
2. Public Clients: These are clients that cannot keep the client credentials confidential. They are typically installed on devices that cannot store secrets, such as mobile or desktop applications. Public clients authenticate with the authorization server using a combination of a redirect URI and a client ID.

It’s important to note that the client has access to the resource owner’s protected resources only if the resource owner grants authorization and if the client presents a valid access token to the resource server.

Authorization Server

In OAuth 2.0, the authorization server is the server that is responsible for verifying the identity of the resource owner, obtaining the resource owner’s consent, and issuing access tokens to clients which the client can use to access the protected resource.

The authorization server is typically owned and operated by the same organization that owns the protected resource.

Resource Server

In OAuth 2.0, the resource server is the server that hosts the protected resource that the client application wants to access on behalf of the resource owner. The resource server can be a web server, a database, a file system, or any other type of server that hosts protected resources. The protected resources can be data, files, services, or any other type of information that requires authentication and authorization to access.

When the client application wants to access a protected resource on behalf of the resource owner, it presents an access token to the resource server. The resource server then validates the access token and verifies that the client is authorized to access the requested resource.

If the access token is valid and the client is authorized to access the resource, the resource server provides the requested resource to the client. If the access token is invalid or the client is not authorized to access the resource, the resource server returns an error response to the client.

Authorization Grant

In OAuth 2.0, an authorization grant is a credential that is used by a client application to obtain an access token from the authorization server. The authorization grant represents the resource owner’s consent for the client application to access a protected resource on their behalf.

OAuth 2.0 defines several grant types that can be used by the client application to obtain an authorization grant from the authorization server. The grant types are:

1. Authorization Code Grant: In this grant type, the client application redirects the resource owner to the authorization server’s authorization endpoint. The resource owner authenticates with the authorization server and grants the client application permission to access the protected resource. The authorization server then redirects the resource owner back to the client application’s redirect URI with an authorization code. The client application then exchanges the authorization code for an access token with the authorization server.
2. Implicit Grant: In this grant type, the client application obtains an access token directly from the authorization server’s authorization endpoint. The client application redirects the resource owner to the authorization server’s authorization endpoint, and the resource owner authenticates with the authorization server and grants the client application permission to access the protected resource. The authorization server then redirects the resource owner back to the client application’s redirect URI with an access token.
3. Resource Owner Password Credentials Grant: In this grant type, the client application obtains an access token by presenting the resource owner’s username and password directly to the authorization server’s token endpoint. This grant type is suitable for clients that have a direct relationship with the resource owner, such as native mobile or desktop applications.
4. Client Credentials Grant: In this grant type, the client application obtains an access token by presenting its own client ID and client secret directly to the authorization server’s token endpoint. This grant type is suitable for clients that access protected resources that are not associated with a specific resource owner, such as API endpoints.

The choice of authorization grant type depends on the security requirements of the protected resource, the type of client application, and the type of user experience desired.

Redirect URI

In OAuth 2.0, a redirect URI (Uniform Resource Identifier) is a URI that the authorization server sends the resource owner to with an authorization code or an access token, depending on the grant type, after the resource owner grants or denies permission to the client application. It is used to return the authorization response to the client application. The client application must register one or more redirect URIs with the authorization server before initiating the authorization flow. The registered redirect URIs must match the redirect URI used by the client application in the authorization request. This is to prevent malicious attackers from intercepting the authorization response and stealing the authorization code or access token.

Access Token

In OAuth 2.0, an access token is a credential that is used by a client application to access protected resources on behalf of the resource owner. The access token represents the authorization granted to the client application by the authorization server.

Access token is not used for authentication, and it does not guarantee that the user is logged in.

Back Channel (highly secure channel) and Front Channel (less secure channel)

In OAuth 2.0, the terms “back channel” and “front channel” are used to describe the different communication channels that are used in the authorization flow.

The front channel refers to the communication channel between the client application and the user’s web browser. This channel is typically used to transmit the authorization request from the client application to the authorization server and to transmit the authorization response back to the client application. The front channel is also used to transmit user authentication credentials when the client application is using the resource owner password credentials grant type.

The back channel refers to the communication channel between the client application and the authorization server that is not visible to the user. This channel is typically used to exchange sensitive information, such as the ID token and access token, between the client application and the authorization server. The back channel is also used to transmit refresh tokens when the client application needs to obtain a new access token after the original access token has expired.

The back channel is considered more secure than the front channel because it is not visible to the user and can be protected using stronger security measures, such as TLS encryption and client authentication. In contrast, the front channel is more vulnerable to attacks such as cross-site scripting (XSS) and cross-site request forgery (CSRF) because it involves communication between the client application and the user’s web browser.

OAuth 2.0 does not provide any built-in authentication mechanisms, such as user authentication or credential management. Instead, it relies on existing authentication protocols such as OpenID Connect, which is built on top of OAuth 2.0, to provide authentication services. Additionally, OAuth 2.0 can be used in conjunction with other authentication mechanisms, such as multifactor authentication or biometric authentication, to further enhance the security of the authentication process.

OAuth 2.0 Request Examples

Let us take a look at some examples in the real world to understand the OAuth 2.0 workflow.

Assuming that a client sends the following authorization request to the authorization server end point accounts.google.com/o/oauth2/v2/auth.

https://accounts.google.com/o/oauth2/v2/auth?
client_id=<yourClientId>
&redirect_uri=<redirectUri>
&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile
&response_type=code
&response_mode=query
&state=abca
&nonce=9ej0sabl5ae

The authorization code from authorization server will be look like

4/0AWtgzh495HaohIx_hFd16Lmuv4qGZPRnw5vUBnZpuu2GFVUKw-BCG2uLH7B8boXqkDhP6A

Next, the client will exchange code for access token by sending the following request:

POST https://accounts.google.com/o/oauth2/v2/auth
Content-Type: application/x-www-form-urlencoded
 
grant_type=authorization_code
&code=4/0AWtgzh495HaohIx_hFd16Lmuv4qGZPRnw5vUBnZpuu2GFVUKw-BCG2uLH7B8boXqkDhP6A
&client_id=<yourClientId>
&client_secret={clientSecret}

2.2 OpenID Connect

OpenID Connect is an open standard for decentralized authentication. It is actually built on top of the OAuth 2.0 protocol to provide a complete SSO solution with identity management capabilities.

OIDC introduces several new features and improvements over the OAuth 2.0 protocol, including:

1. Authentication: OIDC allows for secure and reliable authentication of users through the use of identity providers (IdPs). The IdP can be an external service such as Google, Facebook, or Microsoft, or it can be an internal service managed by the organization.
2. User Information: OIDC provides a standardized way to exchange user information between applications and services. This makes it easier to share user data between different systems without requiring the user to re-enter their credentials.
3. ID Token: It is in the form for a JWT. OIDC introduces a new type of token called the ID token. This token is used to provide the information about the user, such as their name, email address, and other profile information. An ID token may also include other information, such as the issuer of the token, the audience for which it was intended or which application is meant to be the final recipient of an ID token, and an expiration time. The ID token is not meant for authorization, it should not be sent to an API. It is validated and consumed by client to identify the user who has just authenticated.

Final Thoughts

Having learned about OAuth 2.0 and OpenID Connect, we will move on to part 2 where we will explore the SAML protocol. I hope that this blog post has provided you with a useful introduction to SSO and the different protocols that enable it. Thank you for reading!