Skip to content
SDETRole
SDETRole

Glossary · API testing

OAuth 2.0

Also called: OAuth, OAuth2, OAuth 2, client credentials grant

Definition

An authorization framework that lets an application get a limited access token to call an API on a user's or its own behalf, without handling passwords.

OAuth 2.0 is a framework for delegated authorization. Instead of giving an app your password, you approve a request at an authorization server, which issues the app an access token limited by scope (for example, orders:read) and by time. The app sends that token to the API, usually as Authorization: Bearer <token>. The four roles are the resource owner (the user), the client (the app), the authorization server (issues tokens) and the resource server (the API).

Authentication versus authorization

Authentication answers “who are you?”. Authorization answers “what are you allowed to do?”. OAuth 2.0 on its own is about authorization: an access token says what the bearer may access, not reliably who the user is. Logging users in is the job of OpenID Connect, a layer on top of OAuth 2.0 that adds an ID token (a JWT) describing the user. “Sign in with…” buttons use OpenID Connect.

Common grant types

  • Authorization code with PKCE: for apps acting on behalf of a user, including browser and mobile apps. The user signs in at the authorization server, the app receives a short-lived code, and exchanges it for tokens.
  • Client credentials: for service-to-service calls with no user. This is the flow API test suites use most.
  • Refresh token: exchanges a long-lived refresh token for a new access token.

The implicit and resource owner password grants are discouraged by current OAuth security guidance and dropped in the OAuth 2.1 draft.

Example: client credentials

curl -X POST https://auth.example.com/oauth/token \
  -d grant_type=client_credentials \
  -d client_id="$CLIENT_ID" \
  -d client_secret="$CLIENT_SECRET" \
  -d scope=orders:read

The response contains an access_token, a token_type of Bearer and an expires_in in seconds. Fetch the token once in a fixture, cache it until it nears expiry, and keep client secrets in CI secrets rather than in the repository.

What to test

  • A missing, expired or malformed token returns 401.
  • A valid token without the required scope returns 403.
  • Tokens issued for a different audience or client are rejected.
  • In the authorization code flow, the state parameter is checked and the redirect URI must match a registered value exactly.
  • Token responses and redirects never expose tokens in logs or URLs.

Type to search across SDETRole.

Full-text search by Pagefind · runs in your browser Open search page →