Fix OAuth invalid_client Authentication Errors
invalid_client means the authorization server could not authenticate the OAuth client. Verify client identity, authentication method, and environment without exposing credentials.
Separate client and grant failures
Client authentication proves which application is calling the token endpoint. It is separate from the authorization code or refresh token being exchanged. Capture the provider, token endpoint, configured authentication method, timestamp, correlation ID, and non-secret client metadata. Never log client secrets, authorization headers, private keys, assertions, codes, refresh tokens, or token responses.
Verify client ID and environment
Copy the client ID from the provider configuration and compare it exactly, including case and invisible whitespace. Confirm that the token endpoint belongs to the same tenant, region, sandbox, or production environment as the registration. Check that the client is enabled and permitted to use the requested grant type. A valid production secret cannot authenticate a sandbox client ID.
Use the registered authentication method
Providers may require HTTP Basic, form-body credentials, a signed private-key assertion, mutual TLS, or no secret for a public client. Do not send the same credentials in both the Authorization header and body unless the provider explicitly requires it. A client registered for one method may reject another even when the ID and secret are correct.
Check Basic and form encoding
For HTTP Basic, follow the provider and OAuth encoding rules before joining the client ID and secret and Base64 encoding the result. Shell quoting, trailing newlines, incorrect character encoding, or encoding the combined string twice can change the credential. For form authentication, send application/x-www-form-urlencoded, not JSON, unless the provider documents an extension.
Handle secret and key rotation
Determine which secret version is active and whether an old secret was revoked before every instance received the replacement. Update secret storage atomically and restart or reload processes that cache configuration. For private-key assertions, verify issuer, subject, audience, expiration, unique identifier, signing algorithm, key ID, and the registered public key. Keep server clocks synchronized.
Treat browser and mobile apps as public clients
A secret embedded in JavaScript, a mobile binary, or a distributed desktop application is not confidential. Use the provider's public-client registration and authorization code flow with PKCE. Do not solve invalid_client by moving a confidential secret into frontend code.
Retest with one minimal request
Build a new token request using the documented example and one known client registration. Compare the final headers and form fields while keeping values redacted. Decode only non-secret client assertions locally with the JWT Decoder and inspect encoding with the Base64 tool.
Frequently Asked Questions
How does invalid_client differ from invalid_grant?
One concerns the client identity; the other concerns the grant.
Can encoding break Basic authentication?
Yes. Apply the documented OAuth encoding sequence exactly.
Should browser apps hold a secret?
No. Use a public-client flow with PKCE.