OAuth 2.0

An authorization framework (RFC 6749) that lets a user grant a third-party app limited access to their resources on another service, without sharing their password.

The Problem It Solves

Before OAuth, if app A wanted to read your email from service B, you had to give A your B password. A could then do anything. OAuth replaces this with delegated, scoped, revocable tokens.

Authorization vs Authentication

OAuth 2.0 is about authorization (“what is this app allowed to do?”), NOT authentication (“who is this user?”). Conflating these is a common, dangerous mistake — see OpenID Connect for the layer that adds authentication.

The Four Roles

Role	Description	Example
Resource Owner	The user who owns the data	You
Client	The app wanting access	Some website
Authorization Server	Authenticates user, issues tokens	Google’s auth server
Resource Server	Hosts the protected resources	Google’s API

flowchart LR
    User((Resource Owner))
    Client[Client App]
    AuthServer[Authorization Server]
    Resource[Resource Server]

    User -- "1. uses" --> Client
    Client -- "2. requests authorization" --> AuthServer
    AuthServer -- "3. authenticates" --> User
    User -- "4. consents" --> AuthServer
    AuthServer -- "5. issues token" --> Client
    Client -- "6. accesses with token" --> Resource

The Grant Types

OAuth 2.0 defines several “grants” (ways to get a token). The important ones for modern web/mobile:

Grant	Used For	Status
Authorization Code	Web apps, mobile, SPAs (with PKCE)	Current best practice
Implicit	Originally SPAs	Deprecated — use Authorization Code + PKCE
Resource Owner Password	Trusted first-party apps	Deprecated in OAuth 2.1
Client Credentials	Machine-to-machine	Still valid for service accounts
Refresh Token	Renewing access tokens	Valid; use with rotation

The flow that matters for Sign in with Google, Sign in with Apple, and basically all modern social login is the Authorization Code Flow.

Tokens

• Access token — short-lived (minutes to an hour), used to call the resource server. Often opaque, sometimes a JWT.
• Refresh token — long-lived, used to get new access tokens without re-prompting the user. Should be rotated.

OAuth 2.0 itself does NOT define an identity token — that’s OpenID Connect’s ID Token.

Pitfalls

• Treating an access token as proof of identity. It isn’t. It only proves “someone with appropriate permissions”. Use an ID Token for identity.
• Skipping the state parameter. Opens you to CSRF in the redirect step — see Social Login Security.
• Using the implicit grant. Tokens land in the URL fragment, leak via referrer headers / browser history. Authorization Code + PKCE is the answer.

See Also

• Authorization Code Flow
• PKCE
• OpenID Connect
• Authentication MOC