Introduction

OAuth is an abbreviation for “Open Authorization”. It is a standard authentication and authorization protocol that allows users to grant third-party applications limited access to their resources without having to share their credentials with these applications.

OAuth is typically used for delegated access to resources on behalf of a user. For instance if you visit a third party application (som-app.com) that asks you to provide access to your linkedin accounts in order to be able to invite them on to “some-app.com”. You would be provided the linked in login screen where you authenticate yourself and “some-app.com” gets your linkedin accounts.

Another use case of OAuth (or OIDC specifically) is the ‘Sign In With Google’ or similar buttons found in various web applications on the internet. These applications don’t need you to explicitly login on their own website or create an account. Rather, they depend on existing systems to authenticate you and use this to autmoatically log you into their system.

This is both convenient and secure and is therefore widely implemented in most modern day systems. Apart from being convenient, complex modern day systems that often comprise of various different services that work together, must have the ability to authenticate users automatically without having to prompt them over and over again. For instance if you sign in on gmail.com, you would automatically be logged in to youtube.com although you did not really sign in.

The current version of OAuth is OAuth 2.0. This is the successor to OAuth 1.0 and is widely used and supported. It is much more simplified and supports multiple ways of authentication, supporting multiple clients. In this blog, we will be talking about OAuth 2.0

Concepts

The OAuth protocol typically includes four entities

• Resource Owner

  Refers to the user who owns the data and gives consent for access to this data to a third-party application.

• Client

  Client is the application or service seeking access to the user’s data.

• Authorization Server

  Represents the server responsible for authenticating the user and generating access tokens once the user grants permission.

• Resource Server

  Signifies the server hosting the protected resources (data) that the client aims to access.

OAuth has multiple flows (or grant types) and the flow to use would depend on the specific use case. However, for simplicity let’s take a look at a typical OAuth flow that would be used by a user accessing a web application on a browser.

1. The client (third party application) seeks authorization from the resource owner (user) to access some information owned by the user.
2. The resource owner approves client’s access to the information.
3. The client obtains an authorization grant from the authorisation server (responsible for authentication).
4. Using the authorization grant, the client requests an access token from the authorisation server.
5. The authorization server verifies the client’s authenticity and issues an access token.
6. Using this token, the client gains access to the protected resources hosted on the resource server (server that hosts the data).

Types of Authorization Grants

There are multiple ways in which an OAuth based system can grant access to a user’s data. Which one to use depends on the specific use case or context in which the data has to be accessed. Let’s drill down further into the types and What a typical use case for each type is.

• Authorization Code Grant

  Use Case: Web Applications

  Description: Suitable for server-side applications where the client can securely store a client secret. It involves a two-step process. In the first step, the server obtains an authorization code and in the next step, it exchanges this for an access token.

• Implicit Grant

  Use Case: Web Applications (Single Page Applications)

  Description: An older and more obsolete grant type that relies on a direct access to the token. Intended for applications running in a web browser where the client can’t store secrets securely. It involves obtaining the access token directly, without an intermediate authorization code.

• Resource Owner Password Credentials (ROPC) Grant

  Use Case: Legacy or Highly Trusted Applications

  Description: Allows the client to exchange the user’s username and password for an access token directly. It should be used cautiously due to security implications and is typically recommended only for highly trusted clients.

• Client Credentials Grant

  Use Case: Machine-to-Machine Communication

  Description: Suitable for non-user-specific operations where the client is the resource owner. The client uses its own credentials (client ID and client secret) to obtain an access token.

• Refresh Token Grant

  Use Case: Token Renewal

  Description: The tokens are generally short lived for security reasons in order to minimize damage in case of theft. A refresh token grant is used to obtain a new access token using a refresh token that was obtained earlier, without requiring the user to do a re-authorization. This is helpful for maintaining long-lived sessions and avoiding repeated user authentication.

• Device Authorization Grant (Device Flow)

  Use Case: Devices with Limited Input

  Description: Used for devices with limited input capabilities (e.g., smart TVs, streaming devices). The user interacts with a separate device to grant permissions, and the device obtains an access token.

• JWT Bearer Token Grant

  Use Case: Exchanging a signed JWT token for an access token from the authorisation server

  Description: Allows a client to authenticate using a JSON Web Token (JWT) assertion instead of a client secret. The client includes a signed JWT as a means of proving its identity.

• Proof Key for Code Exchange (PKCE)

  Use Case: Mobile and web applications (SPA) running on client side

  Description: The use case here is similar to that of the Implicit Grant where a server is not involved and the authorisation is carried out entirely by the client. PKCE adds an extra layer of security for public clients to protect against authorization code interception.

Single Sign On (SSO) and Open Id Connect (OIDC

Single Sign On is a way to provide secure and seamless access to a user across systems that trust each other without a user having to authenticate separately on each one of them. This is where OIDC comes in.

OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0 providing an identity layer for user authentication. While OAuth 2.0 is primarily an authorization framework, OIDC extends it to include authentication, allowing applications to obtain information about the end-user and then use it further in their own system. This serves as a way to implement SSO (Single Sign On).

OAuth is a mechanism through which an a third party obtains access to a user’s resources with their consent from a first party app. OIDC on the other hand is a mechanism through which a third party relies on a first party to authenticate a user and pass on some identity information such as username, email etc. This is then used further by the third party to identify a user and allow access to resources on their own system.

OIDC is an authentication standard providing seamless authentication and uses the OAuth standard for authorisation. The difference is subtle, but important

Tools that implement OAuth

While OAuth and OIDC are open standards and one can implement solutions for them on their own, more often than not, you would be better off using an off the shelf solution since they make the job a lot easier, are a lot more robust at handling edge cases and would free you up to focus on building your core product. Some benefits provided are

Handling various forms of authentication and authorisation defined as per the OAuth and OIDC standards.
User management
Out of the box integration with popular enterprise IDP’s such as Active Directory as well as google, facebook etc.
Flexibilty to build out your own UI or use out of the box UI.

Some popular solutions are Okta, Auth0, Keycloak, AWS cognito.

Conclusion

A good understanding of OAuth and OIDC is important for modern real world systems. It is critical for ensuring security as well as a seamless experience for your users while accessing first party as well as third party systems together. This is necessary both from the point of usability as well as trustability.

This blog summarizes some of the most essential concepts in OAuth and OIDC, but is by no means a comprehensive one. There is a lot more to this topic and it cannot be covered in a single blog. However, this is a good starting point that you can use to build up further on.