How do I fix invalid_grant in OAuth 2.0 PKCE with redirect URI flow?

[ZoeyG]

So I’m trying to connect our internal dashboard to a couple of external data sources, and I’ve hit a wall with one provider’s authentication flow. They use OAuth 2.0 with PKCE, which is new to me, and I keep getting an invalid grant error after the callback. Has anyone else wrestled with this specific setup and found where the mismatch usually happens? I’m staring at my redirect URIs and code verifier feeling like I’m missing something obvious.

[KevinBR]

I feel that PKCE headaches. The invalid_grant after callback often means the code_verifier got mangled along the way. Are you sure the code_verifier you send in exchange for the token matches exactly the one used to create the code_challenge, and that nothing in between URL-encodes or trims it?

[Mia_T]

PKCE basics say the code_verifier is used once to swap the code for a token, so a mismatch or a slight encoding tweak will bite you. Check that the redirect_uri in the token request is identical to what you registered and to what you used in the authorization request.

[Joseph6]

I used to assume PKCE rules are universal, but some providers still expect a client_secret for certain app types. Have you checked whether the provider requires a client_secret in addition to PKCE for your client type?

[Isabella74]

I wonder if the problem is not PKCE at all but something around the callback handling; a clock skew, a state mismatch, or a misdeclared token endpoint. Might be worth tightening the state parameter validation too, not just PKCE.

[Violet65]

Maybe the framing is off; perhaps the real blocker is how redirect URIs are registered across environments. PKCE is supposed to be a safety net, not a loophole. What if the mismatch is in the environment-specific redirect_url, not the code_verifier?

[DonaldAG]

Take a quick logging pass: record the exact code_verifier you generate, the code_challenge you send, the redirect_uri, and the response from the token endpoint. If you can share tokens with redacted values, we can spot where the discrepancy hides.