OAuth 2.0
Also known as: OAuth, OAuth2, Authorization Code Flow, PKCE, access token
OAuth 2.0 is a protocol that lets one application act on your behalf with another application, without sharing your password.
When you click 'Sign in with Google', OAuth 2.0 is how Google grants the app limited access (your email address, maybe your profile) without ever giving the app your Google password.
OAuth 2.0, explained at three levels
At home
When you click 'Continue with Google' on a new app, OAuth 2.0 is what happens. Google asks you 'Do you want to share your name and email with this app?' You say yes. The app gets your info from Google, but never sees your Google password.
At work
OAuth 2.0 is the standard that lets one application access another on a user's behalf without sharing passwords. Instead of a password, the app receives a token limited to specific permissions, called scopes, that can expire or be revoked. Businesses care because integrations between tools such as Salesforce, Slack, and Google Workspace become safer to approve, audit, and shut off when an employee leaves.
At home
OAuth 2.0 flow (Authorization Code): 1) App redirects you to the authorization server (Google), 2) You authenticate and consent, 3) Google redirects back with an authorization code, 4) App exchanges the code for tokens behind the scenes. Result: an access token (short-lived, used for API calls) and a refresh token (long-lived, used to get new access tokens).
At work
OAuth 2.0 grant types include Authorization Code (web and mobile apps, the most common), Client Credentials (service-to-service, no user involved), Device Code (added later for smart TVs and command-line tools), and the deprecated Implicit and password grants. Scopes define what access is requested (email, profile, calendar.read). The PKCE extension (Proof Key for Code Exchange) secures the Authorization Code flow for public clients.
At home
OAuth 2.0 is an authorization framework, not an authentication protocol: access tokens don't inherently tell you who the user is. OpenID Connect (OIDC) adds an ID token (a JWT with user claims) to the OAuth flow, providing authentication. This distinction matters: OAuth for 'can this app access this resource', OIDC for 'who is this user'.
At work
In enterprise OAuth 2.0 deployments, authorization servers (Okta, Auth0, Microsoft Entra ID, Keycloak) centralize token issuance. Token introspection lets resource servers validate opaque tokens. JWT access tokens (RFC 9068) embed claims directly, enabling stateless validation without server-side lookups. OAuth 2.0 Security Best Current Practices (RFC 9700) consolidates security guidance, deprecating implicit flow and enforcing PKCE.
Real-world examples
At home
Sophie uses 'Sign in with GitHub' on a developer tool she just discovered. GitHub asks if the tool can see her email and public repos. She approves, and the tool creates her account: no new password to create or remember.
At work
Marcus's company integrated their internal app with Slack using OAuth 2.0. Users authorize the app once; the app stores refresh tokens to post notifications to Slack channels on their behalf without re-prompting.
Common confusions
- OAuth 2.0 is an authentication protocol — OAuth 2.0 is an authorization protocol: it controls what a client can access, not who the user is. OpenID Connect (OIDC), built on OAuth 2.0, adds authentication. Many developers confuse the two because they're often used together.
- OAuth 2.0 means single sign-on — OAuth 2.0 is a mechanism; SSO is the user experience. OAuth can enable SSO (if the same authorization server is used across apps), but OAuth itself is about delegated authorization, not session federation.
For analysts
When a business analyst requests access to a data source that uses OAuth 2.0 (Google Analytics API, Salesforce API), understanding the protocol helps explain why access tokens expire, why re-authorization prompts appear, and why different scopes control what data can be pulled.
History & origin
OAuth 1.0 was created in 2006 to solve a specific problem: Twitter apps needed to post on users' behalf without storing Twitter passwords. OAuth 2.0 (RFC 6749) was standardized in 2012, simplifying OAuth 1.0's cryptographic signing requirements in favour of HTTPS for security. It became the universal authorization standard used by Google, Facebook, GitHub, Microsoft, and virtually every modern API. OpenID Connect (OIDC) was built on top of OAuth 2.0 to add authentication (who are you) to OAuth's authorization (what can you do).