All field notes
Webhook guide 3 min read

OAuth Callback URL Tester for Code and State

Inspect a synthetic OAuth authorization callback, verify exact state round trips and query decoding, and debug redirect configuration without exposing a real code.

Published August 3, 2026Facts verified August 3, 2026By Webhook Tester
OAuth callback URL testertest OAuth redirect URIOAuth code state callback testOAuth 2.0 callback inspectordebug redirect_uri mismatch

Interactive example

OAuth authorization response lab

The browser performs a GET navigation. OAuth parameters are in the query string, not a JSON webhook body.

GETCaptured request
Accept
text/html,application/xhtml+xml
Sec-Fetch-Mode
navigate
Sec-Fetch-Site
cross-site
?code=synthetic_code_7f3c2a&state=state_test_82fd

Decoded query:
code  synthetic_code_7f3c2a
state state_test_82fd

Configured response

200 OK

Content-Type: text/plain; charset=utf-8

Synthetic OAuth callback received. No code was exchanged.

Synthetic data only. Never paste production tokens, signing secrets, personal data, or payment information into a public test endpoint.

One-click test setup

Creates a temporary bucket and applies this guide's expected response. You can inspect and delete it from the dashboard.

01

Use Only Synthetic Authorization Data

An OAuth callback is an HTTP redirect, not an ordinary server-to-server webhook. The browser carries an authorization result to the registered redirect URI. A real authorization code can be exchanged for tokens, so never send one to a public inspector.

This lab uses a made-up code, state value, and denial error. It is appropriate for testing query decoding, route handling, and UI behavior. Test the real code exchange only in a private callback service that protects client credentials and PKCE material.

02

Register the Exact Redirect URI

Copy the complete generated endpoint into a sandbox client registration. RFC 9700 requires exact string comparison for registered redirect URIs, with a narrow exception for localhost port numbers in native apps. Small differences are meaningful.

Compare the HTTPS scheme, hostname, full path, query component, encoding, and trailing slash. Do not build an open redirector that accepts an arbitrary next URL after the callback; current security guidance explicitly prohibits that pattern.

  • Register the exact generated HTTPS URL in the sandbox
  • Do not normalize away a path or trailing-slash difference during diagnosis
  • Reject callbacks on unregistered hosts or paths
  • Never forward to a caller-controlled destination parameter
03

Validate State Before Exchanging the Code

RFC 6749 requires the authorization server to return the exact state value when the client supplied one. Store a one-time unpredictable value before redirecting, bind it to the browser session, and compare it before any code exchange.

PKCE protects the authorization code with a verifier and is required for public clients under current best practice. Use the S256 challenge method. State, PKCE, and issuer checks address different attack paths; follow the authorization server’s current integration guidance rather than treating one string as universal protection.

04

Handle Success and Error Queries

On success, read code and state from the query component. RFC 6749 recommends a maximum authorization-code lifetime of ten minutes and requires codes to be single-use. Exchange promptly in a protected backend, then clear transient state.

On denial or another authorization error, read error, optional error_description, and state. Display a safe user-facing message and avoid putting raw provider text or query values into HTML without escaping.

05

Finish with a Private Callback Receiver

The one-click endpoint returns a no-store text response and does not exchange anything. Once query parsing is correct, move the exact route contract into your application, configure PKCE and state storage, and register the production URL separately.

Delete the temporary bucket after the sandbox exercise. Check logs and analytics for accidental full callback URLs because query strings can contain codes and error details that should not survive beyond the short authorization transaction.

  • Keep callback query strings out of long-lived access logs when possible
  • Exchange authorization codes only from a trusted component
  • Invalidate state after one callback attempt
  • Show a generic error while retaining a safe correlation identifier

Common questions

Frequently asked questions

Can I use this URL as a real OAuth redirect URI?
Use it only with a sandbox and synthetic authorization data. A real authorization code is short-lived, single-use, and sensitive. Production callbacks belong on a receiver you control.
What should an OAuth callback contain?
For the authorization code flow, a successful response contains code and repeats the exact state value when state was sent. Error responses contain error and can include error_description and state.
Why does my provider report redirect_uri mismatch?
Modern OAuth security guidance requires exact string matching for registered redirect URIs, except variable localhost ports for native apps. Compare scheme, host, port, path, query, casing, and trailing slash.

Primary sources

Official references

Try it with a real request

Turn the guide into a test.

Open a temporary endpoint, send your payload, and inspect exactly what arrived.

Open the tester