Skip to content
IT Atlas

Identity · Authorization

OAuth 2.0

An authorization framework that lets an application obtain scoped, delegated access to an API on a user's behalf without handling their credentials.

AdvancedUpdated 2026-09-01

Overview

OAuth 2.0 is about authorization, not authentication. It defines how a client obtains an access token from an authorization server and presents it to a resource server, with scopes describing what the token may do.

Confusing OAuth with authentication is a classic and consequential mistake. To authenticate a user, use OpenID Connect, which is defined on top of OAuth and issues an ID token specifically for that purpose.

How it works

  1. 01Grant types: authorization code with PKCE for user facing apps, client credentials for service to service, and device code for input constrained devices. Implicit and password grants are deprecated.
  2. 02Scopes and, in enterprise directories, application roles or app permissions determine what the token can access. Delegated permissions act as the user; application permissions act as the app itself.
  3. 03Refresh tokens allow long lived access without re prompting, so their storage and revocation are security critical.

Sequence

Authorization code flow with PKCE
  1. 1Client redirects user to authorization endpoint with a code challenge
  2. 2User authenticates and consents
  3. 3Authorization code returned to the redirect URI
  4. 4Client exchanges code and verifier at the token endpoint
  5. 5Access token (and optional refresh token) issued
  6. 6Client calls the API with the bearer token

Security considerations

  • Always use PKCE and exact match redirect URIs; never accept wildcards.
  • Prefer short lived access tokens with refresh token rotation and reuse detection.
  • Govern consent: review third party applications holding broad application permissions such as mail or files read all, which are a favoured persistence mechanism.
  • Validate token signature, issuer, audience and expiry on every request at the resource server.

Common misconfigurations

  • Tokens stored in browser local storage and exposed to cross site scripting.
  • Over broad scopes requested because they were convenient during development.
  • Client secrets embedded in mobile or single page applications.

Primary sources