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 allows your company's apps to connect to each other and to third-party services without employees sharing passwords. When Salesforce needs to access Google Calendar, OAuth 2.0 grants that access securely, with the user controlling what's shared.
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 defines four grant types: Authorization Code (web apps, most common), Client Credentials (service-to-service, no user involved), Implicit (deprecated, was for SPAs), and Device Code (smart TVs, CLIs). Scopes define what access is being requested (email, profile, calendar.read). The PKCE extension (Proof Key for Code Exchange) secures 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, Azure AD, 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 favor 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).