b2KIT

OAuth 2.0 Flow Debugger

Debug OAuth 2.0 authorization code, implicit, and PKCE flows. Inspect tokens, scopes, and redirect parameters.

Tested tool guide Tested browser tools Checked August 16, 2026

What OAuth 2.0 Flow Debugger does and how it behaves

OAuth 2.0 Flow Debugger puts request parameters, redirect data, token material, scopes, and PKCE values for authorization code, implicit, and PKCE exchanges into one inspection view. Use it to identify an altered state value, a redirect error, an unexpected scope set, or a verifier and challenge mismatch. Because authorization responses and tokens can grant access, browser-only handling matters here; nothing is uploaded. The common mistake is treating readable token fields or a successful redirect as proof that the token is authentic and acceptable to an API. They are not.

How the result is produced

1

Redirect anatomy

The debugger treats an authorization request and its redirect as related records. It exposes callback parameters from the query string or URL fragment, including success values such as code and failure values such as error and error_description. That placement matters: authorization code responses normally use the query component, while an implicit response can place token data in the fragment, which the redirect server does not receive.

2

PKCE comparison

PKCE inspection relates the authorization request's code_challenge and code_challenge_method to the later code_verifier. For S256, the expected challenge is the unpadded base64url encoding of the SHA-256 digest of the ASCII verifier. The debugger helps reveal a changed verifier, the wrong transformation method, or a copied challenge with padding, but the authorization server remains the authority on whether an exchange succeeds.

Good uses

  • Compare an authorization URL with the returned callback when a provider reports error=invalid_request, omits the expected code, or returns state that differs from the value the client stored.
  • Investigate an authorization code exchange rejected as invalid_grant by checking the verifier used at the token step against the challenge and challenge method carried in the authorization request.
  • Inspect a legacy implicit callback to determine whether access_token, token_type, expires_in, scope, state, or error data landed after the URL fragment marker instead of in the query string.

Limits and checks

  • Displayed token text is not cryptographic validation. Inspection alone does not verify a signature, issuer, audience, revocation status, or authorization-server policy. A resource server can still reject a token that looks structurally reasonable.
  • URL fragments are available to browser code but are not included in the HTTP request sent to the redirect server. If only a server log or request target is copied into the debugger, an implicit response carried after the fragment marker will be missing.
  • Local processing reduces network exposure but does not make live credentials safe to share. Access tokens, authorization codes, refresh tokens, and PKCE verifiers can still leak through screenshots, copied diagnostic reports, browser extensions, developer tools, or application logs.

Common questions

Can the debugger prove that an access token is valid?

No. It can expose the token and related OAuth fields for inspection, but readable contents are not proof of authenticity or authorization. Definitive acceptance depends on checks performed by the relevant authorization server or resource server, which may include signature, issuer, audience, expiry, revocation, client, and scope requirements.

Why does an S256 PKCE challenge differ from the verifier?

The verifier is the original high-entropy value retained by the client. With the S256 method, the challenge is derived by hashing the verifier with SHA-256 and encoding the digest with unpadded base64url. The authorization request carries the challenge; the later token request carries the verifier so the authorization server can compare them.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools

Password Generator

Generate strong, random passwords with customizable length, character sets, and complexity requirements.

Password Strength Checker

Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.

Random String Generator

Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.

QR Code Generator

Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.

QR Code Reader

Scan and decode QR codes from uploaded images or your device camera to extract embedded data.

File Checksum Calculator

Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.