OAuth 2.0

OAuth 2.0 (Open Authorization) is a widely used authorization framework that enables third-party applications to obtain limited access to user accounts on an HTTP service, such as Facebook, GitHub, or Google. It works by delegating user authentication to the service that hosts the user account, and authorizing third-party applications to access the user account without exposing the user's credentials.

It replaced OAuth 1.0 in 2012 and is now the de facto industry standard for online authorization. OAuth 2.0 provides consented access and restricts actions of what the client app can perform on resources on behalf of the user, without ever sharing the user's credentials.

In easy words, OAuth 2.0 is a way for users to give permission to applications (like mobile apps or websites) to access their data (such as emails or photos), that is on another service (like Google or Facebook) without sharing their passwords.

Short History

  • 2007: OAuth began as an open protocol initiated by Blaine Cook and Chris Messina, along with other contributors from the social web community.

  • 2009: The OAuth 1.0 protocol was published.

  • 2012: OAuth 2.0 was finalized and published as RFC 6749 and RFC 6750, introducing significant changes and improvements over OAuth 1.0.

Principles

  • Authorization Protocol: OAuth 2.0 is an authorization protocol, not an authentication protocol. It is designed to grant access to resources, such as remote APIs or user data.

  • Access Tokens: OAuth 2.0 uses Access Tokens, which are pieces of data representing authorization to access resources on behalf of the end-user.

  • Token Format: OAuth 2.0 does not define a specific format for Access Tokens. However, JSON Web Token (JWT) is often used in practice.

  • Token Data: When using JWT, token issuers can include data within the token itself, allowing for self-contained tokens that carry necessary information.

  • Token Expiration: For security reasons, Access Tokens may have an expiration date, limiting the duration of access granted to the client.

Architecture

The OAuth 2.0 architecture involves the following primary roles:

  1. Resource Owner: The user who owns the data and grants access to their resources.

  2. Client: The third-party application requesting access to the resources.

  3. Resource Server: The server hosting the protected resources (API endpoint).

  4. Authorization Server: The server that authenticates the user and issues access tokens to the client.

Low-Level Design

The OAuth 2.0 flow involves several steps and interactions between these components:

  1. Authorization Grant: The client requests authorization from the resource owner.

  2. Authorization Grant Type: This can be one of four types:

    • Authorization Code: Used with server-side applications.

    • Implicit: Used with mobile or web applications (applications that run on the user’s device).

    • Resource Owner Password Credentials: Directly exchanges the user’s username and password for an access token.

    • Client Credentials: Used for application access without user involvement.

    • Device Authorization Flow: A grant that enables use by apps on input-constrained devices, such as smart TVs.

    • Refresh Token Grant: The flow that involves the exchange of a Refresh Token for a new Access Token.

  3. Access Token: The authorization server issues an access token to the client.

  4. Resource Access: The client uses the access token to access the protected resources on the resource server.

How OAuth 2.0 Works

The OAuth 2.0 process typically follows these steps (example: Authorization Code Grant):

  1. Authorization Request:

    • The client redirects the resource owner to the authorization server, including parameters like client ID, redirect URI, and requested scope.

  2. Authorization Grant:

    • The resource owner authenticates and consents to the authorization request.

    • The authorization server redirects back to the client with an authorization code.

  3. Access Token Request:

    • The client exchanges the authorization code for an access token by making a request to the token endpoint of the authorization server, including the client secret.

  4. Access Token Response:

    • The authorization server returns an access token (and optionally a refresh token).

  5. Accessing Protected Resources:

    • The client uses the access token to make authenticated requests to the resource server.

  6. Token Refresh (Optional):

    • If a refresh token is provided, the client can request a new access token without involving the resource owner again.

The user wants to access some resources in the app -> The app requests authorization -> User input credentials -> App transfer credentials with OAuth keys to the Authorization Server -> The authorization server returns the Access token -> The app sends the access token to the resource server -> The resource server serves the resource to the application -> The app returns info to the user that the app is accessible

OAuth Flows

OAuth allows different flows (processes), such as:

  • Authorization Code Flow — To be used for server-side applications, it acquires an authorization code to exchange for an access token, ensuring the client never exposes the tokens to the user-agent.

  • Implicit Flow — Previously used for client-side applications like SPAs, it directly returns an access token upon authorization but lacks refresh tokens and is less recommended due to security issues. It is deprecated due to security weaknesses.

  • Resource Owner Password Credentials Flow — This flow allows the client to use the resource owner’s username and password directly, which is suitable for highly trusted or legacy applications but is discouraged due to security risks.

  • Client Credentials Flow — For server-to-server authentication, a client can use its credentials instead of impersonating a user to obtain an access token.

  • Refresh Token Flow — When an access token expires, the client can obtain a new token using a refresh token without user interaction.

  • Device Code Flow — Designed for devices with limited input capabilities, it involves the user authorizing the device on a secondary device, following which the primary device gets the access token.

  • Extension Flow — A catch-all for custom flows, allowing for adaptations of the OAuth 2.0 protocol to cater to specific needs or scenarios not covered by other predefined flows.

OAuth Design using Python

import os
from requests_oauthlib import OAuth2Session
from oauthlib.oauth2 import BackendApplicationClient
from requests.auth import HTTPBasicAuth

# Replace these values with your client_id and client_secret
client_id = 'YOUR_CLIENT_ID'
client_secret = 'YOUR_CLIENT_SECRET'
authorization_base_url = 'https://accounts.google.com/o/oauth2/auth'
token_url = 'https://accounts.google.com/o/oauth2/token'
redirect_uri = 'http://localhost:8000/callback'

# Step 1: User Authorization
oauth = OAuth2Session(client_id, redirect_uri=redirect_uri, scope=['https://www.googleapis.com/auth/userinfo.email'])
authorization_url, state = oauth.authorization_url(authorization_base_url, access_type="offline", prompt="select_account")

print('Please go to this URL and authorize:', authorization_url)

# Step 2: Getting the Authorization Code
redirect_response = input('Paste the full redirect URL here: ')

# Step 3: Fetching the Access Token
oauth.fetch_token(token_url, authorization_response=redirect_response, client_secret=client_secret)

# Step 4: Accessing Protected Resources
r = oauth.get('https://www.googleapis.com/oauth2/v1/userinfo')
print(r.json())

Reference for Google OAuth API: https://developers.google.com/identity/protocols/oauth2

The provided Python code demonstrates how to implement OAuth 2.0 authorization in a Python application to access a user's Google account data. First, it installs the necessary requests-oauthlib library. Then, it sets up the OAuth 2.0 session using the OAuth2Session class, where the client ID, redirect URI, and the scope of access (e.g., email) are specified. The code constructs the authorization URL and directs the user to this URL to grant access. After the user authorizes the request, Google redirects back to the specified redirect_uri with an authorization code. The user is prompted to paste this redirect URL into the console. The code then uses this authorization code to request an access token from the token endpoint. Once the access token is obtained, the code makes a request to a protected Google API endpoint (in this case, user info) using the access token to access the user's data. This process demonstrates a secure method for third-party applications to access user data without needing the user's credentials.

Example Usage

  • Third-Party Access — Users can grant third-party applications limited access to their resources without sharing their credentials, like allowing a photo printing service access to photos stored in a cloud service.

For example, A user allows a scheduling app to access their Google Calendar to automatically set up meetings without sharing their Google credentials.

  • Single Sign-On (SSO) — It facilitates Single Sign-On (SSO), where users can log in to multiple services using a single ID, streamlining the authentication process across platforms and services.

For example, An employee logs into their corporate network and can access different departmental applications like email, HR system, and project management tool without logging in again.

  • Mobile Applications — OAuth 2.0 provides a framework for mobile apps to obtain the necessary tokens for accessing protected resources, ensuring secure operations.

For example, A user downloads a fitness app which, upon authorization via OAuth 2.0, accesses their Spotify playlists to play music during workouts without requiring separate logins.

References

PreviousJWTNextSecure Headers

Last updated