Debug OAuth 2.0 Flows in Real Time with Fiddler

OAuth 2.0 is the de facto standard for delegated authorization—but its multi-step, redirect-driven nature makes it notoriously hard to debug. When tokens fail to issue, redirects misfire, or scopes mysteriously vanish, you’re not just chasing logs—you’re chasing HTTP transactions across browsers, apps, and identity providers. Fiddler is uniquely suited to this challenge: as a local HTTP debugging proxy, it captures every request and response in the flow—including those buried in browser redirects, silent iframe refreshes, and native app callbacks—giving you full visibility into what’s actually being sent and received.

This tutorial walks you through using Fiddler for end-to-end OAuth 2.0 debugging—from configuring HTTPS decryption and filtering auth traffic, to inspecting PKCE challenges, validating token responses, and troubleshooting common failure points. Whether you’re testing an Authorization Code Flow with PKCE, debugging a client_credentials grant, or reverse-engineering a third-party login widget, these techniques apply directly to real-world API testing scenarios.

Prerequisites: Install and Configure Fiddler for HTTPS Decryption

Before inspecting OAuth flows, ensure Fiddler can decrypt TLS traffic. This is non-negotiable: modern OAuth endpoints (e.g., https://login.microsoftonline.com, https://accounts.google.com) only speak HTTPS.

1. Launch Fiddler → Tools > Options > HTTPS
2. ✅ Check Decrypt HTTPS traffic
3. ✅ Check Ignore server certificate errors (for dev/test environments only)
4. Click Actions > Trust Root Certificate and install the Fiddler root CA into your OS and browser trust stores
5. Restart your browser (and any relevant mobile emulators or desktop apps)

⚠️ Warning: Never enable HTTPS decryption on production machines or shared workstations. Use a dedicated test environment. For more details on secure HTTPS decryption setup, see our fiddler tutorial on certificate trust best practices.

Without this step, Fiddler will show <Protocol Error> or Tunnel to entries instead of readable requests—rendering OAuth debugging impossible. This is the most common cause of failed Fiddler debugging sessions.

Capture and Filter OAuth Traffic Effectively

OAuth 2.0 flows generate high-volume, noisy traffic—especially in browser-based apps that load analytics, ads, and fonts alongside auth redirects. To avoid drowning in noise:

Use AutoResponder + Filters to Isolate Auth Domains

1. In Fiddler, go to the Filters tab
2. ✅ Enable Use Filters
3. Under Hosts, select Show only the following Hosts and enter domains like:
   • login.microsoftonline.com
   • accounts.google.com
   • auth.your-api.com
   • your-app.com (your redirect URI domain)

Alternatively, use Rules > Customize Rules (Ctrl+R) to add a quick filter shortcut:

if (oSession.HostnameIs("login.microsoftonline.com") || 
    oSession.HostnameIs("accounts.google.com") || 
    oSession.oRequest.headers.Exists("Authorization")) {
    oSession["ui-color"] = "orange";
}

This highlights auth-related sessions in orange—making them instantly scannable.

Leverage the Composer for Manual Token Exchange Testing

Once you’ve captured an Authorization Code (e.g., from a /callback?code=xyz URL), paste it into Fiddler’s Composer tab to manually trigger the token exchange:

• Method: POST
• URL: https://auth.your-api.com/oauth/token
• Headers:

  Content-Type: application/x-www-form-urlencoded
  

• Body (form-encoded):

  grant_type=authorization_code&
  code=xyz&
  redirect_uri=https%3A%2F%2Fyour-app.com%2Fcallback&
  client_id=abc123&
  code_verifier=... (if using PKCE)
  

This lets you iterate rapidly—changing code_verifier, tweaking scopes, or testing expired codes—without restarting your app.

Inspect PKCE, State, and Redirect Integrity

PKCE (RFC 7636) and state parameters are critical security controls—and frequent sources of silent failures.

Validate PKCE Handshake End-to-End

In Authorization Code + PKCE flows, Fiddler lets you verify all three components:

1. Code Challenge: Captured in the initial /authorize request (e.g., code_challenge=...&code_challenge_method=S256)
2. Code Verifier: Held client-side—compare it against the challenge using an online S256 verifier or Python:

   import hashlib, base64
   code_verifier = "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
   hash_digest = hashlib.sha256(code_verifier.encode()).digest()
   code_challenge = base64.urlsafe_b64encode(hash_digest).decode().rstrip("=")
   

3. Token Request: Confirm the code_verifier appears unhashed in the /token POST body

If the token endpoint returns invalid_grant, mismatched PKCE values are the #1 suspect—and Fiddler shows exactly which value was sent.

Audit `state` Parameter Consistency

The state parameter prevents CSRF. With Fiddler, you can trace it across:

• Initial /authorize?state=abc123…
• Redirect back to your app: GET /callback?state=abc123&code=...
• Any subsequent token or userinfo calls (if echoed)

Use Inspectors > TextView on each session to copy/paste and compare state values. A mismatch means your app either generated two different states—or lost state across redirects (e.g., due to SPA routing quirks).

Decode and Validate Tokens On-the-Fly

Fiddler doesn’t parse JWTs by default—but with a lightweight extension, you can decode ID tokens and access tokens in context, without leaving the tool.

Install JWT Inspector (Free Extension)

1. Download JWTInspector.dll from Telerik’s Fiddler Extensions Gallery
2. In Fiddler: Tools > Fiddler Options > Extensions > Load
3. Restart Fiddler

Now, when you select a session containing a JWT (e.g., in Authorization: Bearer ey... or response body), the JWT tab appears in Inspectors—showing decoded headers, payload, signature status, and expiration time.

✅ Use this to instantly check:

• exp and iat skew (is the token expired before you even receive it?)
• aud matches your registered client ID
• iss matches your expected identity provider
• scope contains required permissions (e.g., read:orders write:profile)

No more pasting tokens into jwt.io mid-debug—everything stays in your workflow.

Troubleshoot Common OAuth Failures Using Fiddler Evidence

When things break, Fiddler provides forensic-grade evidence—not guesses.

Scenario 1: “Redirect URI Mismatch” Error

You see error=redirect_uri_mismatch in browser console or callback query string.

🔍 In Fiddler:

• Find the /authorize request
• Inspect redirect_uri param in URL or form body
• Compare exactly (including trailing slashes, encoding, and protocol) with what’s registered in your IdP dashboard
• Bonus: Check if your app double-URL-encodes the value (e.g., https%253A%252F%252F...) — Fiddler’s TextView shows raw bytes, so you’ll spot %25 vs %2F immediately.

Scenario 2: Empty or Malformed Token Response

The /token POST returns 200 OK but {"error":"invalid_request"} or blank body.

🔍 In Fiddler:

• Switch to Raw or TextView inspector
• Confirm Content-Type: application/x-www-form-urlencoded is present
• Verify no extra whitespace or Unicode BOM before form data
• Check for missing required params (client_id, grant_type, code, redirect_uri)
• If using Basic Auth for client credentials, confirm header format: Authorization: Basic base64(client_id:client_secret)

Scenario 3: Silent iframe Refresh Fails (OIDC Implicit or Hybrid Flow)

Your SPA shows “Login session expired” but no visible error.

🔍 In Fiddler:

• Filter for iframe or prompt=none in /authorize URLs
• Look for HTTP 400 or 200 with HTML error page inside iframe response
• Check Set-Cookie headers: Are auth cookies being blocked (e.g., SameSite=Lax breaking cross-origin iframe writes)?
• Use Timeline tab to see timing gaps—e.g., 10+ sec delay before iframe loads often indicates consent screen or MFA pending.

These aren’t theoretical edge cases—they’re daily blockers for API testers and frontend engineers. Fiddler turns opaque platform errors into actionable HTTP evidence.

Pro Tips for Production-Like OAuth Testing

• Simulate mobile app behavior: Configure Fiddler as system proxy on Android/iOS (via Wi-Fi settings), then launch your app. You’ll see native WebView or custom tabs hitting auth endpoints—no browser abstraction.
• Replay with modified headers: Right-click any session → Replay > Replay with Modifiers. Add Authorization: Bearer invalid-token to test your API’s error handling.
• Export sessions as HAR: File > Export Sessions > All Sessions > HTTPArchive v1.2. Share with backend teams or import into Postman for deeper analysis.
• Script validation: Use FiddlerScript (Customize Rules) to auto-flag sessions where response.bodyString.Contains("error") or oSession.responseCode == 401.

For advanced workflows—like mocking IdP responses or injecting custom claims—combine Fiddler’s AutoResponder with saved .json stubs. This lets you simulate token revocation, expired signatures, or malformed jwks_uri responses without touching production infrastructure.

Conclusion: Your OAuth Debugging Workflow, Upgraded

OAuth 2.0 isn’t broken—it’s complex, distributed, and intentionally opaque for security reasons. But opacity shouldn’t mean obscurity in development. With Fiddler configured for HTTPS decryption and armed with targeted filters, token inspection, and manual replay, you transform guesswork into precision debugging.

Key takeaways:

• Always validate HTTPS decryption first—no decrypted traffic means no OAuth visibility
• Filter early, highlight auth domains, and use Composer to iterate on token exchanges
• PKCE and state aren’t optional—they’re observable, verifiable, and must be traced end-to-end
• JWT Inspector eliminates context switching and surfaces token validity at a glance
• Every OAuth error has an HTTP fingerprint—Fiddler surfaces it unambiguously

Mastering this workflow makes you faster at shipping secure integrations, more credible when diagnosing partner IdP issues, and far more effective in API testing roles. If you're new to Fiddler’s capabilities beyond basic capture, explore our browse API Testing tutorials for related deep dives on GraphQL introspection, rate-limit analysis, and header injection testing. And if you hit a scenario not covered here, contact us—we’ll help you build the right Fiddler solution.