keycloak Invalid parameter redirect_uri

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.

linear oauth failed redirect_uri not whitelisted error

TL;DR

Linear enforces exact redirect URI matching, so copy the exact redirect_uri your app sends and add it verbatim in the Linear app's OAuth redirect URI list. Watch the scheme, host, path, and trailing slash. Retry the authorize flow and the code exchange should proceed.

linear oauth failed redirect_uri not whitelisted error

Use this when

• Linear OAuth authorize step fails mentioning redirect_uri
• The integration works locally but fails when deployed
• A recent URL change (domain, path, or HTTPS) preceded the failure

Not for this skill when

• Token endpoint errors after a successful authorize (different stage)
• invalid_scope errors (scope problem, not redirect)
• User denies the consent screen (user choice, not config)

Steps

Step 1: Capture the exact redirect URI

Log or copy the redirect_uri parameter your app actually sends in the authorize URL. Expected: you have the literal string, not what you think it sends.

Step 2: Register it verbatim in Linear

In the Linear app settings under OAuth, add that exact URI to the redirect URI list. Expected: the list contains the URI character for character.

Step 3: Fix scheme and host issues

Use https in production, include any port or path the app really uses, and drop query strings unless Linear supports them. Expected: the registered URI matches the request on every component.

Step 4: Retry the authorize flow

Start the OAuth flow again from the beginning. Expected: Linear redirects back to your callback with a code instead of an error.

Step 5: Confirm the full exchange

Exchange the code for tokens and make a test API call. Expected: tokens are issued and the API responds.

Step 6: Register all environments

Add the redirect URIs for local, staging, and production so each environment works. Expected: no environment is left failing.

Tool compatibility

Linear OAuth 2.0 apps; Linear app settings (OAuth redirect URIs); the integrating application's auth callback route.

Variant phrasings

Variant 1

linear oauth redirect_uri mismatch not whitelisted

Variant 2

linear oauth error redirect uri is not registered

Variant 3

linear app oauth callback url invalid

Why it happens

The redirect URI check exists so stolen authorization codes cannot be delivered to an attacker's address: the provider only sends codes to pre-registered destinations. Linear applies the check strictly, comparing the sent value against the registered list. The mismatch is usually mundane, a trailing slash, http vs https, or a deploy that changed the domain, but the error gives no hint which character differs, so the fix is mechanical comparison. Local development adds a wrinkle because the registered local URI and the deployed URI are different entries that must both exist.

Edge cases / pitfalls

• Some providers allow query strings in redirect URIs and some do not; keep the registered URI clean and pass state via the state parameter.
• Reverse proxies that terminate TLS can make the app generate an http redirect_uri behind an https URL; configure the proxy headers.
• Do not register overly broad redirect URIs to dodge the check; that defeats the security control.

Provenance

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

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

Thread query: linear oauth failed redirect_uri not whitelisted error

TL;DR: Linear enforces exact redirect URI matching, so copy the exact redirect_uri your app sends and add it verbatim in the Linear app's OAuth redirect URI list. Watch the scheme, host, path, and trailing slash. Retry the authorize flow and the code exchange should proceed.

Not specified by the original author.

Notion OAuth invalidgrant from redirecturi mismatch between the two calls

TL;DR

If Notion returns invalidgrant on the OAuth code exchange, compare the redirecturi sent in the authorize call with the one in the token call. Make them identical, or omit the parameter from both calls entirely, and the exchange will go through. Context: Stack Overflow #67782515 (accepted answer, 13 votes): the asker completed the Notion OAuth authorize step fine but got invalid_grant when exchanging the code at /v1/oauth/token.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Compatibility

The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Details

The accepted answer found the mismatch: the authorize URL and the token request disagreed on redirect_uri. Removing the redirect parameter from both calls, so neither call sent it, made the exchange succeed. Notion validates that the two calls agree on the value.

Source: Stack Overflow #67782515 (accepted answer, 13 votes): the asker completed the Notion OAuth authorize step fine but got invalidgrant when exchanging the code at /v1/oauth/token. The accepted answer found the mismatch: the authorize URL and the token request disagreed on redirecturi. Removing the redirect parameter from both calls, so neither call sent it, made the exchange succeed. Notion validates that the two calls agree on the value.

Verified resolution: If Notion returns invalidgrant on the OAuth code exchange, compare the redirecturi sent in the authorize call with the one in the token call. Make them identical, or omit the parameter from both calls entirely, and the exchange will go through.

Source URL: https://stackoverflow.com/questions/67782515/notion-api-getting-invalid-grant-when-trying-to-generate-authorization-token