OAuth 2.0 Introduction

Emmanuel Gautier · February 27, 2023

OAuth is an open standard protocol that allows applications to securely access a user's data without requiring the user to share their login credentials. It enables users to grant third-party applications access to their resources such as personal information, documents, and images stored on another app, without giving the third-party app access to their passwords or other sensitive information.

OAuth 2.0 Architecture

The OAuth protocol works by separating the authentication process from the authorization process. When a user wants to access a resource from a third-party application, the third-party application sends the user to the resource owner (e.g. a social media site) to authorize the request. The resource owner authenticates the user and then returns an access token to the third-party application, which can be used to access the requested resource.

This protocol has become a popular method for implementing authorization and authentication in modern web and mobile applications. It's used by many popular services, such as Google, Facebook, and Twitter, to provide access to their APIs for third-party developers and to implement authentication on several websites.

OAuth2 Principles

Long story short, here are some of the main principles of OAuth2:

Authorization, not authentication: OAuth2 is designed to allow a user to grant access to their resources to a third-party application without having to share their login credentials with the third party. In OAuth2, the user is authenticated by the resource owner (e.g. a social media site), and then the third-party application is authorized to access the user's resources.
Token-based authentication: OAuth2 uses access tokens to authenticate requests. The access token is issued to the third-party application by the resource owner and is used to access the user's resources.
Scope-based authorization: OAuth2 allows the resource owner to grant the third-party application access to only the specific resources that the user wants to share. This is done through the use of scopes, which define the level of access that the third-party application has to the user's resources.
Separation of concerns: OAuth2 separates the concerns of authentication and authorization. This allows different parties to focus on their areas of expertise and enables the creation of more secure and scalable systems.
Client Registration: OAuth2 requires third-party applications to register with the authorization server before they can be granted access to the user's resources. This provides a level of security by ensuring that only trusted applications are allowed access to the user's resources.

Overall, OAuth2 is designed to provide a secure and scalable way for third-party applications to access a user's resources without requiring the user to share their login credentials. By following these key principles, OAuth2 provides a powerful framework for building secure and scalable systems.

OAuth vs SAML

OAuth and SAML are two popular authentication and authorization protocols widely used in modern web applications. While both protocols serve a similar purpose of granting access to a user or an application, they differ in their design and approach.

SAML (Security Assertion Markup Language) is an XML-based protocol used for exchanging authentication and authorization data between parties, particularly between an identity provider (IdP) and a service provider (SP). SAML is primarily designed for single sign-on (SSO) and is commonly used in enterprise environments to enable employees to access various web applications with a single set of credentials. SAML is also used to provide federated authentication across multiple domains.

Although both OAuth and SAML provide similar functionality, OAuth is now more widely used today because of its simplicity, flexibility, and simpler support for new usages with web apps (SPA) and mobile apps. For several years, the ecosystem around OAuth and more globally around JWT tokens management gains with support from various components like proxy, gateway, ... etc making SAML sometimes more costly to integrate due to lack of ecosystem.

Client Registration Process

Before a client can access a user's resources using OAuth2, application's developers must first register with the authorization server. The client registration process may depends on the authorization server owner but involves at least the following steps:

Client Registration: The client registers with the authorization server by providing information about the client, such as the client ID, client secret, and redirect URIs.
Authorization Server Owner Approval: The authorization server owner reviews the client registration request and approves or denies the request.
Client Authentication: The client authenticates first time with the authorization server using the client ID and client secret.

OAuth 2.0 Architecture

Most of the time, redirect URIs and client are different for each environment (development, staging, production) to ensure that the client is only allowed to access the user's resources from specific environments. As a developer, you may repeat the client registration process for each environment.

Lexicon

Let's define some key terms used in OAuth 2.0:

Resource Owner: The entity that owns the resources that the third-party application wants to access. This is typically the user.
Resource Server: The server that hosts the resources that the third-party application wants to access.
Client: The third-party application that wants to access the user's resources.
Authorization Server: The server that issues access tokens to the client after the user has authenticated and authorized the request.
Access Token: A token issued by the authorization server that the client uses to access the user's resources.
Scope: A parameter that defines the level of access that the client has to the user's resources.
Grant Type: The method used by the client to obtain an access token from the authorization server. There are several grant types defined in the OAuth2 specification, such as authorization code, implicit, client credentials, and resource owner password credentials.