Cybersecurity glossary
What is OAuth 2.0?
Learn what OAuth 2.0 is, how authorization grants delegate access without sharing passwords, which roles and tokens matter, and which security practices keep OAuth deployments safe.
Definition
OAuth 2.0 is an authorization framework that lets a user or system grant a client application limited access to protected resources without sharing the resource owner’s primary credentials, typically by issuing access tokens to the client.
Why OAuth 2.0 matters
Users should not type their Google, Microsoft, or corporate passwords into every third-party app. OAuth 2.0 standardizes delegated authorization: the user approves limited access, and the client receives tokens instead of the user’s password.
That model powers “Sign in with…”, API integrations, mobile apps, and machine-to-machine access. Misconfigured OAuth, however, becomes an account-takeover factory—so understanding roles, grants, and token handling is mandatory for secure product design.
Core OAuth roles
Resource owner
The user or system that owns the data and grants consent.
Client
The application requesting access on the owner’s behalf.
Authorization server
Authenticates the owner (as needed) and issues tokens.
Resource server
The API that validates access tokens and serves protected resources.
How a common authorization code flow works
Client redirects to authorize
The user is sent to the authorization server with client ID, scopes, redirect URI, and PKCE challenge.
User authenticates and consents
The authorization server verifies identity and shows the permission prompt.
Authorization code returns
The browser is redirected to the registered redirect URI with a short-lived code.
Client exchanges the code
The client calls the token endpoint with the code and PKCE verifier (and secret if confidential).
Tokens are issued
Access token (and optionally refresh/ID tokens) are returned to the client.
API calls use the access token
The resource server authorizes requests based on token validity and scopes.
Tokens and scopes
| Item | Purpose |
|---|---|
| Access token | Presented to APIs to access resources; keep short-lived |
| Refresh token | Obtain new access tokens; protect like a password |
| Scope | Limits token privileges to consented permissions |
| Redirect URI | Exact callback endpoint allowed to receive codes/tokens |
Security essentials
- Prefer authorization code with PKCE; avoid implicit grant for new applications.
- Register and enforce exact redirect URIs; reject open redirects.
- Use least-privilege scopes and require re-consent when expanding them.
- Protect refresh tokens with rotation, binding, and secure storage.
- Validate tokens fully on resource servers (signature, issuer, audience, expiry, scopes).
- Treat mobile/public clients as unable to keep long-term secrets.
- Monitor anomalous consent grants and token usage patterns.
- Follow OAuth 2.0 Security Best Current Practice (RFC 9700) in design reviews.
OAuth vs OpenID Connect
OAuth grants access to APIs. OpenID Connect builds on OAuth to authenticate users and issue ID tokens that assert identity. Many “social login” products implement both. Choose intentionally: authorization for APIs, OIDC when you need standardized login identity.
The practical takeaway
OAuth 2.0 delegates authorized access via tokens instead of shared passwords. Used well, it enables secure integrations with least privilege. Used carelessly—with loose redirects, overbroad scopes, or stolen refresh tokens—it becomes a privileged backdoor.
Design flows around modern grants, strict redirect validation, short-lived access tokens, and careful refresh-token handling. For failure modes, see OAuth Misconfiguration and OAuth Token Theft.
Related security terms
OpenID Connect (OIDC)
An identity layer commonly built on OAuth 2.0 for authentication and ID tokens.
OAuth Misconfiguration
Common deployment mistakes that undermine OAuth security.
OAuth Token Theft
How stolen access or refresh tokens lead to account and data compromise.
JWT (JSON Web Token)
A token format frequently used for OAuth access tokens and OIDC ID tokens.
Single Sign-On (SSO)
Broader SSO architectures that often incorporate OAuth/OIDC.
Frequently asked questions
What is OAuth 2.0 in simple terms?
OAuth 2.0 is a way to let an app access some of your data on another service—like photos or calendar—without giving that app your password. You approve access and the app receives a token with limited permissions.
Is OAuth 2.0 authentication or authorization?
OAuth 2.0 is primarily an authorization framework for delegated access. OpenID Connect adds an authentication layer on top for logging users in.
What are the main OAuth roles?
Resource owner (usually the user), client (the application), authorization server (issues tokens), and resource server (API that accepts tokens).
What is the authorization code grant?
A common, browser-friendly flow where the client receives a temporary code and exchanges it at the token endpoint for tokens—preferably with PKCE for public clients.
What are scopes?
Scopes are permission labels that limit what an access token is allowed to do, such as read-only profile access versus write access.
Should clients use the implicit grant?
No for new systems. Implicit was historically used by browser apps but is discouraged; prefer authorization code with PKCE.
What is the difference between access and refresh tokens?
Access tokens authorize API calls and should be short-lived. Refresh tokens obtain new access tokens and must be stored and rotated carefully.
References
Explore authoritative guidance and frameworks related to oauth 2.0.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.