The municipal fleet API has returned an access token to the city’s maintenance app after a successful code grant. How should subsequent protected resource calls be authorized?
Select an answer to reveal the explanation.
Short Explanation
Once you have the badge, wear the badge at the door—don’t make staff re-approve you for every hallway. Resource calls carry the access token; repeating the authorize redirect each GET is not the grant.
Full Explanation
Once the municipal fleet API’s token response has delivered an access token, subsequent maintenance-app calls to protected resources present that token—typically as Authorization: Bearer—without restarting the browser authorize redirect. The three-legged dance is finished for this access session; resource calls consume the token, not a fresh consent redirect on every GET against vehicle or work-order endpoints.
Passing the original authorization code again on each resource request reuses a spent, single-use ticket that is not a resource credential. Omitting credentials and relying on an earlier consent cookie alone confuses browser SSO residue with the constructed API Authorization header. Opening a new authorization-endpoint redirect for every individual resource GET thrashes the technician and is not the grant’s resource step. Cache token expiry from expires_in and refresh or re-grant before calling fleet resources with a stale Bearer. Municipal maintenance jobs should fail with a clear auth error if the token is missing, rather than silently falling back to another authorize redirect storm.
Exam caveat: Bearer carries the access token on the resource; authorize redirects exist to obtain grants, not to authorize each API read. Operational check: after one successful token exchange, issue multiple resource GETs with the same Bearer access token and confirm no authorize redirect is triggered between them in the maintenance app.