What Is OAuth 2.0?

OAuth 2.0 is an authorization framework that lets one application access resources on behalf of a user without sharing the user’s password. If you have ever clicked “Sign in with Google” or allowed a calendar app to access your events, you have used OAuth 2.0 in action.

In this article, you’ll learn what OAuth 2.0 is, how it works, which roles and flows are involved, why it matters for security, and how developers should use it correctly in real applications.

OAuth 2.0 in Plain English

OAuth 2.0 is a standard way for applications to request limited access to resources hosted by another service.

For example, imagine you install a project management app that wants to read your Google Calendar events. Without OAuth, the unsafe approach would be to give that app your Google email and password. That would be a serious security risk because the app could potentially access everything in your Google account.

OAuth 2.0 solves this by introducing delegated access.

Instead of handing over your password, you are redirected to Google, where you review what the app wants to access. If you approve, Google gives the app a temporary access token. The app can then use that token to access only the specific resources you allowed, such as your calendar events.

The key idea is:

> OAuth 2.0 allows applications to access resources without directly handling the user’s credentials.

It is important to understand that OAuth 2.0 is mainly about authorization, not authentication. Authorization answers: “What is this app allowed to access?” Authentication answers: “Who is this user?” In practice, OAuth is often used together with OpenID Connect, which adds authentication on top of OAuth 2.0.

The Main OAuth 2.0 Roles

OAuth 2.0 involves several parties. Understanding these roles makes the rest of the framework much easier to follow.

Resource Owner

The resource owner is usually the user. This is the person who owns the data or account being accessed.

Example: You own your Google Calendar data, so you are the resource owner.

Client

The client is the application requesting access.

Example: A scheduling app that wants to read your calendar events is the OAuth client.

The client may be:

Authorization Server

The authorization server is responsible for authenticating the user, asking for consent, and issuing tokens.

Example: Google’s OAuth server handles the login and consent process when an app requests access to your Google account.

Resource Server

The resource server hosts the protected data or API.

Example: The Google Calendar API is the resource server that returns your calendar events after receiving a valid access token.

Sometimes the authorization server and resource server are part of the same platform, but conceptually they have different responsibilities.

How OAuth 2.0 Works

OAuth 2.0 can feel confusing because there are several flows, also called grant types. However, the basic idea is consistent: the client requests permission, the user grants it, and the client receives a token.

A Typical OAuth Flow

Here is a simplified version of the most common modern flow, called the Authorization Code Flow:

1. The user clicks “Connect with Google” in an application.

2. The application redirects the user to Google’s authorization server.

3. Google asks the user to log in, if they are not already logged in.

4. Google shows a consent screen explaining what the app wants to access.

5. The user approves the request.

6. Google redirects the user back to the app with an authorization code.

7. The app exchanges that code for an access token.

8. The app uses the access token to call the protected API.

The important detail is that the access token is not sent directly through the browser URL in modern secure flows. Instead, the app receives a short-lived authorization code and exchanges it securely for tokens.

Example Authorization Request

An OAuth authorization URL may look something like this:

https://accounts.example.com/oauth/authorize?
client_id=abc123&
response_type=code&
scope=calendar.read&
redirect_uri=https://app.example.com/callback

This request tells the authorization server:

When building or debugging OAuth URLs, encoding issues can cause frustrating errors. A tool like the URL Encoder / Decoder can help you inspect redirect URIs, query parameters, and encoded callback URLs.

Access Tokens, Refresh Tokens, and Scopes

OAuth 2.0 is token-based. Instead of sending usernames and passwords to APIs, applications send tokens.

Access Tokens

An access token is a credential used to access a protected resource. The client sends it to an API, usually in the `Authorization` header:

Authorization: Bearer eyJhbGciOi...

The resource server validates the token and decides whether to return the requested data.

Access tokens are usually short-lived. This limits damage if a token leaks. Depending on the system, an access token might expire in minutes or hours.

Refresh Tokens

A refresh token is used to obtain a new access token without asking the user to log in again.

For example, a mobile app may use an access token for API requests. When the access token expires, the app sends its refresh token to the authorization server and receives a new access token.

Refresh tokens are more sensitive than access tokens because they can often be used for a longer period. They should be stored securely and never exposed in frontend JavaScript.

Scopes

Scopes define what the client is allowed to do.

Examples:

Scopes help implement the principle of least privilege. An app that only needs to read calendar events should not request permission to delete them.

When reviewing an OAuth implementation, always check whether the requested scopes are appropriate. Overly broad scopes are a common security and privacy problem.

OAuth 2.0 vs Login: A Common Misunderstanding

Many developers first encounter OAuth through “Login with Google,” “Login with GitHub,” or “Login with Facebook.” This leads to a common misunderstanding: OAuth 2.0 itself is not a login protocol.

OAuth 2.0 provides a way for an app to get access to resources. It does not define a standard way to retrieve a user’s identity.

That is where OpenID Connect, often abbreviated as OIDC, comes in.

OIDC is an identity layer built on top of OAuth 2.0. It introduces concepts like:

If your goal is “let users sign in,” you usually want OpenID Connect, not plain OAuth 2.0 alone.

Access Token vs ID Token

A useful distinction:

ID tokens are often JSON Web Tokens, or JWTs. If you are inspecting token payloads during development, a tool like the JWT Decoder can help you view the claims inside a token. Be careful not to paste production secrets or sensitive user tokens into tools unless you trust the environment.

Common OAuth 2.0 Grant Types

OAuth 2.0 supports multiple grant types for different application types. Some are recommended today, while others are outdated or discouraged.

Authorization Code Flow

This is the most common and recommended flow for server-side web apps.

It works well when the application can keep a client secret safe on the backend. The browser receives only an authorization code, and the backend exchanges that code for tokens.

Authorization Code Flow with PKCE

Authorization Code Flow with PKCE, pronounced “pixy,” is the recommended approach for public clients such as:

PKCE adds a temporary secret called a code verifier. This helps prevent attackers from stealing authorization codes and exchanging them for tokens.

For modern OAuth implementations, Authorization Code Flow with PKCE is often the safest default.

Client Credentials Flow

Client Credentials Flow is used for machine-to-machine communication.

There is no user involved. Instead, one backend service authenticates as itself to access another API.

Example: A billing service requests an access token to call an internal invoice API.

This flow is useful for service accounts, background jobs, and backend integrations.

Resource Owner Password Credentials Flow

This flow allows an app to collect the user’s username and password directly and exchange them for tokens.

It is generally discouraged and should be avoided in modern systems. It defeats one of OAuth’s major benefits: keeping user credentials away from third-party applications.

Implicit Flow

The Implicit Flow was once used for browser-based apps, but it is now considered outdated for most use cases. It returns tokens directly through the browser, which increases exposure risk.

Modern single-page applications should generally use Authorization Code Flow with PKCE instead.

Why OAuth 2.0 Matters for Security

OAuth 2.0 is widely used because it solves several real security problems.

It Avoids Password Sharing

Users should not have to give one app their password for another service. OAuth replaces password sharing with limited, revocable access tokens.

This means users can grant access to a third-party app and later revoke it without changing their password.

It Supports Least Privilege

OAuth scopes allow apps to request only the access they need.

For example, a reporting tool might need read-only access to analytics data but should not be able to modify account settings.

It Enables Centralized Access Control

With OAuth, the authorization server controls:

This makes access easier to audit and manage.

It Improves API Security

APIs can validate bearer tokens instead of handling passwords. Tokens can expire, be revoked, or be limited to specific audiences and scopes.

Many access tokens are formatted as JWTs, which are JSON-based. If you work with token payloads or API responses, the JSON Formatter is useful for making dense JSON easier to read during debugging.

Practical Example: Connecting a GitHub Account

Let’s walk through a real-world scenario.

Suppose you are building a developer dashboard that shows a user’s public and private GitHub repositories.

A secure OAuth-based approach would look like this:

1. Register your app in GitHub’s developer settings.

2. Configure an allowed redirect URI, such as https://yourapp.com/auth/github/callback.

3. Add a “Connect GitHub” button in your app.

4. Redirect the user to GitHub’s authorization endpoint with the required scopes.

5. GitHub shows the user a consent screen.

6. After approval, GitHub redirects back to your callback URL with a code.

7. Your backend exchanges the code for an access token.

8. Your backend stores the token securely or encrypts it before saving.

9. Your app uses the token to call the GitHub API.

The user never gives your app their GitHub password. They can also revoke your app’s access later from their GitHub account settings.

Best Practices for Developers

OAuth 2.0 is powerful, but it must be implemented carefully. Many security issues come from incorrect assumptions or weak configuration.

Use the Right Flow

For most modern apps:

Avoid Implicit Flow and Resource Owner Password Credentials Flow unless you have a very specific legacy reason.

Validate Redirect URIs Strictly

Authorization servers should only redirect to pre-registered, exact redirect URIs.

Avoid loose matching such as allowing any subdomain or partial URL match. Weak redirect URI validation can lead to authorization code theft.

Keep Tokens Secure

Access tokens and refresh tokens should be treated like credentials.

Good practices include:

Request Minimal Scopes

Only request the permissions your app actually needs. Users are more likely to trust an app that asks for reasonable access.

For example, if you only need to display a user’s email address, do not request full account management permissions.

Understand Token Validation

If your API receives access tokens, it must validate them correctly. Depending on your architecture, this may involve:

Never assume that a token is valid just because it “looks like” a JWT.

Frequently Asked Questions

What is OAuth 2.0 used for?

OAuth 2.0 is used to let applications access protected resources on behalf of a user or another system. Common examples include connecting a Google account, allowing an app to read GitHub repositories, authorizing payment integrations, and enabling backend services to call APIs securely.

Is OAuth 2.0 the same as authentication?

No. OAuth 2.0 is primarily for authorization, which means granting access to resources. Authentication, which verifies who the user is, is usually handled by OpenID Connect when using OAuth-based login systems.

What is the difference between an access token and a refresh token?

An access token is used to call protected APIs. It is usually short-lived. A refresh token is used to obtain new access tokens without requiring the user to log in again. Refresh tokens are more sensitive and should be stored very securely.

Is OAuth 2.0 secure?

OAuth 2.0 can be secure when implemented correctly. Security depends on using the right flow, validating redirect URIs, protecting tokens, using HTTPS, limiting scopes, and following current best practices such as Authorization Code Flow with PKCE for public clients.

Should single-page apps use the Implicit Flow?

In most modern applications, no. Single-page apps should generally use Authorization Code Flow with PKCE instead. The Implicit Flow is considered outdated because it exposes tokens more directly in the browser.

What is the difference between OAuth 2.0 and OpenID Connect?

OAuth 2.0 is an authorization framework for granting access to resources. OpenID Connect is an identity layer built on top of OAuth 2.0 that provides login and user identity information through ID tokens and standard user claims.