OAuth 2.0 in Depth: Flows, Tokens, and Security

OAuth 2.0 delegation: authorization without sharing the user's password

Central principle

The client is granted limited authority to access an API; User authentication and API authorization remain separate decisions.

In-depth edition - study material and professional reference

radio_button_unchecked Chapter presentation

Previous chapters separated identity, authentication, authorization, and static credentials. Now the course delves into the OAuth 2.0 framework, created to allow a client to obtain limited authority to access a protected resource. The central idea is to replace the direct sharing of credentials with temporary artifacts, with controlled audience, scope , duration and context.

OAuth 2.0 is not a single, closed protocol. It is a family of roles, endpoints, grants, client types, token formats, and extensions. The security of a deployment depends on the correct composition of these elements. An Authorization Code flow can be robust when it uses PKCE , strict redirect URI, and state protection, but it can be vulnerable when it accepts broad redirects, mixes issuers, or exposes codes and tokens in logs.

The original specification remains important, but modern practice is also guided by later documents. Security Best Current Practice consolidates operational experiences, advises against insecure modes and reinforces PKCE , exact URI redirect, mix-up protection, refresh token restriction and replay defense. Extensions such as PAR , JAR , RAR, mTLS, DPoP , resource metadata and token exchange address higher risk scenarios and corporate integrations.

This chapter goes through the complete cycle: client registration, authorization request, token issuance and use, renewal, revocation, introspection , delegation between services and enforcement in API Gateway. The goal is to allow the reader to design and diagnose real flows without confusing user authentication, client authentication, consent, resource authorization, and token validation.

Specification status

OAuth 2.1 remains an Internet-Draft in 2026. It consolidates modern practices, but does not automatically replace published RFCs. For regulatory decisions, use current RFCs and OAuth 2.0 Security Best Current Practice, checking the current draft version for additional guidance only.

Learning Objectives

• Explain the delegation problem solved by OAuth 2.0 and its limits.
• Distinguish resource owner , client , authorization server and resource server .
• Differentiate authorization endpoint, token endpoint, introspection , revocation and metadata.
• Sort public and confidential clients and choose authentication compatible with their ability to protect keys.
• Describe Authorization Code with PKCE and the state , nonce, issuer and redirect URI controls.
• Apply Client Credentials , Device Authorization Grant and refresh tokens in appropriate scenarios.
• Distinguish grants, codes, access tokens, refresh tokens and ID tokens.
• Design scopes, audiences, resource indicators, consent and detailed authorization.
• Understand opaque tokens, JWTs, introspection , revocation, and access token profiles.
• Apply PAR , JAR , JARM , RAR, mTLS, DPoP and token exchange according to risk.
• Integrate OAuth with API Gateways, Axway API Gateway and Azure API Management.
• Diagnose invalid_request, invalid_client, invalid_grant, invalid_token and insufficient_scope.

Chapter structure

• 16.1 The problem that OAuth 2.0 solves
• 16.2 Roles and trust boundaries
• 16.3 Endpoints, metadata and channels
• 16.4 Registration, client types and redirect URIs
• 16.5 Grants, flows and token types
• 16.6 Authorization Code in depth
• 16.7 PKCE and interception protection
• 16.8 State , nonce, issuer and mix-up protection
• 16.9 Confidential client authentication
• 16.10 Web applications, SPAs, native apps, and BFF
• 16.11 Client Credentials
• 16.12 Device Authorization Grant
• 16.13 Refresh tokens, rotation and reuse
• 16.14 Access tokens, scopes, audience and resource indicators
• 16.15 Opaque tokens, introspection and revocation
• 16.16 JWT access tokens and validation
• 16.17 Consent, least privilege and Rich Authorization Requests
• 16.18 PAR , JAR and JARM
• 16.19 Sender-constrained tokens with mTLS and DPoP
• 16.20 Token Exchange and on-behalf-of
• 16.21 Metadata of the authorization server and protected resource
• 16.22 OAuth on API Gateways, Axway and Azure
• 16.23 Threats and hardening
• 16.24 Evidence-driven troubleshooting
• 16.25 Case studies and labs
• Summary, checklist, exercises, glossary and references

radio_button_unchecked 16.1 The problem that OAuth 2.0 solves

Before delegation frameworks, it was common for an application to ask for a user's password to access another system. This practice gave the client excessive power, prevented limiting operations, made selective revocation difficult and exposed reusable credentials. If the client were compromised, the attacker could act as the user on any interface that accepted the same password.

OAuth replaces this sharing with a grant of authority. The client requests authorization for a purpose; The authorization server authenticates the user when necessary, applies policies and issues an access token destined for the resource server . The client receives only the capability represented by the token, not the user's primary credential.

The framework does not alone define how the user authenticates, how the API models object permissions or how the token must be formatted. It also does not transform an access token into proof of login for the client . OpenID Connect meets the need to communicate user authentication to the client , while the API remains responsible for fine-grained authorization and business rules.

Mental model

OAuth answers: “how does a client obtain and present limited authority for a resource?” It does not answer itself: “who is the user for the interface?”, “does the user own this object?” or “is this transaction allowed by the domain?”.

radio_button_unchecked 16.2 Roles and trust boundaries

The resource owner is the entity capable of granting access to the resource. In many flows it is a person, but it can also be an organization or administrative policy. The client is the application that requests access. He does not automatically own the data and should not be given more authority than is necessary for his role.

The authorization server authenticates the resource owner when applicable, evaluates the request, records consent or policy, and issues tokens. The resource server is the API that accepts access tokens and decides whether the operation is allowed. On an enterprise platform, the API Gateway can act as part of the resource server by validating the token and applying cross-cutting controls, while the backend retains domain decisions.

Logical roles do not necessarily equate to separate processes. The same product can host authorization and resources, and a gateway can intermediate multiple APIs. Even so, issuer, audience, keys, endpoints and responsibilities must be distinct to prevent a token issued for one service from being improperly accepted by another.

radio_button_unchecked 16.3 Endpoints, metadata and channels

The authorization endpoint receives requests through the user agent and conducts interaction with the resource owner . The token endpoint is accessed directly by the client to exchange grants for tokens. This separation creates two channels: front-channel, exposed to browser, history, extensions and redirects; and back-channel, protected by TLS and used for direct requests between client and authorization server .

Optional endpoints expand operation and interoperability. Introspection allows the resource server to query the state of a token. Revocation allows you to invalidate refresh tokens and, depending on the implementation, access tokens. PAR receives authorization parameters in advance via back-channel. Metadata describes issuer, endpoints, authentication methods, algorithms and supported capabilities.

Endpoint URLs are security data. The client must not construct them by concatenation or accept metadata from an untrusted source. The returned issuer must match the configured issuer. TLS, hostname validation, and reliable DNS resolution remain essential because OAuth protects authority, not replaces channel security.

radio_button_unchecked 16.4 Registration, client types and redirect URIs

The registry associates client_id, redirect URIs, application type, contacts, keys, authentication methods and allowed grants. The client_id is a public identifier, not a secret. Security depends on the correct link between the identifier and registered properties, especially redirect URIs and cryptographic material.

Sensitive clients can keep credentials under control, such as backend web applications or services. Public clients run in environments where the user or attacker can extract the software and its values, such as SPAs and native applications. Inserting client_secret into a JavaScript, mobile package, or distributed application does not make the confidential client ; the secret becomes copiable.

Redirect URI must be compared by exact match, except for very specific rules for native application loopback. Wildcards, prefix matching and open redirectors allow bypassing codes. Each environment must have its own URIs, and the application must validate the return route before starting any local session.

Public client secrecy

A value embedded in a SPA, mobile application, or distributed binary must be considered public. Adequate protection comes from PKCE , strict redirect URI, operating system, BFF when applicable, and token restriction - not from trying to hide a client_secret.

radio_button_unchecked 16.5 Grants, flows and token types

Grant is the representation of an authorization used by the client to obtain an access token . Authorization Code , refresh token , client credentials and device code are examples. “Flow” describes the complete sequence of interactions. Confusing grant with token leads to inaccurate logs and policies: the authorization code is short, single-use and intended for the token endpoint; the access token is presented to the API.

The access token represents authority for a resource server . The refresh token allows you to request new access tokens and must be restricted to the authorization server . The ID token belongs to OpenID Connect and communicates facts about authentication to the client ; should not be used as an access token . Each artifact has a different recipient, useful life and protection.

Old Implicit Grant and Resource Owner Password Credentials should not be chosen for new projects. The first exposes tokens on the front-channel and has lost its justification with PKCE ; the second delivers user credentials to the client and prevents many modern controls. Migrations should prioritize Authorization Code with PKCE or appropriate machine-to-machine flows.

radio_button_unchecked 16.6 Authorization Code in depth

The client creates an authorization request containing response_type=code, client_id, redirect_uri, scope , state and PKCE parameters. The browser is redirected to the authorization server , where the user can be authenticated and the policy evaluated. If successful, the authorization server returns an authorization code for the registered redirect URI.

The client receives the code and exchanges it in the token endpoint. This direct request includes grant_type=authorization_code, code, redirect_uri, and code_verifier. Confidential clients also authenticate themselves. The server checks one-time usage, term, client , redirect URI and PKCE before issuing tokens.

The code must not carry reusable authority or be sent to APIs. It exists to reduce token exposure in the front-channel and allow validations in the back-channel. Logs, analytics tools, error pages and referrers should not record the value. After the switch, the application must remove sensitive parameters from the URL and establish its own session state in a secure way.

Authorization request - illustrative values

GET /authorize?response_type=code
  &client_id=payments-portal
  &redirect_uri=https%3A%2F%2Fapp.example%2Fcallback
  &scope=payments.read%20payments.write
  &state=valor-aleatorio
  &code_challenge=base64url-sha256-verifier
  &code_challenge_method=S256

Exchange of code for tokens

POST /token
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&code=AUTHORIZATION_CODE
&redirect_uri=https%3A%2F%2Fapp.example%2Fcallback
&client_id=payments-portal
&code_verifier=INSTANCE_RANDOM_SECRET

radio_button_unchecked 16.7 PKCE and interception protection

PKCE starts with a random, high-entropy, and trial-unique code_verifier. The client calculates code_challenge = BASE64URL(SHA256(code_verifier)) and sends the challenge to the authorization endpoint. When changing the code, it displays the original verifier. The authorization server recalculates the challenge and requires matching.

If an attacker intercepts the authorization code , he will not be able to exchange it without the verifier. Method S256 must be used; plain exists for restricted compatibility and does not offer the same protection against observation as challenge. PKCE does not replace state , exact redirect URI, TLS, or confidential client authentication. It solves a specific threat: authorization code interception and injection.

PKCE must also be required for confidential clients when using Authorization Code . In addition to standardizing the flow, it protects against attacks in which code obtained in another context is injected into the client session. The verifier must not be reused and must be associated with the same transaction that contains state and redirect URI.

radio_button_unchecked 16.8 State , nonce, issuer and mix-up protection

State ties the authorization response to the session that initiated the request and helps prevent CSRF. It must be unpredictable, single-use and locally associated with the issuer, redirect URI, PKCE and user intent. Treating state only as a signed return URL may leave the session without adequate protection against unsolicited responses.

Nonce belongs to OpenID Connect and links the ID token to the authentication request. It does not replace state in securing the OAuth flow. On clients using OIDC, both may be required: state protects the redirect and nonce is validated within the ID token.

Authorization server mix-up attacks exploit clients that talk to multiple issuers and do not link the response to the correct issuer. The client must use trusted metadata, validate the iss parameter when supported, and send the code only to the issuer token endpoint associated with the transaction. Never select the token endpoint based on unvalidated response data.

Minimum transactional state

Store, tentatively: expected issuer, client_id, redirect URI, state , code_verifier, nonce when there is OIDC, requested scopes and time. Consume the record once and expire quickly.

radio_button_unchecked 16.9 Confidential client authentication

The token endpoint needs to distinguish the client presenting the grant . client_secret_basic is simple, but relies on symmetric secret and secure transport. client_secret_post puts the secret in the body and increases log risk; should be avoided when the Basic method is supported. Secrets need vault storage, rotation, ownership, and scope per environment.

private_key_jwt uses a JWT assertion signed by the client 's private key. The authorization server validates issuer/subject, audience, expiration, unique identifier and signature. The private key is not sent, and rotation can be managed by JWKS. The mechanism requires jti replay prevention and strict audience validation of the token endpoint.

mTLS client authentication links authentication to the certificate presented in the TLS connection. Can use traditional PKI or registered certificate. In environments with proxies, it must be clear where TLS ends and how the identity of the certificate is preserved. Strong client authentication does not eliminate the need for PKCE in the Authorization Code .

radio_button_unchecked 16.10 Web applications, SPAs, native apps, and BFF

Traditional web applications maintain code and credentials on the server. The browser only receives a protected session cookie, while the backend runs Authorization Code , stores tokens and calls APIs. This separation reduces exposure of tokens to JavaScript, but requires protection against CSRF, fixation, XSS and session theft.

SPAs are public clients. Authorization Code with PKCE is the modern flow, but access tokens stored in the browser are still exposed to XSS and extensions. A Backend for Frontend can receive the code, maintain tokens on the server and expose only HttpOnly, Secure and SameSite cookies to the browser. BFF adds state and infrastructure but reduces the token footprint.

Native applications use external browsers and redirect URIs based on app links, universal links, custom schemes or loopback. Embedded webviews degrade security and SSO experience. The system must prevent another application from capturing the redirect URI and always combine the return mechanism with PKCE .

radio_button_unchecked 16.11 Client Credentials

Client Credentials are used when the client acts on its own behalf, without a human resource owner in the transaction. The client authenticates to the token endpoint and receives an access token associated with the application identity. It is suitable for services, jobs and automations that have their own permissions.

Grant should not be used to simulate users or transport arbitrary user_id. Authorization must be based on the application principal, its tenant, owner, and application permissions. If one service needs to preserve user context when calling another, on-behalf-of or token exchange is more suitable.

Because the token can open broad access, static credentials should be replaced with private_key_jwt, mTLS, managed identity, or workload federation when possible. Application scopes need to be separated from delegated scopes to prevent an app-only token from being confused with user authority.

Client Credentials - conceptual example

POST /token
Authorization: Basic base64(client_id:client_secret)
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
&scope=settlements.process

Review question

If the operation needs to know “which user authorized?”, Client Credentials alone do not provide that answer. The main thing is the application.

radio_button_unchecked 16.12 Device Authorization Grant

The Device Authorization Grant supports devices with limited input or without a convenient browser. The client requests device_code and user_code, presents the user with a verification_uri, and starts polling the token endpoint. The user completes authentication and authorization on another browser-capable device.

The client must respect interval, expires_in and errors such as authorization_pending and slow_down. Aggressive polling creates load and can cause blocking. The user_code needs to be short enough to type, but protected by rate limiting, expiration, and binding to high-entropy device_code .

The flow should not be used as a shortcut for applications that already have a suitable browser. The interface must clearly show which device and operation is being authorized, reducing phishing attacks in which a code sent by a third party is entered by the victim.

radio_button_unchecked 16.13 Refresh tokens, rotation and reuse

Refresh token is a high-value credential because it allows you to obtain new access tokens without repeating the entire interaction. It should only be sent to the token endpoint, protected in suitable storage and limited to the client and the original authorization. Short access tokens reduce exposure; refresh tokens maintain controlled continuity.

For public customers, BCP recommends sender-constrained or rotated refresh tokens. In rotation, each use produces a new refresh token and invalidates the previous one. If an old token reappears, the server detects possible theft and revokes the corresponding family or authorization. The implementation needs to handle concurrency and missed responses without creating false positives.

Absolute expiration, expiration due to inactivity, revocation due to logout, password change, withdrawal of consent and risk must be defined. “ Refresh token never expires” transfers all control to perfect revocation, something difficult in distributed systems. The client should treat invalid_grant as a need for reauthorization, not as a reason to repeat indefinitely.

radio_button_unchecked 16.14 Access tokens, scopes, audience and resource indicators

Access token must only be accepted by the resource server for which it was issued. Wide audience turns a token into a reusable pass between APIs. Resource Indicators allow the client to declare the intended resource during authorization or token request, helping the authorization server to issue specific tokens.

Scope represents authority requested and granted, but its semantics must be documented. Scopes like read and write are simple, but can be ambiguous on large platforms. Domain, operation and resource names help: payments.read, payments.create and conciliacao.execute. Scope does not replace object, tenant, or domain state authorization.

The resource server validates the audience, scope and context of the request. An API should not accept a token because it contains “admin” without checking the issuer, type and origin of the claim. Authorization claims need to have governance: who issues them, when they change, how they are revoked, and which service has the authority to interpret them.

Resource Indicator - conceptual example

GET /authorize?response_type=code
  &client_id=app
  &resource=https%3A%2F%2Fapi.payments.example
  &scope=payments.read

radio_button_unchecked 16.15 Opaque tokens, introspection and revocation

Opaque token does not reveal structure to the client or resource server . The API queries the authorization server by introspection or uses distributed local state . This approach facilitates immediate revocation and minimizes claim exposure, but creates dependencies on availability, latency, API authentication and caching policy.

Introspection returns active and authorized attributes for the requester. active=false should be normal response for invalid, expired, revoked or unknown token, without revealing details. The endpoint needs to authenticate resource servers and limit what data each one can query. Cache reduces load, but increases the window between revocation and enforcement.

Revocation allows the client to request invalidation. The successful response should not reveal whether the token existed. Revoking refresh token normally terminates the ability to renew; Access tokens already issued can continue until they expire if they are self-contained. High-risk architectures combine short TTL, introspection , revocation or denylist events.

Introspection - simplified example

POST /introspect
Authorization: Basic <resource-server-credential>
Content-Type: application/x-www-form-urlencoded
token=OPAQUE_TOKEN
HTTP/1.1 200 OK
{
  "active": true,
  "client_id": "portal",
  "scope": "payments.read",
  "exp": 1770000000
}

radio_button_unchecked 16.16 JWT access tokens and validation

JWT allows the resource server to locally validate signatures and claims, reducing calls to the authorization server . The JWT access token profile standardizes claims and useful types, but the API still needs to know issuer, audience, algorithms and trusted keys. Decoding Base64URL is not validating.

Validation must fix allowed algorithms, locate the key by the kid in trusted JWKS, check signature, issuer, audience, expiration, not-before when present and expected type. The resource server must reject tokens issued for other use, even if the same key signs ID tokens. typ and profile rules help prevent confusion between JWT types.

Key rotation requires caching and controlled updating. When unknown kid appears, the gateway can update JWKS, but must not allow the token to point to an arbitrary key URL. Temporary metadata failure should not immediately invalidate all still trusted keys; at the same time, excessive caches delay compromised key removal.

Unencrypted content

A signed JWT typically protects integrity, not confidentiality. Avoid unnecessary PII and data. The token passes through clients, proxies, gateways, tools and logs; treat it as sensitive credential.

radio_button_unchecked 16.17 Consent, least privilege and Rich Authorization Requests

Consent is a decision interface, not a substitute for policy. In corporate environments, some permissions are approved by administrators or contracts, while others depend on the user. The screen must identify customer, data, actions, duration and consequences, avoiding incomprehensible technical scopes.

Least privilege starts with the definition of scopes and continues on the resource server . Requesting all scopes “to avoid new consent” increases the impact of leaks. Incremental authorization allows you to request additional authority only when the functionality is used. The authorization server can grant subset and the client needs to verify the response.

Rich Authorization Requests represent structured details such as amount, currency, account, and transaction type. This allows for more precise authorizations than scope strings, especially on payments and financial data. The authorization object must be validated, signed or protected according to the adopted profile and must not be accepted as free data sent by the client to the API.

Rich Authorization Request - teaching example

{
  "authorization_details": [{
    "type": "payment_initiation",
    "instructedAmount": {"currency": "BRL", "amount": "150.00"},
    "creditorAccount": {"iban": "EXAMPLE"}
  }]
}

radio_button_unchecked 16.18 PAR , JAR and JARM

Pushed Authorization Requests allow the client to send parameters to the authorization server via back-channel and receive short-lived request_uri. The browser only carries the reference. This reduces manipulation, exposure, and URL length, and allows for client authentication prior to user interaction.

JWT-Secured Authorization Request represents the request in a signed and, optionally, encrypted JWT. The authorization server validates the integrity and origin of the parameters. PAR and JAR can be combined: the client sends a signed request object to the PAR endpoint and uses the request_uri in the authorization endpoint.

JARM secures the authorization response in a signed or encrypted JWT. Instead of relying solely on loose parameters in the redirect, the client validates issuer, audience, signature and time. These mechanisms increase complexity and key management, which is why they are more common in financial profiles, regulated ecosystems and high-risk integrations.

radio_button_unchecked 16.19 Sender-constrained tokens with mTLS and DPoP

Bearer token works like bearer money: whoever obtains the value can present it. Sender-constrained token binds the access token to a client key. The resource server requires, in addition to the token, corresponding proof of ownership. The goal is to reduce replay after leaks in logs, proxies, memory or side channels.

With mTLS, the authorization server associates the token with the client 's certificate and the resource server verifies the certificate presented in the connection. The claim cnf can load thumbprint. The architecture needs to ensure that the API observes the correct TLS identity even when there are load balancers or gateways terminating connections.

DPoP uses a proof JWT signed by the client in each request, containing HTTP method, URI, time, unique identifier and link to the access token . The API validates signature, htm, htu, iat, jti, key and ath. DPoP is application layer protection and does not replace TLS. Server nonce and jti cache can strengthen replay defense according to risk.

radio_button_unchecked 16.20 Token Exchange and on-behalf-of

In service architectures, the first backend may need to call another while retaining some of the original authority. Forwarding the same access token to all services broadens audiences and exposes the credential. Token Exchange allows you to exchange a subject token for another token appropriate to the next resource.

The new token can represent the user, the actor service, or both. Actor claims help record the chain. The policy should limit which clients can exchange tokens, which audiences can be solicited, and which scopes can be preserved. The exchange must not elevate privilege beyond the entry token and the actor's authority.

On-behalf-of is an implementation of delegation where a service acts on behalf of the user. Logs need to preserve user, initial client , intermediate service and effective authorization. If a call passes through several trust domains, each issue must be treated as a new decision, not as a simple copy of headers.

radio_button_unchecked 16.21 Metadata of the authorization server and protected resource

Authorization Server Metadata publishes issuer, endpoints, authentication methods, grants, scopes and algorithms. Clients must obtain the source document configured and validate consistency between issuer and URL. Metadata simplifies rotation and interoperability, but it should not turn discovery into automatic trust.

Protected Resource Metadata allows an API to publish resource identifiers, related authorization servers, scopes, and supported presentation methods. This helps clients and authorization servers understand how to obtain tokens for a resource and improves WWW-Authenticate challenges.

Metadata must be versioned and monitored as part of the platform. Changes to endpoint, algorithm or issuer can break all clients. Cache needs to respect availability without freezing configuration indefinitely. Internal, external and approval environments must have separate documents to prevent mixing of trust.

Authorization Server Metadata - illustrative excerpt

{
  "issuer": "https://id.example",
  "authorization_endpoint": "https://id.example/authorize",
  "token_endpoint": "https://id.example/token",
  "jwks_uri": "https://id.example/jwks.json",
  "code_challenge_methods_supported": ["S256"]
}

radio_button_unchecked 16.22 OAuth on API Gateways, Axway and Azure

API Gateways can validate access tokens, query introspection , require scopes, enforce quota by client_id, and propagate trusted context. Before inserting internal headers, the gateway must remove client -supplied versions. The backend must accept these headers only from an authenticated connection coming from the gateway.

In Azure API Management, validate-jwt and validate-azure-ad-token can validate tokens before the backend. Policies can require issuer, audience and claims, while authentication-managed-identity allows the gateway to obtain token for a compatible backend. Configuring the developer portal for OAuth facilitates testing, but does not replace policy enforcement.

In Axway API Gateway, OAuth filters and services can implement authorization server , token validation, client authentication, and resource server policies. The topology needs to record which component issues, which validates, where keys are stored and how revocation and rotation are handled. As versions and licenses change, validate the installed product documentation.

Azure API Management - conceptual policy

<validate-jwt header-name="Authorization"
              require-expiration-time="true"
              require-signed-tokens="true">
  <openid-config url="https://id.example/.well-known/openid-configuration" />
  <audiences><audience>api://payments</audience></audiences>
  <required-claims>
    <claim name="scp" match="any"><value>payments.read</value></claim>
  </required-claims>
</validate-jwt>

Division of responsibility

The gateway validates issuer, audience, signature, time, scopes and transversal requirements. The backend continues checking tenant, ownership, transaction status, business limits and object authorization.

radio_button_unchecked 16.23 Threats and hardening

Authorization Code interception is reduced by PKCE . CSRF and CSRF login require state and transactional binding. Mix-up requires association with the issuer. Redirect URI manipulation requires exact comparison. Token leakage requires TLS, log hygiene, correct headers, secure storage and TTL reduction. Token replay may require sender constraint.

Open redirectors on the client or authorization server increase code bypass. Referrer, history and analytics can capture front-channel parameters. Query string tokens leak easily and should not be used as a normal form of presentation. Access tokens must follow Authorization header and responses need proper Cache-Control.

Authorization servers must protect endpoints against brute force, credential stuffing, request flooding and user_code abuse. Clients need to validate all responses and not display internal details. Resource servers must limit algorithms, validate audiences and not trust claims without namespace and governance. Every implementation requires an inventory of clients, owners, grants, redirect URIs and keys.

Inadvisable practices

Do not use Implicit Grant or Resource Owner Password Credentials in new projects. Do not store client_secret in public client . Do not accept redirect URI by prefix. Do not treat ID token as access token . Don't accept JWT just because it “decoded without error”.

radio_button_unchecked 16.24 Evidence-driven troubleshooting

Diagnosis begins by identifying the endpoint and step. Error in authorization endpoint involves parameters, session, policy and redirect URI. Token endpoint error involves client authentication, code, verifier, grant and clock. API error involves presentation, validation and authorization. Mixing these steps turns invalid_grant into “Invalid JWT” or 403 into “login failure”.

Collect correlation ID, expected issuer, client_id, grant_type, normalized redirect URI, scopes, audience, kid, time and status without registering tokens or codes. Compare the clock of the components. Confirm metadata and JWKS accessed by the runtime, not just the operator's notebook. In proxy environments, record hostname, TLS, and actual destination.

For intermittency, investigate key rotation, multiple nodes with divergent caching, concurrent authorization code or refresh token reuse, load balancing without session affinity, and DNS. Reproduce with a single controlled flow and synthetic tokens. A token may work on one gateway and fail on another due to different configuration or cache.

Stable external error; Detailed cause remains in the secure log

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="payments",
  error="invalid_token"
Content-Type: application/problem+json
{
  "type": "https://errors.example/oauth/invalid-token",
  "status": 401,
  "correlationId": "corr-8f12"
}

radio_button_unchecked 16.25 Case studies

Case 1 - SPA with built-in secret

A SPA sends client_secret in the token request. The value is visible in the bundle and can be copied by any user. The fix is to register the client as public, use Authorization Code with PKCE and exact redirect URI. If the risk of tokens in the browser is high, adopt BFF and cookie protected.

The investigation also checks CORS, token storage, XSS, logout, and renewal. Just removing the secret does not resolve exposure of refresh token or access token persisted in localStorage.

Case 2 - Token accepted by wrong API

Two APIs trust the same issuer and key, but one of them does not validate audience. A token issued for reporting is accepted for payments. The fix is to require specific audience and separate scopes. In critical systems, resource indicators and resource tokens reduce the possibility of cross-reuse.

Security contract tests must send valid tokens to neighboring audiences and expect rejection. This negative check needs to exist on gateway and backend when both validate tokens.

Case 3 - Refresh token reused after timeout

The client uses a refresh token , receives timeout and repeats the call. The first processing had issued a new token; repetition looks like theft and the family is revoked. The solution combines operational idempotence, controlled tolerance window or client logic that serializes renewal and handles lost responses.

A wide tolerance weakens reuse detection. The decision must consider risk, network and ability to correlate attempts. Logs need to record family, predecessor token, client and result without storing the raw value.

Case 4 - Gateway validates, backend rejects

The gateway accepts the token for its own audience and forwards it to the backend, which expects the token intended for it. The architecture needs to choose: backend trusts the context propagated by the gateway in an authenticated channel, or gateway obtains a new token for the backend using managed identity, client credentials or token exchange .

Forwarding the original token is only correct when the backend is the resource server for that audience. The decision must be documented in the security contract and tested with multiple APIs.

radio_button_unchecked Observation labs

Lab 1 - Authorization Code with PKCE

• Use a laboratory authorization server or authorized simulator.
• Generate random verifier and S256 challenge.
• Run the correct flow and record only synthetic values.
• Repeat with wrong verifier, divergent state , reused code and changed redirect URI.
• Classify each error by step and endpoint.

Lab 2 - audience and scope validation

• Configure two APIs with different audiences.
• Issue token for API A and try to use it on API B.
• Test scope missing, expired and alternative issuer.
• Compare external response and internal reason code.

Lab 3 - introspection and cache

• Use opaque lab and introspection token endpoints.
• Measure no-cache and short-cache latency.
• Revoke the token and watch the window until rejection.
• Document the decision between availability and speed of revocation.

Lab 4 - refresh token rotation

• Obtain a synthetic refresh token .
• Renew and confirm issuance of successor.
• Reuse the predecessor and observe family policy.
• Simulate two competing renewals and analyze the result.

Lab 5 - policy at the gateway

• Configure issuer, audience and scope in lab gateway.
• Unknown kid test and JWKS update.
• Remove client -sent identity headers.
• Only propagate validated claims and compare with backend authorization.

radio_button_unchecked Chapter summary

OAuth 2.0 is a delegation framework. Resource owner , client , authorization server and resource server have different responsibilities. Authorization endpoint and token endpoint use different channels, and each artifact - code, access token , refresh token and ID token - has its own recipient and lifecycle.

Authorization Code with PKCE is the modern basis for user-based applications. PKCE protects against interception, state links the transaction, nonce belongs to the OIDC and issuer protects multi-issuer clients. Public clients do not have reliable secrets; confidential clients can use secret, private_key_jwt or mTLS.

Client Credentials represent the application, Device Authorization meets limited input and refresh tokens require rotation or sender constraints. Access tokens need a minimum audience and scope . Opaque tokens favor central control; JWTs favor local validation, but require full verification and key management.

PAR , JAR , JARM and RAR strengthen requests and responses; mTLS and DPoP reduce replay; Token Exchange controls delegation between services. API Gateways apply cross-cutting validation, while backends preserve domain authorization. Security depends on inventory, least privilege, exact redirect URI, log hygiene, observability, and negative testing.

Next step of the course

Chapter 17 will delve deeper into OpenID Connect: ID Token, UserInfo, nonce, acr, amr, federated authentication, sessions, logout, and secure application integration with identity providers.

radio_button_unchecked OAuth 2.0 Checklist

• Each client has explicitly registered owner, type, redirect URIs and grants.
• Authorization Code uses PKCE S256, including for confidential clients.
• State is random, single-use and linked to issuer, redirect URI and verifier.
• Public clients do not depend on client_secret.
• Redirect URIs use exact matching and do not contain open redirectors.
• Implicit and password grants are not used on new projects.
• Access tokens have minimal audience and scopes.
• ID token is not accepted as an access token .
• Refresh tokens have rotation, sender constraint or equivalent policy.
• JWTs validate signature, algorithm, issuer, audience, type and time.
• Introspection is authenticated and has revocation-aware caching.
• Tokens do not appear in URLs, logs, analytics or error messages.
• mTLS or DPoP is considered for high replay risk.
• Gateway and backend have explicit authorization division.
• Rotation of JWKS, certificates and client credentials is tested.
• OAuth errors are correlatable without revealing sensitive details.
• Customers, grants, consents and tokens have a termination process.

radio_button_unchecked Exercises

• Explain why OAuth 2.0 is not, on its own, a user authentication protocol.
• Differentiate authorization code , access token , refresh token and ID token.
• Describe Authorization Code checks with PKCE .
• Explain why state and PKCE are not substitutes for each other.
• Rate a SPA and justify why its client_secret is not trustworthy.
• Compare client_secret_basic, private_key_jwt and mTLS.
• Model Client Credentials for a userless job.
• Explain reuse detection in refresh token rotation.
• Compare opaque token with JWT on revocation and availability.
• List mandatory validations of a JWT access token .
• Explain audience and resource indicators on a platform with multiple APIs.
• Compare PAR , JAR and JARM .
• Differentiate between mTLS-bound token and DPoP -bound token.
• Propose Token Exchange for three services while preserving the user.
• Create a troubleshooting script for intermittent invalid_grant.

radio_button_unchecked Glossary

radio_button_unchecked Annex A - Flow choice matrix

radio_button_unchecked Technical references

• IETF. RFC 6749 - The OAuth 2.0 Authorization Framework. 2012.
• IETF. RFC 6750 - OAuth 2.0 Bearer Token Usage. 2012.
• IETF. RFC 7009 - OAuth 2.0 Token Revocation. 2013.
• IETF. RFC 7519 - JSON Web Token (JWT). 2015.
• IETF. RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients. 2015.
• IETF. RFC 7662 - OAuth 2.0 Token Introspection . 2015.
• IETF. RFC 8252 - OAuth 2.0 for Native Apps. 2017.
• IETF. RFC 8414 - OAuth 2.0 Authorization Server Metadata. 2018.
• IETF. RFC 8628 - OAuth 2.0 Device Authorization Grant . 2019.
• IETF. RFC 8693 - OAuth 2.0 Token Exchange . 2020.
• IETF. RFC 8705 - OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound access tokens. 2020.
• IETF. RFC 8725 - JSON Web Token Best Current Practices. 2020.
• IETF. RFC 9101 - JWT-Secured Authorization Request. 2021.
• IETF. RFC 9126 - Pushed Authorization Requests. 2021.
• IETF. RFC 9068 - JWT Profile for OAuth 2.0 access tokens. 2021.
• IETF. RFC 9207 - OAuth 2.0 Authorization Server Issuer Identification. 2022.
• IETF. RFC 9396 - OAuth 2.0 Rich Authorization Requests. 2023.
• IETF. RFC 9449 - OAuth 2.0 Demonstrating Proof of Possession. 2023.
• IETF. RFC 9700 - Best Current Practice for OAuth 2.0 Security. 2025.
• IETF. RFC 9701 - JWT Response for OAuth Token Introspection . 2025.
• IETF. RFC 9728 - OAuth 2.0 Protected Resource Metadata. 2025.
• IETF OAuth Working Group. The OAuth 2.1 Authorization Framework - Internet-Draft, version consulted in 2026.
• Microsoft Learn. Azure API Management authentication, validate-jwt, validate-azure-ad-token, and managed identity policies.
• Axway Documentation. OAuth 2.0 services, client authentication and token validation on API Gateway.
• OpenID Foundation. Financial-grade API Security Profile and OpenID Connect specifications, when applicable to the ecosystem.

Update note

OAuth evolves through RFCs, Best Current Practices, profiles and drafts. Before deploying a flow or policy, validate the current specification, product version documentation, and behavior in an authorized environment. Treat Internet-Drafts as work in progress, not as automatic replacements for RFCs.