OAuth 2.0 is the authorization framework that makes "Sign in with Google" and "Connect your Slack workspace" possible. It is the protocol that allows a user to grant a third-party application limited access to their account on another service, without ever sharing their password. Every modern web application that integrates with external APIs uses OAuth 2.0 in some form. When I build a custom application that needs to pull data from a client's Google Workspace, sync with their HubSpot CRM, or post to their social media accounts, OAuth 2.0 is the mechanism that makes that access secure and revocable. The user clicks a button, gets redirected to the provider, approves the permissions, and the application receives a token. No credentials are exchanged, and access can be revoked at any time.
Before OAuth 2.0
Before OAuth existed, integrating with third-party services was genuinely dangerous. The standard practice was to ask users for their username and password, store those credentials, and use them to log in on the user's behalf. Twitter apps, email clients, banking aggregators, they all did this. If any one of those applications got breached, the attacker had direct access to the user's actual account. OAuth 1.0 was created in 2007 by Blaine Cook (who was working on Twitter's API at the time) and Chris Messina, along with contributions from Larry Halff of Ma.gnolia. It solved the core problem but was notoriously complex to implement, every request required cryptographic signatures, and the flow had multiple steps that developers constantly got wrong. OAuth 2.0 was published as RFC 6749 in October 2012, authored by Dick Hardt of Microsoft. It simplified the protocol dramatically by relying on HTTPS for security instead of signatures, introduced multiple grant types for different use cases, and became the de facto standard within a year of publication.
What Makes It Different
The most commonly misunderstood thing about OAuth 2.0 is that it is an authorization protocol, not an authentication protocol. It tells your application what a user has permission to access, not who the user is. OpenID Connect (OIDC) was built on top of OAuth 2.0 in 2014 to add the identity layer, that is what actually powers "Sign in with Google." The other critical concept is the distinction between grant types. The Authorization Code flow (with PKCE, pronounced "pixie") is what you use for web and mobile apps where the user is present. The Client Credentials flow is for server-to-server communication with no user involved. The Implicit flow, which sent tokens directly through URL fragments, was once the standard for single-page apps but has been officially deprecated since 2019 because it was vulnerable to token leakage. Modern SPAs now use Authorization Code with PKCE exclusively. Every time I see an application still using the Implicit flow, it is a security red flag.
Visit: oauth.net