How to choose the right API Gateway auth method

You can become a serverless blackbelt. Enrol to my 4-week online workshop Production-Ready Serverless and gain hands-on experience building something from scratch using serverless technologies. At the end of the workshop, you should have a broader view of the challenges you will face as your serverless architecture matures and expands. You should also have a firm grasp on when serverless is a good fit for your system as well as common pitfalls you need to avoid. Sign up now and get 15% discount with the code yanprs15!

Update 21/06/2020: following lots of feedback and questions on Twitter, I have updated the post to include a few more options.

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.

How do I use Auth0 or Okta for authentication?

With third-party systems such as Auth0 or Okta, we can integrate them with Cognito User Pools as SAML identity providers (IdPs). That way, we can still use COGNITO authorizer with API Gateway and Cognito User Pools would verify the identity of the caller with the SAML IdP.

How do I support social log-in such as Facebook or Google?

Similar to the above, we can also integrate Facebook, Google, Amazon or Apple with Cognito User Pools as social identity providers.

Where does Cognito Identity Pool fit in?

With Cognito Identity Pools, we can exchange federated identities from external identity providers with temporary IAM credentials.

Cognito Identity Pools is often used to provide access to client apps so they can access AWS services directly. For example, to allow IoT devices to publish and receive messages to & from AWS IoT Core.

The same approach can be applied with API Gateway. In which case, we need to use AWS_IAM authentication and control access with IAM policies.

How can I use group-based authentication with Cognito User Pools?

This is possible with API Gateway, but it takes a lot of work as you can see from the official guide:

  1. add user groups
  2. assign an IAM role to each group to control which endpoints users in the group can access
  3. assign precedence to groups because a user can belong to multiple groups, and you need to resolve to one IAM role
  4. submit the ID token from Cognito when you send a request to API Gateway
  5. write a custom Lambda authorizer function (that’s right, you can’t use a Cognito authorizer!) to generate the correct policy based on the ID token

It’s complicated…

With AppSync, this is supported out-of-the-box and is one of the reasons why I prefer working with AppSync over API Gateway nowadays.

 

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:

Liked this article? Support me on Patreon and get direct help from me via a private Slack channel or 1-2-1 mentoring.
Subscribe to my newsletter


Hi, I’m Yan. I’m an AWS Serverless Hero and I help companies go faster for less by adopting serverless technologies successfully.

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.

Hire me.


Skill up your serverless game with this hands-on workshop.

My 4-week Production-Ready Serverless online workshop is back!

This course takes you through building a production-ready serverless web application from testing, deployment, security, all the way through to observability. The motivation for this course is to give you hands-on experience building something with serverless technologies while giving you a broader view of the challenges you will face as the architecture matures and expands.

We will start at the basics and give you a firm introduction to Lambda and all the relevant concepts and service features (including the latest announcements in 2020). And then gradually ramping up and cover a wide array of topics such as API security, testing strategies, CI/CD, secret management, and operational best practices for monitoring and troubleshooting.

If you enrol now you can also get 15% OFF with the promo code “yanprs15”.

Enrol now and SAVE 15%.


Check out my new podcast Real-World Serverless where I talk with engineers who are building amazing things with serverless technologies and discuss the real-world use cases and challenges they face. If you’re interested in what people are actually doing with serverless and what it’s really like to be working with serverless day-to-day, then this is the podcast for you.


Check out my new course, Learn you some Lambda best practice for great good! In this course, you will learn best practices for working with AWS Lambda in terms of performance, cost, security, scalability, resilience and observability. We will also cover latest features from re:Invent 2019 such as Provisioned Concurrency and Lambda Destinations. Enrol now and start learning!


Check out my video course, Complete Guide to AWS Step Functions. In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. There is something for everyone from beginners to more advanced users looking for design patterns and best practices. Enrol now and start learning!