OAuth 2.0 and OpenID Connect: Simplified Guide

Future-Proofing Your Security, Here’s What You Really Need to Know

Prince Singh
7 min readSep 6, 2024

Introduction

In today’s interconnected digital landscape, seamless and secure user authentication is crucial. The modern web has made it easier than ever for users to access multiple services and applications without creating new accounts for each.

This seamless convenience often comes thanks to protocols like OAuth 2.0 and OpenID Connect (OIDC). These are two of the most widely used protocols for managing authentication and authorization across multiple platforms.

Solution: single sign-on options to reduce friction during login processes

But what exactly are these protocols, how do they work, and how can you use them securely in your applications? Whether you’re a developer building an application or a security professional ensuring user data protection, understanding these protocols is essential.

This article will break it all down in plain English, providing easy-to-understand examples, diagrams, and tips to ensure your app is both user-friendly and secure.

What is OAuth 2.0?

OAuth 2.0 is an open standard authorization framework that allows third-party applications to access a user’s resources without needing to know their credentials. The user can grant the application limited access to their to their data hosted on another platform (like Google, Facebook, or Twitter) without revealing their username and password.

Real-World Example

Imagine you’re developing a fitness app that tracks users’ activities. Your app wants to access a user’s data from their Google Fit account, to make it more comprehensive.

However, asking users to provide their Google credentials directly to your app is risky and would raise trust concerns. Instead of asking the user for their Google credentials, your app uses OAuth 2.0 to redirect users to Google’s login page, where they grant access to your app. Google then provides your app an Access Token, which your app uses to fetch the user’s data securely.

The Flow of OAuth 2.0

Diagram: A detailed diagram showing each step in the OAuth 2.0 flow, highlighting the interaction between the client (your app), the authorization server (Google), and the resource server (Google Fit API).

+----------------+                                  +-------------------+
| | | |
| User | | Google |
| (User-Agent) | | (Authorization |
| | | Server) |
+----------------+ +-------------------+
| |
| 1. Request Authorization (Redirect to Google) |
|--------------------------------------------------->>|
| |
| 2. User Consent (Grant Authorization Code) |
|<<---------------------------------------------------|
| |
| 3. Authorization Code (Received by App) |
|<<---------------------------------------------------|
| |
| 4. Exchange Authorization Code for Access Token |
|--------------------------------------------------->>|
| |
| 5. Receive Access Token |
|<<---------------------------------------------------|
| |
| 6. Use Access Token to Request User’s Data |
|--------------------------------------------------->>|
| |
| 7. Access Resource (Fitness Data from Google Fit) |
|<<---------------------------------------------------|
| |
+----------------+ +-------------------+
| | | |
| App | | Google Fit |
| (Your Server) | | (API Server) |
| | | |
+----------------+ +-------------------+

Let’s break down how OAuth 2.0 works with a more detailed look at the steps involved:

  1. User Authorization Request: The user wants to use a feature in your app that requires access to their Google Fit data. Your app redirects them to Google’s authorization server, asking permission to access the data.
  2. User Consent: The user logs in to Google (if they aren’t already) and is presented with a screen asking if they want to grant your app the requested permissions.
  3. Authorization Code: If the user agrees, Google’s authorization server sends an authorization code to your app.
  4. Access Token Request: Your app sends the authorization code back to Google’s authorization server and your app’s credentials (client ID and secret).
  5. Access Token Response: If everything checks out, Google’s authorization server sends an Access Token to your app.
  6. Access Resource: Your app uses this Access Token to request the user’s data from the Google Fit API.

What is OpenID Connect (OIDC)?

OpenID Connect is an identity layer built on top of OAuth 2.0, that enables the application (client) to verify the identity of the user, while OAuth 2.0 handles the authorization part (granting access to resources).

OIDC returns an ID Token along with the Access Token, which contains information about the user (e.g., their name, email, and unique identifier).

Real-World Example

Continuing from the previous example, let’s say your fitness app not only needs access to users’ Google Fit data but also needs to personalize their experience by displaying their name and profile picture. With OIDC, when the user grants your app permission, Google will also send back an ID Token containing this information.

The ID Token is a JSON Web Token (JWT), which is a secure, signed piece of data that your app can decode to obtain user details. This means your app can authenticate users and personalize their experience without asking them to create another account.

How Does OIDC Work?

Diagram: An enhanced diagram showing the complete OIDC flow, including the issuance and validation of the ID Token.

+-----------+                                  +-------------------+
| | | |
| User | | Google |
| (Client) | | (Authorization |
| | | Server) |
+-----------+ +-------------------+
| |
| 1. Request Authorization |
|-------------------------------------------------->|
| |
| 2. Grant Authorization (OAuth Token) |
|<--------------------------------------------------|
| |
| 3. Use Token to Access Resource |
|-------------------------------------------------->|
| |
| 4. Receive ID Token with User Info |
|<--------------------------------------------------|
| |
| 5. Access Data (Fitness Data, etc.) |
|-------------------------------------------------->|
| |
+-----------+ +-------------------+
| | | |
| App | | Google Fit |
| (Client) | | (API Server) |
| | | |
+-----------+ +-------------------+

OIDC adds a few additional steps to the OAuth 2.0 flow:

  1. Authorization Request with OIDC Scope: Your app requests authorization as usual but also specifies that it wants to use OIDC by including the openid scope.
  2. Authentication and Consent: The user authenticates with Google and consents to the requested permissions.
  3. ID Token Issuance: Along with the Access Token, Google issues an ID Token. This token is encoded in JWT format and contains user information such as their unique identifier, email, and name.
  4. ID Token Validation: Your app validates the ID Token to ensure it hasn’t been tampered with. This involves checking the signature and verifying that the token is indeed from Google.
  5. Personalized Experience: Your app decodes the ID Token to retrieve user information and provides a personalized experience based on that data.

When to Use OAuth 2.0 and OpenID Connect

  • Use OAuth 2.0 when you need to authorize access to user resources (like accessing a user’s Google Fit data) without handling their credentials directly.
  • Use OpenID Connect when you also need to authenticate usersobtain their identity details (like their name, email, and profile picture).

Example Use Cases:

  • Social Logins: Allow users to log in to your app using their Google or Facebook accounts.
  • API Access: Enable your app to fetch data from external APIs on behalf of the user, such as accessing their fitness or social media data.
  • Single Sign-On (SSO): Allows users to sign in once and access multiple applications seamlessly.

Refresh Tokens: Maintaining the User Session

A key feature of OAuth 2.0 is the use of Refresh Tokens to maintain user sessions without requiring them to log in repeatedly. The Access Token typically has a short lifespan (minutes to hours), but the Refresh Token is long-lived and can be used to obtain new Access Tokens.

How Refresh Token’s Work

  • Short-Lived Access Tokens: When the Access Token expires, the user would typically have to log in again. However, if your app has a Refresh Token, it can silently request a new Access Token without user interaction.
  • Security Consideration: Because Refresh Tokens are long-lived, they must be stored securely, usually on the server side. If a Refresh Token is compromised, an attacker can maintain access to user resources until the token is revoked or expires.

Example: Imagine a user logs in to your fitness app, granting it access to their Google Fit data. If the Access Token expires after 30 minutes, your app can use the Refresh Token to obtain a new Access Token without interrupting the user’s workout session.

Security Considerations

While OAuth 2.0 and OIDC are powerful, they come with their own security challenges. Here are some potential threats and best practices to mitigate them:

  1. Token Hijacking: If an attacker intercepts an Access Token, they can impersonate the user.
  • Mitigation: Always use HTTPS to encrypt the communication channel and minimize the risk of token interception.

2. Redirect URI Manipulation: Attackers can manipulate the redirect URI to intercept tokens or authorization codes.

  • Mitigation: Validate redirect URIs strictly, ensuring they match exactly what you expect.

3. Cross-Site Scripting (XSS): Malicious scripts can steal tokens from your app’s storage.

  • Mitigation: Implement a Content Security Policy (CSP) and sanitize all user inputs to prevent XSS attacks.

4. Token Storage: Storing tokens securely is crucial, especially Refresh Tokens and ID Tokens.

  • Mitigation: Store tokens in secure HTTP-only cookies or server-side sessions to reduce exposure to client-side attacks.

In conclusion:

OAuth 2.0 and OpenID Connect are essential tools for modern application development, providing robust frameworks for secure authentication and authorization. By understanding how they work and implementing them correctly, you can enhance both the security and user experience of your applications. Learn more at OAuth 2.0

~ Prince Singh (LinkedIn isinghprince)

--

--

Prince Singh

I specialize in architecting enterprise-scale web applications and intuitive data visualizations from zero. Expertise - TypeScript, Rest APIs, Postgres DB