A city’s building-permit portal must reject callers unless a custom combination of API key header, department code, and an internal lookup succeeds. Standard JWT validation alone is not enough. Which API Gateway authentication approach should the developer choose?
Select an answer to reveal the explanation.
Short Explanation
Think of the gateway’s built-in JWT check as a standard lock that only understands one key shape. When the city needs a custom combination of headers plus a lookup, that lock is not enough—hand the decision to an authorizer function that can return allow/deny, scopes, and context. Native token validation stays for ordinary JWTs; custom rules belong in the authorizer.
Full Explanation
When a civic API must authenticate with a custom blend of headers, department codes, and an internal lookup, OCI API Gateway’s native JWT/OAuth path is not enough. That path validates standard tokens against JWKS, static keys, or introspection (including OCI IAM identity domains). The municipal permit portal’s rule set is custom business logic, so the correct approach is an authorizer function on OCI Functions. The authorizer receives request attributes from the gateway, evaluates the city’s combination of API key header, department code, and lookup, and returns allow or deny, access scopes, and optional context variables the deployment can use later. That contract keeps authentication decisions at the edge while still letting routes apply authorization against the scopes the authorizer supplies.
Relying only on native JWT validation fails the requirement because a remote JWKS check understands token shape and signature, not an arbitrary multi-header plus directory lookup. Treating CORS headers as authentication confuses browser cross-origin permission with caller identity; CORS never proves who the caller is. Issuing each mobile client a raw Functions invoke endpoint and API-signing key bypasses the gateway’s centralized auth, metering, and policy surface and scatters credentials—the opposite of a controlled city front door.
Exam caveat: an authorizer authenticates and shapes authorization inputs; it is not the business back end that fulfills permit submissions. Keep the authorizer focused on identity and scopes.
Operational check: invoke the deployment with valid and deliberately incomplete header sets, confirm allow/deny and scopes in the authorizer response, and verify that denied calls never reach the permit Function while allowed calls carry the expected context into the route.