OAuth 2.0 is a protocol for delegated authorization. In plain English, it lets one app get limited access to something on behalf of a user, without giving that app the user's password.

A calendar app can read a user's Google Calendar, a deployment tool can access a GitHub repository, or a reporting service can read data from another SaaS product, all without ever seeing the user's password.

OAuth 2.0 is about access, not login. When people say "Login with Google," they are usually talking about OpenID Connect (OIDC), which adds login and identity on top of OAuth 2.0. OAuth gives an app an access token for APIs. OIDC adds an ID token that tells the app who the user is.

The recommendations in this chapter follow OAuth 2.1 style guidance: use PKCE, avoid the Implicit grant, avoid the Resource Owner Password Credentials grant, and match redirect URIs exactly.

Before OAuth, integrations often required users to hand over their username and password to another app.

For example, a photo printing app might ask for a user's photo service password so it could fetch albums. That model is unsafe: the app sees the user's password, usually gets more access than it needs, and cannot be revoked without changing the password.

A breach of the app exposes credentials for the original service, and MFA and modern login policies become difficult to enforce.

OAuth fixes this by introducing an authorization server that issues access tokens.

Instead of giving the app a password, the user approves limited access. The app receives a token with a scope, lifetime, and audience. The API accepts that token only for the access it represents.

OAuth separates three decisions: