Quite a few clients have asked me “Hey Yan, what API Gateway auth method should I use for this REST API?” so I thought I’d share my answer with everyone here.
This is the high-level decision tree I go through when deciding if and what auth method I should use. It’s directly applicable for over 90% of the use cases I have come across.
What about performing authentication and authorization inside the Lambda function itself?
The short answer is don’t do it!
When API Gateway rejects an unauthorized request, we don’t pay for the request. If we perform authentication and authorization inside our Lambda functions then we have to pay for both the API Gateway request and the Lambda invocation. This opens us up to naive denial-of-wallet attacks where attackers can generate lots of invalid requests against our API.
What about API Gateway resource policy?
API Gateway resource policies offer another layer of control on top of the auth method on individual methods. We can whitelist/blacklist a range of IPs or AWS accounts, and we can also restrict access to the API to VPCs (see here for more details).
When we have internal tools that are only accessible through the company’s VPN, then we can use IP Whitelisting to restrict access to the VPN’s public IP addresses. However, this shouldn’t be the default. As much as possible, we should integrate the internal tool with a user management system such as Auth0 or Cognito and use the appropriate auth method.
IP Blacklisting is often used in conjunction with other authentication methods to explicitly deny a list of known, suspicious IPs. While this can be useful, it doesn’t scale well as it makes us responsible for maintaining the list of known, suspicious IPs. Also, where we have multiple REST APIs, we’d have to keep the resource policies in-sync to keep out the bad actors. A much better approach is to configure a Web ACL in AWS WAF and apply it to all our APIs.
We can use resource policy to make private APIs?—?that is, APIs that are only accessible through our VPCs. Much has been said about zero-trust networking, that is, no one should be trusted by default, even when they are already inside our network. So even when we use resource policy to enforce access through VPC, we should still employ one of the aforementioned auth methods in our REST APIs. Network security should be applied in addition to, not instead of, the layer 7 protections provided by API Gateway.
Finally, what about whitelisting AWS accounts? This is necessary when making cross-account API requests using AWS_IAM auth. The REST API needs to white list the caller’s AWS account (or user/role) before the caller is able to use its IAM policy to provide access to our APIs. For more information about cross-account access management with IAM, have a read of these pages from the IAM documentation:
Hi, my name is Yan Cui. I’m an AWS Serverless Hero and the author of Production-Ready Serverless. I specialise in rapidly transitioning teams to serverless and building production-ready services on AWS.
Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.
You can contact me via Email, Twitter and LinkedIn.
The post How to choose the right API Gateway auth method appeared first on theburningmonk.com.
Top comments (0)