A rowan-berry press API currently accepts any well-formed JWT. Which validation must the developer require for Microsoft Entra access tokens?
Select an answer to reveal the explanation.
Short Explanation
A JWT that merely looks tidy isn’t enough. The API has to insist the audience is this API and the issuer is the Entra endpoint you trust.
Full Explanation
Microsoft Entra access-token validation for the rowan-berry press API must require audience equal to this API’s application ID URI or client ID, and issuer equal to the expected Entra endpoint for the trusted tenant (or authorized multi-tenant issuers if that is an explicit design). Signature validation against Entra signing keys, lifetime checks, and then roles/scp authorization complete the baseline. Structure alone never proves a token is meant for this API.
Checking only that the JWT has three Base64 segments fails because format checks accept forged or wrong-audience tokens. Without cryptographic and claim validation, “well-formed” is meaningless.
Matching the kid header to any string published in Blob Storage fails because signing key identity must come from Entra’s discovery metadata, not an arbitrary blob the API happens to read. Kid matching without trusted JWKS still does not validate the signature chain properly.
Requiring the token’s email claim to equal the storage account name fails because email is not an API audience substitute, storage account names are unrelated to Entra token validation, and many tokens legitimately omit email depending on scopes and account types.
Exam caveat: v1 and v2 tokens can differ in issuer format and whether aud is a GUID client ID or an api:// application ID URI. Align your validation library with the token version your app registration issues.
Operational check: send a token minted for another API and confirm rejection on aud; send an expired token and confirm rejection on lifetime; send a valid token for this API and confirm acceptance before role checks run.