OAuth 2.0 is a protocol for delegated authorization.

It lets one application access a protected resource on behalf of a user without asking for 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 credentials.

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

The recommendations in this chapter follow OAuth 2.1: PKCE everywhere, no Implicit grant, no Resource Owner Password Credentials, and exact redirect URI matching.

Before OAuth, third-party integrations often required users to hand over their username and password.

For example, a photo printing app might ask for a user's photo service password so it could fetch albums. That model is bad on every axis: the third-party app sees the user's password, usually gets broader 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 client a password, the user approves limited access. The client receives a token with a scope, lifetime, and audience. The resource server accepts that token only for the access it represents.

OAuth separates three decisions: