What is OAuth, real-world examples and various OAuth attacks

OAuth is everywhere—from signing into your favorite apps using Google or GitHub to enabling secure access between APIs. But while OAuth is incredibly powerful, it’s also one of the most misunderstood and misconfigured components in modern applications. And that’s exactly why knowing its fundamentals isn’t optional—it’s critical.

Misconfigurations in OAuth can open doors to serious vulnerabilities such as account takeover, token leakage, authentication bypass, and privilege escalation. These aren’t just theoretical risks—they’re some of the most commonly exploited bugs in real-world bug bounty reports and security audits, often leading to severe business impact.

In this blog series, we’ll break down OAuth in a simple, understandable way—covering how it works, the common pitfalls, types of attacks to watch out for, and how to defend against them effectively.

OAuth: Overview

OAuth (Open Authorization) is an open standard protocol that allows secure, delegated access to a user’s resources without exposing their credentials. It is commonly used to enable third-party applications to access a user’s data on services like Google, Facebook, and GitHub.

Sure! Here’s a human-friendly, real-world example to make the concept of OAuth easier to understand:

Real-World Example of OAuth

Let’s say you’ve just downloaded a new photo editing app on your phone. The app asks, “Do you want to import photos from your Google Drive?” You click “Yes”, and suddenly you’re taken to a Google login screen—not inside the app, but on Google’s official website. You log in, give permission to access only your photos (not your emails or calendar), and you’re redirected back to the app, which now has access to your pictures.

Here’s what just happened behind the scenes:

The photo app never saw your Google password.
You only gave limited access (photos, not emails).
You could go to your Google account later and revoke that access anytime.

This is OAuth in action.

It allows the app to access your data securely and with your consent, without ever needing to store or manage your actual credentials.

Key Components of OAuth

Resource Owner: The user who authorizes access to their data.
Client: The third-party application requesting access to the user’s resources.
Resource Server: The API that holds the protected resources (e.g., Google Calendar).
Authorization Server: Issues access tokens after authenticating the user.

OAuth Grant Types

OAuth supports different types of grants depending on the use case:

1. Authorization Code Grant

This is a widely used grant type and you use it on a day to day basis.

Flow:
a. The client directs the user to the authorization server.
b. The user authenticates and grants permission.
c. An authorization code is sent to the client.
d. The client exchanges the code for an access token.
Use Case: Web and mobile applications

You must use this grant where you have the following requirements.

Your app is a server-side web application.
You can safely store secrets (like client_secret) on the server.
You need secure, long-term access to a user’s data.
You want to avoid exposing tokens to the browser or front-end.

2. Implicit Grant (Deprecated)

Flow: The access token is returned directly in the redirect URL.
Use Case: Browser-based apps.
Security Concern: Prone to token leakage and is largely discouraged.

3. Resource Owner Password Credentials Grant

The Resource Owner Password Credentials Grant is an OAuth 2.0 flow where the user directly shares their username and password with the application. The app then sends these credentials to the authorization server in exchange for an access token.

Use Case: Trusted applications like first-party mobile apps.

Imagine a command-line tool built by a company that also owns the OAuth provider. The tool needs access to a user’s Google Drive files.

With ROPC:

The user provides their Google email and password directly into the CLI tool.
The tool sends these credentials (along with its own client ID and secret) to Google’s authorization server.
If the credentials are valid, Google returns an access token to the tool.
The CLI tool then uses that token to access the user’s Google Drive files.

Security Concern: Requires sharing sensitive user credentials, making it less secure.

4. Client Credentials Grant

Flow: The client (e.g., a backend service or microservice) directly authenticates itself to the authorization server using its own credentials (client ID and secret) and receives an access token.
Use Case: Used for server-to-server communication, where no end user is involved. For example, a microservice fetching data from another internal service.
Security Feature: No user involvement, focusing on service security.

5. Device Code Grant

Flow: The device (e.g., a smart TV) shows the user a code and a URL. The user then visits the URL on their phone or computer, logs in, and enters the code. Once authorized, the device gets an access token.
Use Case: Perfect for devices without a browser or input capabilities, like smart TVs, gaming consoles, or IoT devices.
Security Feature: Separates the authentication step from the device, preventing credential input on potentially insecure platforms.

6. Refresh Token Grant

Flow: After a user has authenticated once and the original access token expires, the client uses a refresh token to obtain a new access token without asking the user to log in again.
Use Case: Ideal for apps requiring long-lived sessions, like mobile apps or web apps where users shouldn’t have to log in every hour.
Security Feature: Helps reduce login frequency while keeping sessions secure. Refresh tokens are typically stored securely and used only when necessary.

Common OAuth Attacks and Mitigations

The previous section covered all the basics that you need to know about OAuth. Now let’s understand what are the common oauth attacks and how to best protect against them.

Here’s a brief and easy-to-understand explanation of each OAuth-related attack along with real-world examples and short mitigations:

1. Phishing Attacks

What Happens:
Attackers create fake login pages that mimic services like Google or Facebook to steal user credentials or authorization codes.

Example:
You get an email asking to “log into your account,” which redirects to a lookalike Google OAuth login page.

Mitigation:

Only trust OAuth URLs over HTTPS
Train users to verify URLs carefully

2. Token Leakage

What Happens:
Access tokens leak through browser history, referrer headers, or insecure local storage (e.g., localStorage in SPAs).

Example:
A user logs in via OAuth, and the token is logged in browser dev tools or passed in URL parameters.

Mitigation:

Use Authorization Code Grant (not Implicit Grant)
Always use HTTPS

3. Token Replay Attack

What Happens:
An attacker captures a token (via proxy or insecure app) and reuses it to impersonate a user.

Example:
An attacker sniffs an access token on a public Wi-Fi and uses it to access user data.

Mitigation:

Use short-lived tokens
Bind tokens to client using MTLS or DPoP
Validate token sessions

4. 🎭 Cross-Site Request Forgery (CSRF)

What Happens:
An attacker tricks a logged-in user into unknowingly sending a valid OAuth authorization request.

Example:
You’re logged into an app, and visiting a malicious site silently triggers an OAuth request in your name. Or you as a victim unwillingly add attacker’s account as part of adding 3rd party integrations.

Mitigation:

Use state parameter to link request to session
Add CSRF tokens in requests

5. Authorization Code Interception

What Happens:
A malicious app intercepts the authorization code (sent via redirect) and uses it to fetch a token.

Example:
An attacker installs malware on your device that catches the OAuth redirect and steals the code.

Mitigation:

Use PKCE (Proof Key for Code Exchange)
Enforce HTTPS for all traffic

6. Access Token Manipulation

What Happens:
Attackers try to modify or forge access tokens (especially if JWTs are used) to gain unauthorized access.

Example:
Someone tampers with the JWT payload to escalate privileges from read to admin.

Mitigation:

Sign JWTs and verify signatures
Validate token claims on server

7. Open Redirect Vulnerabilities

What Happens:
An attacker exploits redirect URIs to send users to a malicious site after OAuth login.

Example:
After Google login, instead of returning to the original site, the user is redirected to evil.com.

Mitigation:

Whitelist redirect URIs
Avoid wildcards (*) in URI patterns

8. Scope Abuse

What Happens:
A client app requests more permissions than needed, increasing the blast radius if compromised.

Example:
A fitness app asks for full Gmail access instead of just step count.

Mitigation:

Follow least privilege principle
Limit scopes at the user and server level

9. Refresh Token Abuse

What Happens:
Stolen refresh tokens allow attackers to get new access tokens repeatedly, bypassing expiration.

Example:
An attacker gets hold of a long-lived refresh token and keeps renewing access.

Mitigation:

Rotate refresh tokens after each use
Set strict expiration and reuse limits

OAuth is a powerful protocol that enables seamless and secure delegated access—but with great power comes great responsibility. As developers and security professionals, it’s crucial to understand not just how OAuth works, but how attackers can abuse its flows. From phishing and token leakage to code interception and scope abuse, each vulnerability can have serious consequences if left unchecked. By learning the fundamentals, choosing the right grant types, and applying practical mitigations like PKCE, token binding, and strict scope management, you can drastically reduce the attack surface of your applications.

Remember: secure design isn’t just about compliance—it’s about protecting real users from real threats. Keep learning, stay curious, and keep building safer systems.