Choosing an API Gateway authorizer
1. Choosing an API Gateway authorizer
So far we have covered who a user is and what a policy lets them do. None of it runs until a request actually reaches your code. Something has to check the caller at the door, and for an API that something is API Gateway.2. Checked before your code runs
Every request reaches API Gateway first, and its authorizer decides who gets through. Think of a building lobby: you clear reception once before any lift moves.3. Who does the checking
Three authorizers exist, each defined by who does the checking. With IAM auth the caller signs the request with AWS credentials, the same SigV4 signing from chapter one. AWS verifies that signature, so your code never runs authorization logic.4. Who does the checking
Next, the Cognito user pool authorizer. The caller sends a Cognito token and API Gateway verifies it: the same four checks you wrote by hand in this chapter's first video, now run by AWS.5. Who does the checking
Finally the Lambda authorizer. Reach for it when the token is not from Cognito, or the logic is custom. More power, and more of the checking to own.6. Match the door to the caller
Match the door to the caller. An internal service already holds AWS credentials, so IAM auth fits.7. Match the door to the caller
An app user carries a Cognito token, so use the Cognito authorizer.8. Match the door to the caller
And a partner app bringing its own authorization logic needs Lambda.9. Mind the API type
Which authorizers you can use depends on the API type. A REST API offers all three, plus resource policies that allow or deny by account or address. Choose REST when you need those, or API keys, per-client throttling, request validation, or WAF.10. Mind the API type
An HTTP API drops those for a lower price and less latency. Its JWT authorizer replaces the Cognito one and accepts any OpenID Connect issuer, not just Cognito. Choose HTTP for a straightforward service, or one whose users sign in elsewhere.11. The authorizer remembers
Now the detail that catches people. Running an authorizer on every call is slow, so API Gateway caches the result. Later calls with the same token read that stored answer instead.12. The authorizer remembers
That window is the cache TTL, or time to live. For a Lambda authorizer it defaults to three hundred seconds and can reach one hour.13. A cached allow can outlive its permission
Here is the trap. Suppose you revoke a caller's access right now. The permission is gone, but the cache still holds an allow and keeps answering until the TTL expires.14. A cached allow can outlive its permission
Think of a hand stamp: the door checked your ticket once and stamped your wrist, and now waves you in on the stamp. Cancel the ticket, and the stamp still works until it fades.15. A cached allow can outlive its permission
So keep the TTL short when fast revocation matters, and zero on your most sensitive routes. Before accepting the default, ask what a stale allow could do for five whole minutes.16. One caller skips the front door
One caller never comes through that door at all. A monitoring vendor works inside your account by assuming a role you created for it. You hand over the role ARN, and the vendor assumes it whenever it needs to look at your resources.17. One caller skips the front door
But your role ARN is not a secret. Another of the vendor's customers could hand over your ARN as their own, and the vendor, meaning no harm, would act on your resources. That is the confused deputy problem.18. One caller skips the front door
The fix is an external ID. The vendor generates one per customer and sends yours on every AssumeRole call, and your trust policy requires sts:ExternalId to match. No other customer can make the vendor send your value.19. Let's practice!
Now let's practice choosing an authorizer, with some exercises.Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.