Identity & Access Security Bloggers Network

Home » Security Bloggers Network » OAuth 2.0 Overview

OAuth 2.0 Overview

by Ankit Agarwal on May 17, 2025

Ever clicked a “Login with Google” button or granted a new photo app permission to access your Dropbox files? If so, you’ve already experienced OAuth 2.0 — even if you didn’t realize it at the time.

Think of it like this: you wouldn’t hand the valet at a hotel your entire keychain with your house, office, and safe deposit box keys just to park your car, right? You’d give them a valet key — a key that lets them do one specific thing and nothing else.

OAuth 2.0 works the same way in the digital world. It’s a secure authorization protocol that lets applications access specific user resources without ever sharing the user’s password. And if you’re building modern web, mobile, or API-first apps, understanding OAuth 2.0 is a must.

In this post, we’ll break down the what, why, and how of OAuth 2.0 for developers — explaining its core concepts, real-world use cases, and the different roles involved in a way that’s easy to grasp, whether you’re just getting started or refining your security knowledge.

What is OAuth 2.0, Really?

OAuth 2.0 is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords. Think of it as a permission slip. Instead of sharing your username and password for a service (like Google or Twitter) with a third-party application, OAuth 2.0 allows you to grant that application limited access to your account on your behalf.

It’s an authorization framework, not an authentication protocol. While it’s often used in conjunction with authentication, its primary job is to say “this application is allowed to do X, Y, and Z with this user’s data,” not “this user is who they say they are.” For a deeper dive into the official specification, you can always refer to the OAuth 2.0 Authorization Framework RFC 6749.

Why Do We Need OAuth 2.0? The Problem it Solves

Before OAuth, the digital world faced a significant security dilemma. If you wanted a third-party application (let’s say, “AwesomePhotoPrinter.com”) to access your photos on “MyPhotoCloud.com,” you often had to give AwesomePhotoPrinter your MyPhotoCloud username and password.

This “password anti-pattern” is problematic for several reasons:

Security Risk: AwesomePhotoPrinter now has your full credentials. If their database is breached, your MyPhotoCloud account is compromised.
Over-Privileged Access: AwesomePhotoPrinter might only need to read your photos, but with your password, it could potentially delete photos, change your settings, or access other private information.
Revocation Difficulty: If you want to stop AwesomePhotoPrinter from accessing your photos, changing your MyPhotoCloud password is the only sure way, which then breaks access for all other services you might have (legitimately) given your password to.
User Experience: Users are (rightfully) hesitant to share their passwords.

OAuth 2.0 was designed to solve these problems by providing a secure and standardized way for applications to obtain limited, revocable access to user accounts on an HTTP service.

The Cast of Characters: Understanding OAuth 2.0 Roles

To understand how OAuth 2.0 works, let’s meet the key players involved in this authorization dance. Imagine you (the user) want a third-party application to access some of your data stored on another service.

Resource Owner (You, The User)
Who they are: The entity capable of granting access to a protected resource. Typically, this is the end-user who owns the data.
Analogy: You are the owner of a valuable safe (your data).
### Client (The Third-Party Application)
Who they are: The application (e.g., a mobile app, web app, or desktop app) that wants to access the Resource Owner’s data on their behalf.
Analogy: A trusted friend (the application) who wants to borrow a specific item from your safe, with your permission.
### Authorization Server (The Gatekeeper)
Who they are: The server that authenticates the Resource Owner and issues “access tokens” to the Client after successfully obtaining authorization from the Resource Owner. This server is often, but not always, the same server as the Resource Server.
Analogy: The security guard at the bank who verifies your identity and checks your permission slip before giving your friend a special key (access token) to a specific safe deposit box.
### Resource Server (The Vault)
Who they are: The server hosting the protected user resources (e.g., photos, contacts, emails). This server accepts and validates an access token from the Client and, if valid, allows access to the requested resources.
Analogy: The vault itself, or the specific safe deposit box, that holds your valuable items. The special key (access token) unlocks it.

These roles interact in a carefully choreographed sequence, often referred to as an “OAuth flow” or “grant type.”

If you’re curious how SAML handles similar responsibilities, here’s a guide that breaks down how SAML authentication works in comparison.

The OAuth 2.0 Flow: A Simplified Story (Authorization Code Grant)

One of the most common and secure OAuth 2.0 flows for web and mobile applications is the Authorization Code Grant. Let’s walk through it step-by-step, continuing our analogy:

The Request (User Initiates): You’re on AwesomePhotoPrinter.com (the Client) and click “Connect to MyPhotoCloud.com to print photos.”
Redirection to Authorize (Client to Authorization Server): AwesomePhotoPrinter.com redirects your browser to MyPhotoCloud.com‘s Authorization Server. This request includes the Client’s ID and the specific permissions (scopes) it’s requesting (e.g., “read photos”).
User Authentication & Authorization (Resource Owner at Authorization Server):

- MyPhotoCloud.com (Authorization Server) asks you (the Resource Owner) to log in (if you aren’t already).
- It then displays a consent screen: “AwesomePhotoPrinter.com wants to access your photos. Allow?” You click “Allow.”

Authorization Code Issued (Authorization Server to Client via User):

- The Authorization Server redirects your browser back to AwesomePhotoPrinter.com with a short-lived Authorization Code. This code is not the final key.

Exchanging Code for Token (Client to Authorization Server – Backend):

- AwesomePhotoPrinter.com (Client), in a secure backend exchange (not visible to your browser), sends this Authorization Code, along with its own Client ID and Client Secret (a password for the app itself), to the MyPhotoCloud.com Authorization Server.

Access Token Granted (Authorization Server to Client):

- The Authorization Server verifies the Authorization Code, Client ID, and Client Secret. If all is well, it issues an Access Token (and optionally, a Refresh Token) back to AwesomePhotoPrinter.com. This is the valet key!

Accessing Resources (Client to Resource Server):

- AwesomePhotoPrinter.com (Client) can now use this Access Token to request your photos from MyPhotoCloud.com‘s Resource Server. It includes the Access Token in the Authorization header of its API requests.

Resource Served (Resource Server to Client): The Resource Server validates the Access Token. If valid and the requested scope is permitted, it returns your photos to AwesomePhotoPrinter.com.

Here’s a visual representation of this flow:

This flow ensures your credentials are never shared with the client application. The client only receives a temporary, scoped Access Token.

Key OAuth 2.0 Concepts You Should Know

Beyond the roles and basic flow, a few more terms are essential:

Access Token: A string representing the authorization granted to the client. It’s used by the client to access protected resources on the resource server. Access tokens are typically short-lived for security reasons (e.g., valid for an hour). They can be in various formats, with JSON Web Tokens (JWTs) being a popular choice.
Refresh Token: A special token that can be used to obtain a new access token when the current one expires. Refresh tokens are typically longer-lived and are stored securely by the client. They are only sent to the Authorization Server.
Scopes: These define the specific permissions the client is requesting. For example, read_photos, post_tweet, or access_profile_info. This allows for granular control – the user only grants the permissions the application actually needs.
Grant Types: OAuth 2.0 defines several ways (flows) for a client to obtain an access token. These are called grant types. We discussed the Authorization Code Grant, which is ideal for web and mobile apps. Others include:
- Implicit Grant: A simplified flow for browser-based applications (less secure, generally deprecated in favor of Auth Code with PKCE).
- Resource Owner Password Credentials Grant: The user provides their credentials directly to the client, which then uses them to get an access token. This is strongly discouraged as it negates many OAuth benefits.
- Client Credentials Grant: Used for machine-to-machine authentication, where the client is acting on its own behalf (not a user’s).
- Proof Key for Code Exchange (PKCE): An extension to the Authorization Code Grant (often pronounced “pixie”) that enhances security for public clients like mobile and single-page applications. RFC 7636 details this.

OAuth 2.0 vs. OAuth 1.0a: The Evolution

OAuth 2.0 is a complete rewrite of OAuth 1.0a, designed to be simpler for developers, more flexible, and better suited for non-browser clients (like mobile apps). Key differences include:

Signatures: OAuth 1.0a required clients to cryptographically sign every API request. OAuth 2.0 relies on HTTPS (TLS) for transport-level security and bearer tokens, simplifying client-side implementation.
Simplicity: OAuth 2.0 is generally easier to implement for client developers.
Token Types: OAuth 2.0 clearly separates access tokens and refresh tokens.
Scalability: OAuth 2.0 is designed to scale better.

For more details, OAuth.com offers a good comparison.

Want to stay ahead of the curve? Here’s what’s changing in OAuth 2.1 and how it improves upon OAuth 2.0.

OAuth 2.0 vs. OpenID Connect (OIDC): Authorization vs. Authentication

This is a common point of confusion.

OAuth 2.0 is for Authorization: It’s about granting permission to access resources.
OpenID Connect (OIDC) is for Authentication: It’s about verifying the user’s identity.

OIDC is built on top of OAuth 2.0. When you see “Login with Google,” it’s often OIDC at play. OIDC adds an ID Token (usually a JWT) to the OAuth 2.0 flow, which provides information about the authenticated user to the client. So, OIDC uses OAuth 2.0 to get authorization and then provides an ID token for authentication. OpenID Connect’s official site is a great resource.

If you’re still wondering when to use OAuth vs OpenID Connect, this difference between OAuth and OIDC guide explains it clearly.

Still comparing identity protocols? Here’s a practical guide on SAML vs OAuth for SSO to help you decide what’s best for your stack.

Benefits of Using OAuth 2.0

Implementing or using OAuth 2.0 offers significant advantages:

Enhanced Security: Users don’t share their primary credentials with third-party apps. Access tokens are limited in scope and lifetime.
Improved User Experience: Users can grant access with a few clicks without creating new accounts or remembering more passwords. It can also enable single sign-on (SSO) like experiences.
Granular Control: Scopes allow users and services to grant only the necessary permissions.
Revocable Access: Users (or services) can revoke a client’s access at any time without affecting other applications or changing their main password.
Standardization: It’s a widely adopted industry standard, meaning better interoperability and more available libraries and tools.

Challenges and Considerations

While powerful, OAuth 2.0 isn’t without its complexities:

Implementation Complexity: The full specification is extensive, and choosing the right grant type and implementing it securely requires careful consideration. Common pitfalls include token leakage, insecure redirect URI handling, and Cross-Site Request Forgery (CSRF) vulnerabilities.
Understanding the Flows: Developers new to OAuth 2.0 might find the different roles and flows initially confusing.
Security is Paramount: Misconfigurations can lead to serious vulnerabilities. Always use well-vetted libraries and follow security best practices. For instance, the OAuth 2.0 Security Best Current Practice document is essential reading.

Real-World Applications & Use Cases

You interact with OAuth 2.0 constantly:

Social Logins: “Sign in with Google/Facebook/Twitter/GitHub” buttons on websites and apps.
Third-Party App Integrations: A calendar app accessing your Google Calendar, a fitness tracker syncing data with a health platform, or a marketing tool posting to your social media accounts.
Smart Home Devices: Your smart thermostat app getting permission to control the device via a cloud service.
API Access Management: Enterprises use OAuth 2.0 to secure access to their internal and external APIs.

Conclusion: OAuth 2.0 — The Modern Gatekeeper for Secure Access

OAuth 2.0 has fundamentally changed how applications interact securely on the internet. By acting as a “digital valet key,” it allows users to delegate specific permissions to third-party applications without compromising their primary credentials. While it has its complexities, understanding its roles, flows, and core concepts is essential for any developer building modern, interconnected applications or secure APIs. It empowers users with control and developers with a standardized framework for secure access delegation.

As applications become increasingly interconnected, the principles of OAuth 2.0 will only become more critical. So, the next time you click “Allow” on a permission screen, you’ll know there’s a sophisticated, secure dance happening behind the scenes, orchestrated by OAuth 2.0.