What is OAuth?

The problem OAuth solves

Before OAuth caught on, an app that wanted to read your calendar would simply ask for your email password. That handed it unlimited, hard-to-revoke control over the whole account. OAuth inverts the arrangement: you sign in only at your own account provider, approve a specific set of permissions, and the app receives an access token limited to those permissions. You can revoke it later without changing your password.

The four roles

• Resource owner — usually the end user.
• Client — the application requesting access: a web app, mobile app, desktop app or another service.
• Authorization server — authenticates the user, collects consent and issues tokens.
• Resource server — the API holding the protected data, which validates the token on each request.

Authorization code flow with PKCE

For anything involving a user, the recommended flow today is the authorization code grant with PKCE (RFC 7636). The client generates a random code_verifier, hashes it with SHA-256 into a code_challenge, and sends the user to the authorization server:

GET /authorize?response_type=code
  &client_id=calendar-app
  &redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
  &scope=calendar.read
  &state=af0ifjsldkj
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256

1. The user signs in at the authorization server and approves the calendar.read scope.
2. The server redirects back to redirect_uri with a short-lived, single-use code. The client checks that the returned state matches the one it sent.
3. The client posts the code plus the original code_verifier to the token endpoint and receives an access token, optionally with a refresh token.
4. API calls then carry the token in an Authorization: Bearer ... header.

Because an attacker who intercepts the code does not know the verifier, a stolen code is useless. That makes PKCE effectively mandatory for single-page and mobile apps, which cannot keep a client secret, and the OAuth 2.0 Security Best Current Practice (RFC 9700) recommends it for confidential server-side clients as well.

Other grants

Machine-to-machine calls with no user involved use the client credentials grant. Input-constrained devices such as smart TVs use the device authorization grant. The legacy implicit grant and the resource owner password credentials grant, which hands the user's password straight to the client, should no longer be used according to current security guidance.

OAuth vs OpenID Connect

The most persistent misconception is that OAuth is a login protocol. An access token is meant for the resource server; it does not reliably tell the client who the user is or how they were authenticated. OpenID Connect (OIDC) fills that gap: when the client requests the openid scope, the authorization server also returns a signed ID token addressed to the client — a JWT describing the user and the authentication event. "Sign in with Google" buttons are OIDC, not bare OAuth. In short, OAuth handles authorization; OIDC adds authentication.

Integration mistakes to avoid

• Matching redirect_uri loosely (wildcards, prefixes) instead of exactly against the registered value.
• Skipping state and leaving the callback open to CSRF.
• Requesting broader scopes than needed — a read-only calendar app should not ask for write access.
• Treating an access token as proof of identity instead of validating the ID token.
• Storing refresh tokens carelessly; they live longer and are worth more than access tokens.