What Is OAuth?

OAuth is an authorization framework that allows one application to access resources in another service on a user’s behalf without exposing the user’s password. Instead of sharing credentials, OAuth uses tokens with defined permissions and limits. That makes it a core part of modern API security, SaaS integrations, and cloud identity workflows.

How OAuth works

The easiest way to think about OAuth is this: it separates authorization from credential sharing.

Without OAuth, a third-party app might ask for your username and password to read your calendar or contacts. That is risky because the app now has your actual credentials. With OAuth, the app redirects you to the service that owns the account, you log in there, review what the app wants, and the service returns a token instead of your password.

The basic flow

A typical OAuth flow involves four parts:

• Resource owner: usually the user
• Client: the application requesting access
• Authorization server: the service that authenticates the user and issues tokens
• Resource server: the API or data source the app wants to access

The sequence generally looks like this:

1. An app asks for access to a service
2. The user is redirected to the authorization server
3. The user signs in and approves requested permissions
4. The authorization server issues a token
5. The app uses that token to access the approved resource

The token tells the resource server what the app is allowed to do.

Tokens and scopes

OAuth typically relies on access tokens, and sometimes refresh tokens, depending on the implementation.

• Access token: used to call an API or access a protected resource
• Refresh token: used to obtain a new access token without prompting the user again
• Scope: defines what level of access the application is requesting

For example, an app might request permission to:

• Read your profile
• View your calendar
• Send email through an API
• Access files in a cloud storage account

Those permissions should be limited to what the app actually needs. Overly broad scopes create unnecessary risk.

OAuth is about authorization, not identity

This is where people often get confused. OAuth is primarily for authorization, not authentication.

It answers the question:

• “What is this app allowed to access?”

It does not, by itself, fully answer:

• “Who is this user?”

In many environments, OAuth is used alongside OpenID Connect (OIDC), which adds identity information on top of OAuth-style flows. If you want the identity side explained, see what is sso.

Why OAuth matters

OAuth is everywhere in modern IT because cloud services, SaaS apps, APIs, and mobile apps constantly need controlled ways to connect to one another.

It is commonly used for:

• Third-party integrations
• API access
• Mobile app sign-in flows
• Enterprise SaaS connections
• Automation platforms
• “Sign in with Google/Microsoft/GitHub”-style experiences

Done correctly, OAuth is safer than handing apps long-lived passwords. Done poorly, it can still create serious exposure.

Security risks and common failure points

OAuth improves security when it is implemented and governed well, but it is not automatically safe.

Overbroad permissions

If an app gets more access than it needs, a compromised or malicious app can expose far more data than intended.

Consent phishing

Attackers sometimes trick users into approving access for a malicious app. The login page may be real, but the application requesting access is not trustworthy. The user effectively authorizes the attacker through the consent flow.

Token theft

If access or refresh tokens are stolen, an attacker may be able to act as the user or application until the token expires or is revoked.

Weak app governance

Organizations often accumulate many connected SaaS and API integrations over time. Without governance, old or risky OAuth grants remain active longer than they should.

When you’ll encounter OAuth

You will run into OAuth any time applications need to connect without passing around raw credentials.

In SaaS integrations

When one cloud app connects to another, OAuth is often the mechanism used to authorize that access. Examples include calendar sync, CRM integrations, file sharing automations, and collaboration platform add-ons.

In API security work

Developers and security teams regularly deal with OAuth when protecting APIs. Tokens, scopes, token lifetimes, client registrations, and redirect URIs all become part of the security conversation.

In identity and access management

IAM teams encounter OAuth when reviewing third-party app access, user consent settings, service integrations, and token policies.

In incident response

OAuth becomes relevant during investigations involving suspicious app consent, cloud account misuse, unauthorized integrations, or token theft. In some cloud intrusions, the attacker does not need the user’s password after obtaining the right token or app approval.

For a related concept around centralized authentication, read what is sso.

Practical security guidance

From a defensive standpoint, OAuth should be treated as part of your identity attack surface.

Useful controls include:

• Limiting user consent to trusted apps
• Reviewing granted app permissions regularly
• Enforcing least privilege for scopes
• Monitoring risky or newly approved applications
• Protecting refresh tokens and secrets
• Revoking unused or suspicious grants

If your organization uses SaaS heavily, OAuth governance is not optional.

For users managing many accounts across cloud services, a password manager like 1Password can still help reduce credential reuse and improve account hygiene, even though OAuth itself is designed to avoid password sharing between apps.

Bottom line

OAuth is a way to grant applications limited access to accounts, APIs, and services without sharing passwords. That makes it foundational to modern cloud and API security, but also a common source of risk when tokens, permissions, or third-party app approvals are not tightly controlled.