Never Roll Your Own Auth (Part 1)

Starting from the beginning why do we have OAuth? and why was it created?

Introduction

Conceptualized in the early 90s, HTTP was introduced as a lightweight, stateless application protocol for retrieving static hypertext (HTML) documents over a network. A client would issue a GET request, the server would return the content, and then the connection would be closed. Once closed any memory of the requester was lost making HTTP a quick and efficient transfer mechanism without built-in session state in a world with limited “website” interaction.

In more modern implementations we still use the base HTTP protocol, but web applications are now tasked with storing sensitive information that must be accessible to some users and not others. Limiting this access requires verifying what a requester has been granted permission to access and reliably differentiating one requester from another, a complex task layered on top of a stateless protocol with many opportunities for oversight or misconfiguration.

Due to this complexity the mantra “Never roll your own auth” became the recommended guidance, and well-maintained, peer-reviewed frameworks and services became the norm for just about every application because of the risk involved. The motivation to circumvent this obstacle eventually brought about the concept of “borrowed trust” a segmentation of duties that allows applications to move the responsibilities for authentication and authorization away from the individual application or potentially even away from the business and into a dedicated, trusted service.

OAuth and Authorization

By centralizing these responsibilities in a separate authentication and authorization service, any application, inside or outside the organization, can rely on the same source of truth for identity and permissions. That service issues standardized session identifiers or tokens that consistently represent a specific user and what that user is allowed to do at that point in time. When one application calls another, it can pass this token along, allowing the receiving application to verify that it is acting on behalf of the same authenticated user rather than an anonymous system account. Because identity and permissions travel with the request, data custodians can make consistent decisions about what to expose in line with the data owner’s intent, and applications can enforce access control concepts such as the principle of least privilege across boundaries, whether those are internal APIs, micro services, or third-party services.

OAuth, since its inception, was never meant for authentication. it is an authorization framework designed for segmented, delegated access. It allows a centralized authorization service to issue tokens that describe exactly what an application is allowed to do on a user’s behalf. Because those permissions are explicit and tied to the application, development teams can see which systems have access to which data, review and adjust those permissions over time, and quickly revoke or tighten them if something changes. This makes it much easier to keep applications within least-privilege boundaries, support audits, and reduce the blast radius of a compromise without redesigning every individual system.

Organisations quickly realised that this approach can be further extended to support authentication as well, which was facilitated with the help of OpenID connect service, which is built on top of the OAuth Framework. An external identity provider is involved in this specific case that helps verify the user.

Why is OAuth needed then?

For a while, third party applications had to store user credentials for other services outside their domain if they had to obtain a protected resource from that service on the user’s behalf to function. In the modern world where every single application is integrated with one another, one can infer the disadvantage of providing the login credentials for different services to an application that must obtain the protected resource from them. In case of a security breach, it can compromise the user’s accounts in other platforms as well. Beyond the issue of providing credentials, this also means that servers must support password-based authentication, which is inherently unsafe in comparison to modern solutions.

Providing the credentials for other platforms to these third-party applications also allows access to permission on an absolute scale of 0 or 1. Either the client gains absolute access to all information and permissions with the credentials, or they have no permission at all. Which is not a good approach compared to the spread of possibilities that come with the restrictive/selective access approach. OAuth is hence needed as a separate layer of authentication to separate the client from the resource owner. By asking the client to contact the resource server and providing a different set of credentials that is restricted for a specific resource. This new credential is called an access token. It is bound by scope, lifetime and other access attributes that provide strictly only the information necessary and gives control to the user without complications.

How does it work?

From an abstracted view, OAuth works based on providing permissions in the form of tokens. Imagine an example, where you would like to gain some information about a person from a third party who protects their information. The third party will then give you a slip asking you to ask for permission directly from the owner of this information. Once the permission is approved, and is given to you, then you are allowed to access the requested resource. This while being a very simple example of the overall process, does represent the framework well. In the next coming sections, we will dive deep into the roles and the responsibilities of those involved in the framework, and how they interact with each other.

Resources

Eaton, Brian, et al. “The OAuth 2.0 Authorization Framework.” Datatracker.ietf.org, Oct. 2012, datatracker.ietf.org/doc/html/rfc6749.

OktaDev. “OAuth 2.0 and OpenID Connect (in Plain English).” Www.youtube.com, 5 Feb. 2018, www.youtube.com/watch?v=996OiexHze0. Accessed 4 July 2021.