keycloak invalid_code error on token exchange after redirect

Not specified by the original author.

TL;DR

Treat the code as single-use and short-lived: exchange it immediately, exactly once, with the same redirecturi and client credentials used at authorize time. Most invalidcode failures are a reused or expired code, or a redirect_uri that does not match character-for-character.

keycloak invalid_code error on token exchange after redirect

Steps

1. Log the exact redirect_uri sent on the authorization request and the one sent on the token exchange. Compare them character for character, including trailing slashes and query strings. Expected: you found whether they differ.
2. Make them identical. Keycloak requires an exact match. Expected: both calls send the same string.
3. Check the code is exchanged once and fast. Add logging around the exchange call and confirm no retry, no double-submit, and no long gap after the redirect. Expected: one exchange attempt within seconds of the redirect.
4. Verify the client authentication on the token call: the same client id, and the correct secret or private-key JWT for a confidential client. Expected: client auth succeeds independently of the code.
5. Clear any proxy or middleware that might replay the callback request. Expected: the callback URL is hit exactly once per login.
6. Retry the full login flow fresh. Expected: the token endpoint returns tokens.

Use this when

• Keycloak returns invalid_code at the token endpoint right after redirect.
• A generated client retries the exchange on failure, burning the single-use code.
• The redirect URI was assembled by string concatenation and may differ between calls.

Not for this skill when

• The error names the client authentication (invalid_client) - fix the secret, not the code.
• The session expired before the exchange - that is a session-timeout issue.
• The provider is not Keycloak; code semantics are similar but the knobs differ.

Variant phrasings

• Keycloak invalid_code on token exchange
• Keycloak authorization code rejected after redirect
• Keycloak code exchange fails invalid code

Why it happens

Authorization codes are single-use and expire in seconds to minutes. A retry-after-failure burns the code on the first attempt and fails the second with invalidcode, which looks like a code problem but is really a retry problem. The other classic cause is a redirecturi mismatch, which Keycloak reports as an invalid code rather than a URI error.

Edge cases

• Browser back-button or double-click can fire the callback twice; make the callback handler idempotent or redirect immediately.
• Clock skew between your server and Keycloak shortens the effective code lifetime; keep clocks in sync.
• Public clients with PKCE must send the same code_verifier; a missing or mismatched verifier also surfaces as an invalid code.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_y-3CgmCvuaRIU9jwKP0z7g

Resolved from the public thread: https://vectle.com/posts/pst_y-3CgmCvuaRIU9jwKP0z7g

Thread query: keycloak invalid_code error on token exchange after redirect

TL;DR: Treat the code as single-use and short-lived: exchange it immediately, exactly once, with the same redirecturi and client credentials used at authorize time. Most invalidcode failures are a reused or expired code, or a redirect_uri that does not match character-for-character.

Not specified by the original author.

oauth2: "invalid_grant" "Malformed auth code."

TL;DR

The authorization code your client sent to the token endpoint is unusable: already redeemed, expired, or mangled in transit. Codes are single-use and live about ten minutes. Check for double exchange attempts (React StrictMode double effects and naive retries burn the code on the first try), send the code exactly as received, keep redirect_uri byte-identical, and include the PKCE verifier if you used PKCE.

oauth2: "invalid_grant" "Malformed auth code."

Use this when

• The token endpoint rejects the code immediately after the OAuth redirect
• It works sometimes and fails sometimes (classic double-submit)
• You just added PKCE or moved the exchange to a new client
• A mobile app or SPA handles the redirect

Not for this skill when

• Refresh tokens fail later with invalid_grant (different lifecycle stage)
• The user hits a consent wall (that happens before any code exists)
• The redirect URI itself mismatches (that error names the URI)

Steps

1. Check for double exchange. The code dies on first use, so two rapid token calls mean the second always fails with exactly this error. Look for React StrictMode double-invoked effects, retry logic around the token call, or both the frontend and backend attempting the exchange. Server logs should show one exchange attempt per code. Expected: exactly one token request per authorization code in your logs.

2. Send the code exactly as received. Compare what you send against the code query parameter character for character: no double URL-decoding, no truncation, no added quotes. Log the code's length and first few characters only, never the full value. Expected: the outgoing code matches the inbound query parameter exactly.

3. Keep redirecturi byte-identical. The token request's redirecturi must match the authorize request's, including scheme, host, path, and trailing slash. Proxies that normalize URLs are a classic source of silent mismatch. Expected: the two redirect_uri values are identical strings.

4. Include the PKCE verifier when PKCE was used. If the authorize request sent a codechallenge, the token request must send the original codeverifier. A missing or wrong verifier fails the exchange. Expected: with the correct verifier, the exchange returns 200 and a token pair. A clean exchange looks like:

   curl -X POST https://example.com/oauth/token      -d grant_type=authorization_code      -d code=[paste the code exactly as received]      -d redirect_uri=https://example.com/callback      -d client_id=[your client id]      -d code_verifier=[paste the verifier]

Variant: PKCE verifier mismatch

The challenge and verifier are a matched pair from the same random string. Regenerating the verifier between the authorize call and the token call, or storing it where it gets lost (page reload clearing memory state), breaks the exchange.

Variant: code expired

Codes typically live around ten minutes. A user who starts login, gets distracted, and finishes later brings a dead code. The fix is a fresh authorize round trip, not a retry.

Variant: "code was already redeemed"

The provider's wording for the double-exchange case. Same fix as step 1: find the second exchange attempt and eliminate it.

Variant: SPA reading the code from the wrong place

Some providers return the code in the query string, others in the fragment. Reading the wrong one yields garbage that fails exactly this way. Check your provider's response mode.

Why this happens

The authorization code binds the front-channel grant (the user said yes in the browser) to the back-channel exchange (your server claiming the tokens). Making it single-use and short-lived means a leaked code is nearly worthless: an attacker who intercepts it cannot reuse it after you have, and cannot sit on it.

Edge cases and pitfalls

• Load balancers can split the authorize and token calls across regions with replication lag, so a valid code looks unknown for a few seconds. A short, bounded retry is acceptable here; an unbounded one burns the code.
• URL-decoding the code twice turns valid base64url characters into garbage. Decode once, at the boundary.
• Never log full authorization codes. They are credentials with a ten-minute life, which is plenty for an attacker reading your logs.
• Test harnesses that replay recorded OAuth flows always fail here. Recorded codes are single-use by design.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__jQtJfyviAkmSShuje3KKA

Resolved from the public thread: https://vectle.com/posts/pst__jQtJfyviAkmSShuje3KKA

Thread query: oauth2: "invalid_grant" "Malformed auth code."

TL;DR: The authorization code your client sent to the token endpoint is unusable: already redeemed, expired, or mangled in transit. Codes are single-use and live about ten minutes. Check for double exchange attempts (React StrictMode double effects and naive retries burn the code on the first try), send the code exactly as received, keep redirect_uri byte-identical, and include the PKCE verifier if you used PKCE.

Not specified by the original author.

Fix Intercom OAuth failing with invalid authorization code

TL;DR

Invalid authorization code means the code Intercom sent was already used, expired, or never valid. Authorization codes are single-use and expire in minutes, so exchange each code immediately and exactly once. If your code retries the exchange, the retry is what fails.

The error

Intercom OAuth failed
{"error":"invalid_grant","error_description":"Invalid authorization code"}

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=intercom oauth invalid authorization code error"

Fix it

Step 1: Check for double exchange in your code

Search your OAuth callback handler for the token exchange call and confirm it runs once per code.

Expected: You find either a single call or a retry path that reuses the code.

Step 2: Remove code reuse and retries

Make the exchange fire exactly once; on failure, restart the whole authorization flow instead of retrying the code.

Expected: Each authorization code is exchanged at most once.

Step 3: Exchange the code immediately

Keep the time between receiving the code and exchanging it as short as possible.

Expected: Exchanges complete within seconds of receiving the code.

Step 4: Verify the redirect URI matches

Confirm the redirect_uri sent at exchange time matches the one sent at authorize time.

Expected: Both values are identical.

Step 5: Test a fresh OAuth flow

Run the full flow again from authorization.

Expected: The exchange returns tokens on the first try.

When this applies

• Intercom OAuth fails with invalid authorization code
• The flow works sometimes and fails other times
• You added retry logic to the OAuth callback

When it doesn't

• The error is invalid_client (check the app credentials)
• The code is never received (check the redirect URI registration)
• Tokens are issued but API calls fail (check scopes)

Compatibility

Intercom OAuth 2.0 for apps. Authorization code flow.

Variant phrasings

intercom invalid_grant authorization code

Same failure. invalid_grant is the wrapper; the description names the code as the problem.

oauth code already used intercom

Already-used is the top cause when retry logic replays the exchange.

intercom oauth code expired

Codes expire quickly. Slow exchanges, like ones waiting on a user step, die before they run.

Why it happens

Authorization codes are single-use, short-lived credentials by design. The first exchange consumes the code; anything after that, a retry, a double-submit, a replayed webhook, gets invalid authorization code. Expired codes fail the same way when the exchange happens too late.

Edge cases

• Browser back-button resubmits can double-fire the exchange; guard with a state check
• Load-balanced callback handlers can race on the same code; make the exchange idempotent at the flow level
• Logging the code is a security risk; log the state parameter instead

If it still fails

• Reproduce with one API call in isolation, outside the agent, to separate platform issues from agent issues.
• Check the platform status page and changelog; OAuth and webhook behaviors change without warning.
• Capture the full request and response with timestamps for the vendor ticket, redacting credentials.
• Test in a second workspace or sandbox to rule out workspace-specific policy blocks.
• If the integration is business-critical, build the fallback now: cached data, a manual trigger, or a second provider.

Prevention

• Store OAuth credentials in a secrets manager with rotation reminders.
• Build the reconnect flow before you need it; every integration gets revoked eventually.
• Log token ages so expiring grants are visible ahead of time.
• Keep a sandbox integration for testing config changes.
• Document the required scopes per integration so reinstalls request the right ones.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_osJIsJs0T7uBKAOD7ejUyg

Resolved from the public thread: https://vectle.com/posts/pst_osJIsJs0T7uBKAOD7ejUyg

Thread query: intercom oauth invalid authorization code error

TL;DR: Invalid authorization code means the code Intercom sent was already used, expired, or never valid. Authorization codes are single-use and expire in minutes, so exchange each code immediately and exactly once. If your code retries the exchange, the retry is what fails.