OAuth Debugger

Inspect, debug and build OAuth 2.0 / OIDC flows entirely in your browser. Decode JWT tokens (ID token, access token), generate PKCE code verifier + challenge, and construct authorization URLs with all standard parameters.

JWT Decoder (RFC 7519)

Decode JSON Web Tokens – inspect header, payload and signature details. Supports HS256/RS256/ES256 (signature not verified locally).

? Sample JWT (HS256) ? OIDC Sample (RS256) ? ID Token with claims

PKCE Generator (RFC 7636)

Generate cryptographically strong code verifier and S256 code challenge for OAuth 2.0 authorization code flow with PKCE.

Challenge method = S256 (recommended). Use this as code_challenge in authorization request.
PKCE prevents authorization code interception attacks, mandatory for public clients (SPA, mobile).

Authorization URL Builder

Construct a complete OAuth 2.0 / OIDC authorization endpoint URL with parameters.

Quick presets: Google Auth0 Okta
Zero data exposure: All cryptographic operations (PKCE, JWT decoding) run inside your browser. No tokens or secrets are sent to any server. Complete privacy for OAuth debugging.

Understanding OAuth 2.0 & OpenID Connect

OAuth 2.0 is the industry-standard protocol for authorization, enabling third-party applications to obtain limited access to HTTP services. OpenID Connect (OIDC) extends OAuth 2.0 with authentication, providing ID tokens in JWT format. This debugger helps developers inspect tokens, simulate PKCE protection, and craft correct authorization requests.

Key standards: RFC 6749 (OAuth 2.0), RFC 7636 (PKCE), OpenID Connect Core 1.0, RFC 7519 (JWT).

Security Best Practices for OAuth 2.0 & OIDC

  • Always validate JWT signatures – On the resource server or relying party, obtain the issuer's public keys (via JWKS URI) and verify the token signature. This tool does not perform signature validation; it's meant for inspecting claims only.
  • Use PKCE for all public clients – Native apps, SPAs, and mobile apps must use PKCE (RFC 7636). The code challenge and verifier ensure that the authorization code cannot be exchanged without the original client.
  • Include nonce in OIDC requests – For ID tokens, a nonce parameter binds the token to the initial authentication request and prevents replay attacks.
  • Avoid the implicit flow – Implicit flow (response_type=token) is deprecated in OAuth 2.1 due to token leakage via browser history and redirects. Prefer authorization code flow with PKCE.
  • Validate redirect URIs strictly – Always register exact redirect URIs with your OAuth provider to prevent open redirectors.

These best practices align with the OAuth 2.0 Security Best Current Practice and the upcoming OAuth 2.1 specification.

Real-world debugging scenario: PKCE mismatch during OAuth flow

A developer integrating with a provider kept receiving "invalid_grant" when exchanging the authorization code. Using this tool, they generated a fresh PKCE pair, inserted the code_challenge into the authorization URL, and after receiving the code, they used the same code_verifier (generated here) in the token request. The mismatch was caused by accidentally using different verifiers. This debugger helped isolate the issue by ensuring consistent generation and easy copying of both values.

Another common issue: malformed redirect URI causing "invalid_request". The Authorization URL Builder lets you quickly adjust parameters and see the exact URL sent to the provider, eliminating manual concatenation errors.

Maintained by the GetZenQuery Tech Team – Our team consists of experienced developers and security practitioners who follow IETF standards and OAuth security best practices. This tool is open-source (available on GitHub), and we encourage community code reviews. Last updated: March 2026. We track changes in OAuth 2.1 and OpenID Connect specifications to keep the tool aligned with emerging standards.

Why PKCE matters

Proof Key for Code Exchange (PKCE) mitigates authorization code interception attacks, especially for public clients like single-page apps and mobile apps. The tool generates a high-entropy verifier and its SHA-256 challenge. The verifier is sent during the token exchange, ensuring that only the legitimate client can redeem the authorization code.

Step-by-step OAuth flow testing with this toolkit

  1. Use the JWT decoder to verify structure of access tokens or ID tokens returned from your OAuth provider.
  2. Generate PKCE verifier + challenge to include in your authorization request (public clients).
  3. Build a complete authorization URL, copy and open in browser, simulate the grant.
  4. After redirection, exchange code for tokens (manually via your backend) — but you can decode tokens instantly with our JWT tool.

Common pitfalls & security tips

  • Always validate JWT signature: Though this tool does not verify signatures for security (requires secret/key), always perform signature validation on the resource server or using trusted libraries.
  • Use state parameter: Prevent CSRF attacks by including a unique, non-guessable state value. Our builder supports state.
  • PKCE is mandatory for native/SPA: Even if your provider does not enforce it, enabling PKCE adds critical security layer.
  • Scope design: Request only minimal scopes (least privilege). Our default scopes follow OIDC best practices.

Authoritative references & advanced insights

This toolkit is built according to IETF specifications and curated by the GetZenQuery Tech team. The PKCE generator uses Crypto.getRandomValues() for entropy and SHA-256 via Web Crypto API, aligning with NIST recommendations. JWT decoding strictly follows base64url decoding without eval, ensuring safe client-side handling. For production-level security, always rely on certified libraries (e.g., oauth2-client, Auth.js).

For further reading: OAuth 2.0 Security Best Current Practice, JWT Best Current Practices.

Frequently Asked Questions (OAuth Debugger)

Yes, any JWT (JWS) with header and payload in Base64URL format will be decoded. Signature is displayed but not verified — verification requires shared secret or public key.

Absolutely. It uses window.crypto.getRandomValues (CSPRNG) to generate a 64-byte random value, then base64url encodes it to create a verifier compliant with RFC 7636. Challenge is derived via SHA-256, also using Web Crypto API.

Primarily Authorization Code flow (response_type=code), with optional PKCE code_challenge. You can also use id_token or hybrid flows by customizing response type. Implicit flow is discouraged; our builder supports it but we highlight security concerns.

No, the tool never asks for client secret. Authorization URL only requires client_id. For token endpoint, secrets should never be used client-side; this tool is designed for public clients and debugging.

Yes, the Authorization URL builder can construct requests for any OIDC compliant provider. For discovery, you can fetch well-known endpoints separately, but this tool focuses on request building and token inspection.

The tool is maintained by GetZenQuery and updated periodically to reflect changes in OAuth/OIDC standards and browser APIs.
Compliant with RFC 6749, RFC 7636, OpenID Connect Core 1.0. Updated March 2026. Implemented by GetZenQuery Tech team.