The Nuts & Bolts of OAuth 2.0

6 min readApr 28, 2024

In today’s interconnected digital landscape, the need for secure access to user data across different applications has become paramount. OAuth, an open standard for access delegation, has emerged as a vital framework for facilitating secure authorization and authentication processes.
OAuth (Open Authorization) is an authorization framework that allows third-party services to access a user’s resources on another service without revealing their credentials. It enables users to grant limited access to their resources (such as data or services) to external applications without sharing their passwords directly. OAuth is widely used in various applications, especially in the context of APIs and web services.

Example

Consider the scenario of a user, Alice, who wants to allow a third-party application, MyApp, to access her photos stored on a cloud storage service like Google Drive or Dropbox. Before OAuth, the only way for MyApp to access Alice’s photos would be for Alice to share her username and password for the cloud storage service directly with MyApp. This approach poses several security risks:

Credential Exposure: Sharing passwords directly with third-party applications exposes users’ credentials to potential misuse or unauthorized access. If MyApp were compromised, Alice’s login credentials could be exposed and used to access her account on the cloud storage service. The only way to revoke the app’s access to the third-party application was updating the password.
Limited Control: Once Alice shares her credentials, she loses control over how they are used. MyApp could potentially access all of Alice’s data on the cloud storage service, not just her photos, without her knowledge or consent.
Difficulty in Revocation: If Alice decides to revoke access for MyApp or suspects unauthorized access, she would need to change her password for the cloud storage service, affecting her ability to log in directly and potentially disrupting other connected services.

OAuth addresses these security concerns by providing a secure and standardised framework for granting limited access to user resources without sharing credentials.

History

OAuth was first conceptualized in 2006 by Blaine Cook, Chris Messina, Larry Halff, and David Recordon as an alternative to the then-common practice of sharing usernames and passwords to grant access to third-party applications. The initial version, OAuth 1.0, was released in 2007, followed by OAuth 1.0a in 2009, addressing security vulnerabilities in the original specification.
OAuth 2.0, the current version, was introduced in 2012 with significant improvements in usability, flexibility, and security. It aimed to simplify the authorization process for developers while providing robust security mechanisms for protecting user data. The development did not stop then, the work continued in order to make it easier to use and more secure in various situations.

OAuth 1.0: An Overview and Shortcomings

How it worked?

Request Token: The process began with the Consumer obtaining a request token from the Service Provider by presenting its credentials (consumer key and secret). This request token acted as a temporary credential for the authorization process.
User Authentication: The Consumer then redirected the user to the Service Provider’s website to authorize the request token. The user logged in and granted permission to the Consumer to access their resources.
Access Token: After authorization, the Service Provider exchanged the authorized request token for an access token, confirming that the user had granted permission to the Consumer. This access token was used by the Consumer to access the user’s resources on the Service Provider.
Accessing Protected Resources: With the access token, the Consumer could access the user’s protected resources on the Service Provider’s server.
Token Expiry and Renewal: OAuth 1.0 also supported token expiry and renewal mechanisms to enhance security. Tokens had a limited lifespan, and when they expired, the Consumer had to renew them by repeating the token exchange process.

Shortcomings

Complexity: OAuth 1.0 was relatively complex to implement, especially for developers who were not familiar with cryptographic concepts and security protocols. The signature process, which involved generating cryptographic signatures for requests, added complexity to the protocol.
Example: Imagine you’re sending a secret code to a friend, but you have to encrypt it using a complicated method each time. If you make a mistake in the encryption, your friend won’t understand the code.
Security Concerns: While OAuth 1.0 provided a secure way to authorize third-party access, it still had some vulnerabilities, especially related to signature generation and token management. Developers needed to carefully implement cryptographic functions to prevent attacks like replay attacks and man-in-the-middle attacks.
Example: It’s like sending a secret message in a locked box, but someone sneaky manages to duplicate the key and unlock the box without your knowledge.
Token Transmission: OAuth 1.0 tokens, including request tokens and access tokens, were transmitted over the wire in plaintext, which posed a security risk. Although the protocol required the use of HTTPS for token transmission to mitigate this risk, it still left room for potential vulnerabilities.
User Experience: The user experience in OAuth 1.0 was not always seamless. Users were often redirected to the Service Provider’s website to authorize access, which could lead to confusion and security concerns if not implemented properly.
Limited Protocol Support: OAuth 1.0 lacked native support for some use cases, such as mobile and browser-based applications, which became increasingly popular with the rise of smartphones and web applications.

OAuth 2.0 to the rescue

OAuth 2.0 solved all the short comings present in the first version.

Roles in OAuth 2.0

There are 4 roles associated:

User (Resource Owner): This is the user who owns the resource that needs to be accessed by a third-party application or simply person with the account.
Authorization Server: Server that authenticates the Resource Owner and issues access tokens after getting proper authorization. Example: Auth0, Next Auth.
Application (OAuth Client): Application requesting access to a protected resource on behalf of the Resource Owner.
API (Resource Server): This is the server hosting the protected resources that the client wants to access. This is the API you want to access.

Application Types

There are basically two types of clients:

Confidential Clients: These are the clients that has credentials that can be used during the OAuth flow, typically a secret token (client secret). This is common for apps running on the server, example Java, .NET, php, etc.
The source code of these applications are not accessible to the user, so If we are storing the secret in env variables, the code is not visible to anyone outside.
Public Clients: These clients don’t have the secret. The simple reason is because for public clients, the source code can be viewed by external users. These clients include SPA Web Apps, mobile apps (there are tools to extract strings out of the binary files). There is no way to keep the secret in the source code and have it remain secret.
Anything that runs on user’s device, smart TV, IoT device, cannot have a secret present and hence it becomes a public client.

This is used by OAuth server to identify whether the request is coming from a valid source. And based on the client type, OAuth server can be configured to behave differently (show consent screen or not).

User Consent

OAuth aims to safeguard user data by ensuring it’s only shared with authorized parties. This protection is facilitated through user consent, a crucial step in the OAuth flow. When users encounter a screen prompting them to grant permission, known as the consent screen, they’re essentially giving the green light for access to their data.

Learn about the detailed workings of OAuth 2.0, how tokens are exchanged securely and how it all comes together in this article: https://medium.com/@iamabhikedia74/detailed-working-of-oauth-2-0-web-952622bcf1fc

Make sure you have completed this article first before moving to the detailed one!

Let’s Get in Touch

You are most welcome to follow me here on Medium. In addition, feel free to check out:

References:

https://www.udemy.com/share/103UzM/