Is AWS API Gateway custom authorizer useful?

Question

I am looking to use some "serverless api server" for AWS Lambda /zappa that uses a custom API Gateway authorizer for user authentification. In serverless AWS lambda service is there a considerable security or cost benefit in using custom authorizer rather than checking the issued JWT token directly in your code controller? For me checking with the code could be more convenient.

UPDATE I went for pre request hooks, however there is header level authorizer, it is easier to use for CORS, yet it is not supported by zappa I believe. Also setting mock API for Options might be possible via swagger upload, will update if succeed.

Answer 1

I don't think there is strictly speaking a security or cost benefit. The benefit is that it is a single place, a single piece of code, that handles your authorization. It prevents you from having to duplicate that authorization code in every single Lambda function you deploy behind your API. And it allows you to update a single function to make any changes to your authorization logic.

From the perspective that it provides a single source of truth for your authorization logic, and it allows you to implement separation of concerns , it could be said to enhance your application's security.

That being said, if your entire API consists of a single Lambda function, then the benefit is somewhat dubious. I think API Gateway Custom Authorizers really become beneficial when your API has many Lambda functions or when your API Gateway is sitting in front of traditional HTTP servers.

Answer 2

@Mark B makes excellent points I certainly don't dispute anything in his answer. I'd like to contribute to the conversation nevertheless.

An answer tailored more specifically to you might depend on where the JWTs come from, and how they're being acquired, used, and refreshed. Using a custom authorizer may make sense in these scenarios:

Use Case 1

Custom authorizers can be useful if you want to secure a single Lambda behind several different flavors of authorization. For example, you can create three different API Gateway endpoints that each invoke the same Lambda, but use distinct authorizers. This ties into Mark's point about the DRY benefits.

Use Case 2

Custom authorizers afford you the ability to build IAM permissions inline in your authorizer code. Rather than assigning a pre-existing IAM role to a caller, you can build any arbitrary set of permissions you like. Note that this can easily become a nasty attack vector if you're somehow using (untrusted) user input to assign IAM permissions.

Use Case 3

Lambdas are great for hiding secrets. For example, you have a front-end JS app and you need to participate in OAuth 2.0 flows that require client id and client secret. Or you need to call endpoints that require API keys of some sort. Clearly, you can't expose these secrets to the browser.

These values can be encrypted and stored in environment variables specific to the Lambda function. While you could certainly take this approach with your back-end lambda, using an authorizer instead has the following benefit:

I like being able to restrict the scope of these secrets as tightly as possible. By using an authorizer, my application can remain blissfully unaware of these secrets. This ties into Mark's point about separation of concerns.

IAM and Least Privilege

I prefer that my back end code never gets invoked by unauthorized parties. For this reason, I use an authorizer of some type on virtually every API Gateway resource I create. I have used custom authorizers, but they're kind of my last resort. I lean on IAM authorization most of the time, using Cognito to trade tokens for temporary IAM credentials.

If you perform authorization in your back-end lambda, rather than in an authorizer, you can't be as restrictive when defining the IAM contols around your back-end lambda. This is a violation of the principle of least privilege . This isn't just a matter of code organization and application architecture; it's a legitimate security concern. You're essentially exposing more attack surface than you have to.

Furthermore, the real power of IAM shines when your back end grows. Your back-end lambda may need to write to S3, invoke other Lambdas, publish to SNS or SQS, interact with RDS or DynamoDB, etc. I'd suggest that "best practice" dictates that all of this access is governed by strict IAM policies. In my experience, using an API Gateway authorizer (of any type, not necessarily custom) to assign a role is the most straightforward way to accomplish this.

Answer 3

To the cost part of the question. Authorizer will be a separate charge for one additional lambda call, and new cpu time with its own 100ms minimum charge. This may be significant costs if there are many short lambdas in backend, could be doubling cost of each of them.