“Authorization code already used”: what OAuth and SSO are telling you
An authorization code is intentionally short-lived and single-use. Reusing it usually means the application is retrying the callback incorrectly or exchanging it more than once.
What the error means
In the OAuth 2.0 authorization-code flow, the identity provider sends a temporary authorization code to the registered redirect URI. The application exchanges that code for tokens on the server. The code is designed to be used once. If the same callback is processed twice, the second exchange should fail.
The error therefore often points to application flow rather than user credentials. The identity provider may be behaving exactly as designed.
Common causes
Typical causes include the callback route being requested twice, browser refresh on the callback URL, client-side code repeating a server exchange, reverse proxies retrying a non-idempotent request, or the application redirecting back to a URL that still contains the code. Another common cause is saving the code and accidentally trying to reuse it later.
Log a hash of the authorization code, the request identifier and the callback timestamp. Never log the raw code or resulting access token.
A safer callback pattern
Exchange the code once on the server, create the application session, then immediately redirect the browser to a clean URL that contains no authorization code. Store a short-lived state value before starting authentication and consume it during the callback to prevent replay and cross-site request forgery.
If the login begins from several applications, carry a validated return destination in server-side state. Do not trust an arbitrary return URL from the browser.
Debugging sequence
Confirm whether the callback endpoint is hit more than once. Check browser network logs, server access logs and application logs. Confirm that only one component performs the token exchange. Then verify the redirect URI exactly matches what is registered with the identity provider, including scheme, host and path.
If the first exchange succeeds but the user still sees an error, the problem is usually after token exchange: session creation, cookie configuration, redirect handling or application authorization.
Turn the idea into a clear implementation plan.
Use TWE to structure requirements first. If you later want implementation, Valron can pick up the same brief.