After a successful token exchange, a developer caches the authorization code to “renew” access later when the access token expires. What happens if that code is replayed at the token endpoint?
Select an answer to reveal the explanation.
Short Explanation
A used cloakroom ticket will not get you a second coat. Replaying the authorization code fails. When the access token expires, use a refresh token or run a new grant—don’t reuse the code.
Full Explanation
Authorization codes are single-use by design. After a successful token exchange for the municipal app, replaying a cached code at the token endpoint yields invalid_grant or an equivalent rejection. When the access token later expires, renew with a refresh token if one was issued, or run a new authorize → code → token grant—do not resurrect the spent code as a renewal key.
Codes are not refreshable access factories; the authorization server will not keep minting tokens from a replay. Codes do not upgrade themselves into refresh tokens without an explicit token response that included refresh_token. Treating a used code as a long-lived API key ignores both expiry and one-time redemption semantics. Instrument token-endpoint responses so invalid_grant on replay is visible in metrics for the city app. Operators should know that a sudden spike in invalid_grant after deploys often means someone cached codes instead of refresh tokens.
Exam caveat: store refresh_token if provided and the access_token securely; discard the authorization code immediately after a successful exchange. Operational check: exchange a code once successfully, attempt the same code again and confirm rejection, then renew access via refresh_token or a fresh grant when the access token expires.