OAuth/OIDC Debugger

PKCE (Proof Key for Code Exchange) is a security extension to OAuth 2.0 that prevents authorization code interception attacks. It's required for mobile and single-page applications (SPAs) and recommended for all OAuth clients. Use the "PKCE Generator" tab to create a code verifier and code challenge. Send the challenge during authorization and the verifier during token exchange.

Go to the "Flow Tester" tab, select your OAuth flow type (Authorization Code, PKCE, etc.), fill in the required parameters (client_id, redirect_uri, scope), and click "Generate Authorization URL". Copy the URL and open it in a new tab to start the OAuth flow. The tool will help you understand each step and provide examples for token exchange.

OAuth requires exact string matching for redirect URIs. Common issues include: trailing slash differences (/callback vs /callback/), protocol mismatches (http vs https), port numbers (localhost:3000 vs localhost:8080), and query parameters. Use the "Redirect Validator" tab to compare your URIs character-by-character and see exactly what's different.

'invalid_grant' is the most common OAuth error with multiple possible causes. The top three are: (1) authorization code expired (usually >10 minutes old), (2) code was already used (codes are single-use), and (3) redirect_uri mismatch between authorization and token requests. Use the "Error Debugger" tab for detailed troubleshooting steps ranked by likelihood.

Yes - all token processing happens entirely in your browser using JavaScript. No tokens, secrets, or sensitive data are sent to any server or stored permanently. The tool uses browser sessionStorage (cleared when you close the tab) and never logs data to analytics. However, always be cautious with production secrets and use development/test tokens when possible.

JWT signature verification requires access to the secret key (for HMAC algorithms like HS256) or the public key (for asymmetric algorithms like RS256/ES256). Since this is a client-side tool and we never store, transmit, or have access to your signing keys, we cannot verify signatures. This tool is designed for inspecting and understanding JWT structure, debugging claims, and analyzing algorithms - not for production authentication. Always verify JWT signatures server-side using proper cryptographic libraries before trusting the token contents.

For server-side web apps: Authorization Code Flow (with client secret). For mobile apps and SPAs: Authorization Code Flow with PKCE. For backend service-to-service: Client Credentials Flow. Avoid legacy flows: Implicit Flow and Resource Owner Password Flow are deprecated due to security concerns. See the "Flow Tester" tab for detailed descriptions.

Go to the "PKCE Generator" tab and click "Generate New PKCE Pair". The tool creates a cryptographically random code verifier (256 bits of entropy) and computes the code challenge using SHA-256 (S256 method, recommended) or plain method. Copy the challenge for your authorization request and keep the verifier for token exchange.

Major JWT vulnerabilities include: (1) Algorithm confusion attacks - changing "alg" to "none" or switching from RS256 to HS256 to forge tokens. (2) Weak signing secrets - short or common secrets that can be brute-forced. (3) Missing signature verification - accepting tokens without validating signatures. (4) Missing expiration claims - tokens that never expire, allowing indefinite access if stolen. (5) Token storage issues - storing JWTs in localStorage where XSS attacks can steal them. (6) Accepting untrusted algorithms - not enforcing algorithm allowlists. Always use strong algorithms (RS256, ES256), verify signatures, include expiration claims, and store tokens securely.

Use JWTs when: You need stateless authentication across distributed systems, APIs, or microservices; implementing single sign-on (SSO); mobile apps need offline access; scaling horizontally without shared session storage. Use session tokens when: You need instant token revocation (logout); managing long-lived sessions; security is paramount (JWTs can't be invalidated once issued until expiration); working with traditional server-rendered apps. JWTs are self-contained and stateless (don't require server-side session storage), while session tokens require a session store but offer better revocation control.

HS256 (HMAC-SHA256) is a symmetric algorithm where the same secret key is used for both signing and verifying tokens. This means anyone who can verify tokens can also create them, making key distribution risky. RS256 (RSA-SHA256) is an asymmetric algorithm where a private key signs tokens and a separate public key verifies them. Only the authorization server with the private key can create tokens, but any service can verify tokens using the widely-distributed public key. RS256 is recommended for distributed systems, while HS256 may be acceptable for simple, single-server applications where the secret never leaves the server.

JWT access tokens should have short lifespans (5-15 minutes) to limit exposure if stolen. When the access token expires, applications use a separate refresh token (stored securely, often in httpOnly cookies) to obtain a new access token without requiring the user to log in again. Refresh tokens have longer lifespans (days to weeks) and are used only with the authorization server, never sent to resource APIs. This two-token pattern balances security (short-lived access) with user experience (no constant re-authentication). The refresh token can be revoked server-side for instant logout, while access tokens remain stateless.