OAuth 2.0: Delegated Authorization, Not Authentication

WHY IT EXISTS: Before OAuth, if you wanted an app to access your data on another service (e.g., print your Google Photos), you had to give that app your Google username and password. This was insecure, giving the app full access forever. OAuth was created to solve this problem of delegated access securely, without sharing credentials.

THE MENTAL MODEL: Imagine you're staying at a hotel. You have a master key (your password) to your entire life's data. You want to let a cleaning service (a third-party app) into your room (your photos) but not let them into the hotel safe (your email). Instead of giving them your master key, you go to the front desk (the Authorization Server), prove who you are, and ask for a temporary key card (an Access Token) that only opens your room's door for a limited time. OAuth is this process of getting a limited-use key card.

HOW IT WORKS: The flow involves four roles: the Resource Owner (you), the Client (the third-party app), the Authorization Server (the service that verifies you, like Google), and the Resource Server (the service holding your data, like the Google Photos API). The client redirects you to the authorization server, where you log in and grant permission. The authorization server then gives the client an authorization grant (like an Authorization Code). The client exchanges this code for an Access Token, which it then uses to request your data from the resource server.

WHEN TO USE IT: Use OAuth 2.0 whenever a third-party application needs to access a user's data on another server. This is the standard for "Log in with Google/Facebook/GitHub" and for granting API access to services like Slack bots or CI/CD pipelines that need to access private repositories on a user's behalf.

WHEN NOT TO USE IT: Do not use OAuth 2.0 as a standalone authentication protocol. While it's often part of an authentication flow (like with OpenID Connect built on top), an access token by itself only proves the application has permission; it doesn't prove the user is currently present or who they are. Also, avoid the "Resource Owner Password Credentials" grant type; it requires the user to give their password to the client, defeating the primary purpose of OAuth.

ONE CANONICAL EXAMPLE: A user wants "PhotoPrintApp" to print photos from their "CloudPhotos" account. First, PhotoPrintApp (Client) redirects the user (Resource Owner) to CloudPhotos' login page (Authorization Server). Second, the user logs into CloudPhotos and approves the request. Third, CloudPhotos redirects back to PhotoPrintApp with a temporary Authorization Code. Fourth, PhotoPrintApp sends this code to CloudPhotos' API and receives a short-lived Access Token. Finally, PhotoPrintApp uses this token to fetch photos from the CloudPhotos API (Resource Server).