A county fir-cone catalog web app puts an ID token in the Authorization header when calling a downstream inventory API and receives HTTP 401. What should the developer send to the API?
Select an answer to reveal the explanation.
Short Explanation
Think of the ID token as the app’s nametag for its own session, and the access token as the ticket the API actually checks. Send the ticket, not the nametag.
Full Explanation
The inventory API must receive an access token whose audience is that API. Keep the ID token inside the county fir-cone catalog app for its own session and user profile claims. Access tokens are the API’s authorization ticket; the Microsoft identity platform issues them for a specific resource. When the catalog app calls downstream, it requests a token for the inventory API’s application ID URI (or client ID) and places that access token in the Authorization header.
A refresh token in the Authorization header fails because refresh tokens are for the client to obtain new access tokens from the token endpoint. Downstream APIs do not accept refresh tokens as bearer credentials, and exposing them to another service expands the blast radius if that service is compromised.
Reusing the ID token after Base64-decoding the payload for the API to re-sign fails because ID tokens are for the client, not for API authorization. Decoding does not turn an ID token into a valid access token, and APIs must not re-sign arbitrary payloads. Signature validation and audience checks will reject the wrong token type.
An unsigned JWT that lists the grower’s email fails because the inventory API must verify an Entra-signed token. Unsigned claims can be forged by anyone who can craft JSON, so they prove nothing about authentication or authorization.
Exam caveat: even a correctly shaped JWT is wrong if aud is the catalog app’s client ID instead of the inventory API. Audience mismatch is a common cause of HTTP 401 after developers “fixed” the header by pasting whatever token MSAL already had.
Operational check: decode the token you send (without trusting unsigned tools for security decisions) and confirm aud matches the inventory API, iss matches the expected tenant endpoint, and exp is still valid. Confirm the catalog app requests the inventory API’s scope or app ID URI when acquiring the token, not only openid/profile for the ID token.