OAuth 2.0: Delegated Access, Not Shared Passwords

WHY IT EXISTS The original problem was simple but dangerous: to let a third-party app access your data on another service, you had to give it your username and password. This gave the app full control and exposed your credentials if the app was ever breached. OAuth was created to solve this password anti-pattern.

THE MENTAL MODEL Think of OAuth 2.0 as a hotel key card system for the internet. You (the user) don't give your master key (password) to a temporary service (a third-party app). Instead, the front desk (the service provider, like Google) issues a temporary key card (an access token) to the service. This key card only grants access to specific areas (e.g., your calendar, but not your email) for a limited time. You can revoke this key card at any time from your Google account settings without changing your password.

HOW IT WORKS The flow is a redirection dance. First, the user tells an application (the "client") they want to access data from a service (the "resource server," like Google). The client redirects the user to Google. The user logs into Google and sees a consent screen asking to approve the requested permissions. If approved, Google redirects the user back to the client with a temporary authorization code. The client then secretly exchanges this code with Google for an access token. This token is the key the client uses to make API calls on the user's behalf.

WHEN TO USE IT Use OAuth 2.0 whenever a third-party application needs to act on behalf of a user within another service. It's the standard for API access delegation. Common cases include a social media management tool posting to a user's Twitter feed or a CRM pulling contact data from a user's Google account.

WHEN NOT TO USE IT Do not use OAuth 2.0 by itself for authentication (i.e., just for logging a user in). While many "Sign in with..." buttons use OAuth, they are typically layered with another protocol like OpenID Connect (OIDC) which is built on top of OAuth 2.0 to handle identity verification. Raw OAuth 2.0 is for authorization (what you can do), not authentication (who you are).

ONE CANONICAL EXAMPLE A user wants a new app, "ChartMyRun," to import their workout history from their Nike account. ChartMyRun redirects the user to Nike's login page. The user logs in and grants ChartMyRun permission to "read workout history." Nike sends the user back to ChartMyRun with a code. ChartMyRun exchanges the code for an access token, which it then uses to fetch the workout data from the Nike API. The app never sees the user's Nike password.