A county library API uses an OCI Functions authorizer in front of HTTP back ends. After authentication succeeds, routes must enforce which operations the patron may perform, and one back-end URL needs a library-branch id injected from the authorizer. What should the authorizer return?
Select an answer to reveal the explanation.
Short Explanation
The authorizer is like a bouncer who stamps your wristband with what you may do and a table number—not the chef who cooks the meal. It returns whether the client is authenticated, the access scopes for allowed operations, and optional context the gateway can plug into back-end URLs. The route’s authorization policy then applies those scopes; the authorizer is not the business API.
Full Explanation
After an OCI Functions authorizer authenticates a caller on API Gateway, the gateway still needs structured outputs to enforce what the patron may do and to inject values such as a library-branch id into a back-end URL. The authorizer contract therefore returns authentication success or failure, access scopes that describe permitted operations, and optional context as key-value pairs. Route authorization policies evaluate those scopes. Context variables can be referenced in deployment configuration so an HTTP back end receives the branch id without the client forging it. That keeps the county library API’s identity check at the gateway while the catalog or circulation systems remain the true business back ends.
Returning only a boolean allow flag fails because scopes and context are how the gateway applies fine-grained authorization and URL injection after authentication. Having the authorizer return the full business response body for every catalog search turns the authorizer into the API itself and breaks the separation the product documents. Emitting OpenAPI 501 stock responses for every path until a card is renewed confuses deployment scaffolding for unimplemented paths with runtime authorization for authenticated patrons.
Exam caveat: scopes drive the route’s authorization policy; context is optional enrichment. Do not assume context alone authorizes an operation if scopes are missing or mismatched.
Operational check: authenticate a test patron, inspect the authorizer’s returned scopes and context, confirm a restricted route rejects missing scopes, and verify the back-end URL receives the injected library-branch id from context rather than from an untrusted client header.