--- title: "OAuth 2.0 — Identity Glossary | IDSync" description: "OAuth 2.0 is an authorization framework that lets a user grant a third-party application limited access to their data on another service without sharing…" lang: en json-ld: | [ { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://idsync.com/" }, { "@type": "ListItem", "position": 2, "name": "Glossary", "item": "https://idsync.com/glossary" }, { "@type": "ListItem", "position": 3, "name": "OAuth 2.0", "item": "https://idsync.com/glossary/oauth-2" } ] }, { "@context": "https://schema.org", "@type": "DefinedTerm", "@id": "https://idsync.com/glossary/oauth-2", "name": "OAuth 2.0", "alternateName": [ "Open Authorization 2.0", "OAuth", "OAuth2" ], "description": "OAuth 2.0 is an authorization framework that lets a user grant a third-party application limited access to their data on another service without sharing their password.", "url": "https://idsync.com/glossary/oauth-2", "inDefinedTermSet": "https://idsync.com/glossary" }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Is OAuth 1.0 still used?", "acceptedAnswer": { "@type": "Answer", "text": "Only in a handful of legacy APIs (some older Twitter / X endpoints). New work should always be OAuth 2.0 or 2.1." } }, { "@type": "Question", "name": "What's the difference between a scope and a permission?", "acceptedAnswer": { "@type": "Answer", "text": "Scope is what the *client* is asking for. Permission is what the user actually grants and what the resource server enforces. They overlap but aren't synonyms." } } ] } ] --- [![IDSync — identity software buyer platform](/assets/idsync-logo-BKS89EW4.png)](/) [Directory](/directory) [Compare](/compare) [Resources](/resources) [Browse tools](/directory)[Run Stack Finder](/stack-finder) 1. [Home](/) 2. [Glossary](/glossary) 3. OAuth 2.0 Standards & Protocols # OAuth 2.0 (Open Authorization 2.0) OAuth 2.0 is an authorization framework that lets a user grant a third-party application limited access to their data on another service without sharing their password. Last reviewed 3 months ago Key points - OAuth is about authorization (delegated access), not authentication. - Core artifacts: access token (short-lived, used to call APIs) and refresh token (long-lived, used to mint new access tokens). - Authorization Code flow with PKCE is the modern default for web, mobile, and SPA clients. - OAuth 2.1 consolidates a decade of best practices and deprecates the implicit and password grant flows. - For authentication, layer OpenID Connect on top — OAuth alone is the wrong tool. ## What is OAuth 2.0? OAuth 2.0 is an open standard (RFC 6749) for **delegated authorization**. It lets a user say "yes, this third-party app can read my Google Calendar" without ever handing that app their Google password. The app gets a scoped, time-limited **access token**; the user's credentials stay with the identity provider. OAuth is _not_ a login protocol. It does not tell your application who the user is in a trustworthy way. For that you want [OpenID Connect](/glossary/openid-connect), which builds an identity layer on top of OAuth. ## How OAuth works The recommended flow for almost every modern client is the **Authorization Code flow with PKCE**: 1. Your app (the **client**) sends the user to the authorization server's `/authorize` endpoint with a list of requested **scopes**. 2. The user authenticates with the authorization server (often the IdP) and approves the scopes. 3. The authorization server redirects back with a short-lived **authorization code**. 4. Your app's backend exchanges the code + PKCE verifier at the `/token` endpoint for an access token and (optionally) a refresh token. 5. Your app calls the resource server's APIs with `Authorization: Bearer `. Access tokens are typically opaque to the client (the resource server validates them via introspection or as JWTs). They are short-lived (minutes to an hour) and refreshed using the refresh token, which is long-lived but bound to the client. ## When buyers care about OAuth OAuth is foundational whenever your app needs to: - Let users sign in with a third-party account (combined with OIDC). - Integrate with third-party APIs on the user's behalf (Slack, Salesforce, GitHub, Google). - Protect your own APIs that are called from mobile apps, single-page apps, partners, or AI agents. - Issue short-lived, scoped tokens to machines and AI agents (see [AI Agent Identity](/glossary/ai-agent-identity)). ## OAuth grant types - **Authorization Code (+ PKCE)** — the default for almost everything. - **Client Credentials** — machine-to-machine, no user involved. - **Device Authorization Grant** — TVs, CLIs, devices without a browser. - **Refresh Token** — used to mint new access tokens. - **Implicit** — deprecated. Don't use. - **Resource Owner Password Credentials (ROPC)** — deprecated. Don't use. ## OAuth 2.0 vs OAuth 2.1 OAuth 2.1 is not a new protocol — it's a consolidation of best practices that have emerged since 2012. The major changes: - PKCE required for all clients using the Authorization Code flow. - Implicit flow removed. - ROPC flow removed. - Exact redirect URI matching required. - Refresh tokens for public clients must be sender-constrained or rotated. If you're building new, target 2.1. ## Common pitfalls - **Using OAuth for authentication.** Layer OIDC on top. - **Storing access tokens in localStorage.** Vulnerable to XSS. Prefer httpOnly cookies or in-memory storage with refresh rotation. - **Long-lived access tokens.** Defeats the point. Keep them short and rely on refresh tokens. - **Wide scopes.** Ask for the minimum scope you need. "All access" is a red flag for buyers. ## FAQ ### Is OAuth 1.0 still used? Only in a handful of legacy APIs (some older Twitter / X endpoints). New work should always be OAuth 2.0 or 2.1. ### What's the difference between a scope and a permission? Scope is what the _client_ is asking for. Permission is what the user actually grants and what the resource server enforces. They overlap but aren't synonyms. ## Standards & references - [RFC 6749 — OAuth 2.0 Authorization Framework](https://datatracker.ietf.org/doc/html/rfc6749) - [OAuth 2.1 draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/) IDSync provides educational buyer guidance based on publicly available information, editorial review, and user-submitted data. Vendor information should be verified before purchase. [Who we are, our methodology & disclosure policy](/about). ### One identity concept, explained per issue Get vendor-neutral identity explainers and market updates in your inbox. Work email\* Name Company Role (optional) Interests (optional) Pick what you want more of. IAMCIAMSSO/MFAIGA/PAMSCIM/provisioningAI agent identityVendor updatesSecurity incidents Subscribe Twice-monthly identity digest. Curated, vendor-neutral. Unsubscribe any time. ### Vendor categories [ciam](/directory/category/ciam)[iam platforms](/directory/category/iam-platforms)[api security](/directory/category/api-security) ### Related terms [openid connect](/glossary/openid-connect)[jwt](/glossary/jwt)[pkce](/glossary/pkce)[single sign on](/glossary/single-sign-on) ### Not sure which tool you need? Run the IAM Stack Finder for a vendor-neutral shortlist tailored to your stack. [Run the Stack Finder](/stack-finder) ### Explore tools for this topic Browse vetted vendors in the ciam category. [Explore tools](/directory/category/ciam) [![IDSync home](/assets/idsync-logo-BKS89EW4.png)](/) The buyer-focused platform for identity, access, and authentication software. #### Platform - [Home](/) - [IAM Stack Finder](/stack-finder) - [Directory](/directory) - [Resources](/resources) - [State of AI Agent Identity 2026](/reports/state-of-ai-agent-identity-2026) - [Buyer Guides](/guides) - [Glossary](/glossary) - [Newsletter](/newsletter) - [Newsletter Archive](/newsletter/archive) #### Best of guides - [All comparisons](/compare) - [All vendor alternatives](/alternatives) - [Best SSO tools](/compare/best-sso-tools) - [Best MFA tools](/compare/best-mfa-tools) - [Best PAM tools](/compare/best-pam-tools) - [Best IGA tools](/compare/best-iga-tools) - [Best CIAM tools](/compare/best-ciam-tools) - [Best passwordless auth](/compare/best-passwordless-authentication-tools) - [Best identity security](/compare/best-identity-security-tools) - [Best machine identity](/compare/best-machine-identity-tools) - [Best SaaS access governance](/compare/best-saas-access-governance-tools) - [Best developer auth](/compare/best-developer-authentication-tools) - [Best for startups](/compare/best-iam-tools-for-startups) - [Best for enterprises](/compare/best-iam-tools-for-enterprises) - [Best SCIM tools](/compare/best-scim-provisioning-tools) - [Best for AI agents](/compare/best-ai-agent-identity-tools) - [Best NHI tools](/compare/best-nhi-management-tools) - [Okta pricing explained](/guides/okta-pricing) - [Auth0 pricing explained](/guides/auth0-pricing) - [Okta alternatives](/alternatives/okta) - [Auth0 alternatives](/alternatives/auth0) #### For Vendors - [Sponsor](/sponsor) - [Badges](/badges) - [Submit Product](/submit-product) - [Claim Profile](/claim-profile) - [Partner](/partner) #### Company - [About & Methodology](/about) - [Contact](/contact) - [Privacy](/privacy) Vendor names, logos, and trademarks are the property of their respective owners. IDSync is an independent buyer resource and does not imply endorsement unless explicitly stated. Logos are displayed for identification purposes only. IDSync (idsync.com) is operated by TetraCore, Bowling Green, Ohio. It is not affiliated with the IDSync® Active Directory synchronizer by Identity Syncronizer — [learn more](/about#idsync-disambiguation). © 2026 IDSync. All rights reserved. Editorial independence. Sponsored placements are clearly disclosed.