OAuth is an open standard framework for delegated authorization. It lets one application, called the client, get limited access to an API or account on a user’s behalf, or on its own behalf, by obtaining a token instead of handling the user’s password. When you connect a scheduling tool to your calendar and approve “read your calendar”, OAuth is usually what issues the token behind that approval, typically limited in what it allows and how long it lasts, depending on the provider. OAuth 2.0, published through the IETF, is the version in common use today.
At a glance
- Authorization, not authentication: OAuth controls what an app can access, not who the user is.
- An authorization server issues tokens; the API (the resource server) checks them and is responsible for enforcing what they allow.
- Scopes describe what a token is meant to allow, such as read-only access to a calendar; how fine-grained they are depends on the provider.
- Used for user-approved app connections, service-to-service API access and many SaaS integrations.
- OpenID Connect (OIDC) adds a sign-in layer on top of OAuth 2.0.
What problem it solves
Before OAuth, a common way to let one service use another was to give it your password. The service then had full access to your account, you could not limit or revoke it without changing the password, and a breach at that service exposed your credentials. Machine integrations had similar problems with long-lived shared API keys.
OAuth replaces this with tokens. The framework lets an authorization server issue tokens limited to specific permissions, with set lifetimes, that can be withdrawn without changing the user’s password, although how narrow the scopes are, how long tokens last, whether revocation is supported and how strictly each API enforces them depend on the provider and the API. The user, or an administrator, approves what the app may do. The API checks the token rather than a password. For a business, this means integrations between SaaS applications can often be granted narrowly and cut off individually, and APIs can apply consistent access rules across partners and internal services.
How it works
Roles. OAuth defines four parties: the resource owner (usually the user), the client (the application wanting access), the authorization server (which authenticates the user and issues tokens, often your identity provider (IdP) or the SaaS platform itself) and the resource server (the API).
Authorization request. For user-delegated access, the client sends the user’s browser to the authorization server, listing the scopes it wants. The user signs in and approves, or an administrator has already approved on the organization’s behalf.
Authorization code and token exchange. The authorization server returns a short-lived code to the client, which exchanges it for an access token at the server’s token endpoint. Current guidance recommends adding PKCE (Proof Key for Code Exchange) to this flow, so an intercepted code cannot be redeemed by someone else.
Calling the API. The client presents the access token to the API, which should check that it is valid, unexpired and carries the scope needed for the request. That enforcement is the API’s job, so its quality varies.
Refresh tokens. Access tokens are usually short-lived. A client may also receive a refresh token to get new access tokens without asking the user again; refresh tokens often last much longer and are a common target for attackers.
Machine-to-machine access. In the client credentials flow, a service authenticates as itself to get a token, with no user involved. These service identities are a growing part of the non-human identity estate.
Older flows, such as the implicit grant and sending a username and password directly to the client, are discouraged in current guidance, and OAuth 2.1 is a draft effort that consolidates these recommendations.
When it matters for buyers
- When reviewing connected apps. Users and admins grant OAuth access to third-party apps in Microsoft 365, Google Workspace, Salesforce and other platforms. Periodically review which apps hold which scopes and remove what is not needed.
- When consent phishing is a risk. Restricting user consent to approved apps, or requiring admin approval for high-risk scopes, limits attacks that trick users into granting access.
- When exposing APIs. If you publish APIs to partners or customers, decide how clients get tokens, which scopes exist and how tokens are validated. Our web application and API protection overview covers protecting those APIs.
- When buying SaaS that integrates with other SaaS. Ask what scopes the integration needs and whether narrower ones are available.
Questions to ask vendors
- Which OAuth 2.0 flows do you support, and do you require PKCE for user-facing clients?
- What scopes does your integration request, and can it work with narrower ones?
- How fine-grained are your scopes, and does each API endpoint enforce them?
- How long do your access and refresh tokens last, and can we change those lifetimes?
- Do you support token and grant revocation, and how quickly do your APIs stop accepting a revoked token?
- Do you support OpenID Connect if we also need user sign-in?
- How do you log token issuance and API calls made with tokens?
- For machine-to-machine access, do you support certificate-based or other non-secret client authentication?
How it differs from SAML
Security Assertion Markup Language (SAML) is an authentication and federation standard: an identity provider sends an application a signed XML assertion saying who the user is, typically to deliver single sign-on (SSO) to web applications. OAuth is an authorization framework: it issues tokens that let an application call an API with the permissions those tokens were granted, and on its own it does not tell the application who the user is. The two often coexist. A user might sign in to a SaaS app with SAML, and that app then uses OAuth to call another service’s API. When an application needs both sign-in and API access in one modern design, OpenID Connect, built on OAuth 2.0, usually fills the sign-in role.