After a library-cardholder consents, the municipal app’s redirect URI receives an authorization code. A junior developer places that code in Authorization: Bearer on the first resource GET. Why is that wrong?
Select an answer to reveal the explanation.
Short Explanation
The code is a cloakroom ticket, not the coat. You cannot wear the ticket; you trade it at the counter (token endpoint) for the access token, then use that as Bearer on the resource.
Full Explanation
The authorization code delivered to the municipal library portal’s redirect URI is a short-lived, single-use grant ticket. It must be exchanged at the token endpoint for an access token; only that access token belongs in Authorization: Bearer on protected resource GETs. Putting the raw code in the Bearer header confuses the ticket with the credential and fails at the cardholder profile API.
Bearer is not limited to Webex ChatOps message posts—the mistake is credential type, not a civic-versus-Webex restriction. Double Base64 wrapping of authorization codes is folklore, not part of the grant. Sending the code as a query parameter on every resource call still uses the wrong artifact and leaks a sensitive one-time code through URLs, proxies, and access logs. Log only that a code was received and redeemed—never log the code or access token values in clear text on the library portal hosts. Teach juniors the ticket-versus-badge analogy so Bearer mistakes stop recurring in code review for other civic OAuth clients.
Exam caveat: code ≠ access token ≠ refresh token; each has a distinct hop, audience, and lifetime in the constructed flow. Operational check: after redirect, POST the code to the token endpoint, store the access_token from the JSON response, and send only that value as Bearer on the first profile GET—never the code.