API Gateway Authorizer and Logout (Performance/Security Considerations) - amazon-web-services

Question

I am using Cognito, API Gateway and Authorizers. Authorizers are configured to be cached for 5mins for performance. I felt that this is a nice feature.
I understand that authorizers are a good way to keep auth logic in one place and apps can assume users are already authorized. However, I am having my doubts.
The pentest report recommends that once logged out tokens should not be able to be used. So it means for security, I should not enable authorizer caching? It also means all authenticated APIs will have a go through one overhead of a lambda authorizer ...
Also from a coding perspective, isit really a good idea to use authorizers which are hard to test end to end? I could test the lambda function as a unit. But whats more important to me is they are attached to the correct APIs. Theres currently no way I see that allows me to test this easily.
Another problem is looking at the code, I can no longer tell what authorization is required easily ... I have to look through which authorizer is supposed to be attached (eg. CloudFormation) then the lambda code itself.
Is there a good thing from using Authorizers? Or whats the best practice with this actually?

Answer 1

For security, I should not enable authorizer caching
If you have strict security requirements (e.g., as soon as a token is invalidated all requests should fail) you will need to turn off authorizer caching. See this answer from https://forums.aws.amazon.com/thread.jspa?messageID=703917:
Currently there is only one TTL for the authorizer cache, so in the scenario you presented API Gateway will continue to return the same cached policy (generating a 200) for the cache TTL regardless of whether the token may be expired or not. You can tune your cache TTL down to level you feel comfortable with, but this is set at level of the authorizer, not on a per token basis.
We are already considering updates to the custom authorizer features and will definitely consider your feedback and use case as we iterate on the feature.
It also means all authenticated APIs will have a go through one overhead of a Lambda authorizer...
That it does. However, in practice, my team fought far harder with Lambda cold starts and ENI attachment than anything else performance-wise, so the overhead that our authorizer added ended up being negligible. This does not mean that the performance hit was not measurable, but it ended up increasing latency on the order of milliseconds over placing authorizer code directly in the Lambda, a tradeoff which made sense in our application. In stark contrast, Lambda cold starts could often take up to 30s.
Also from a coding perspective, is it really a good idea to use authorizers which are hard to test end to end?
In many applications built on a service-oriented architecture you are going to have "end-to-end" scenarios which cross multiple codebases and can only be tested in a deployed environment. Tests at this level are obviously expensive, so you should avoid testing functionality which could be covered by a lower-level (unit, integration, etc.) test. However, it is still extremely important to test the cohesiveness of your application, and the fact that you will need such tests is not necessarily a huge detractor for SOA.
I could test the Lambda function as a unit. But what's more important to me is they are attached to the correct APIs. There's currently no way I see that allows me to test this easily.
If you are considering multiple authorizers, one way to test that the right authorizers are wired up is to have each authorizer pass a fingerprint down to the endpoint. You can then ping your endpoints and have them return a health check status.
For example,
[ HTTP Request ] -> [ API Gateway ] -> [ Authorizer 1 ] -> [ Lambda 1 ] -> [ HTTP Response ]
Payload: Payload:
user identity status: ok
authorizer: 1 authorizer: 1
In practice, my team had one authorizer per service, which made testing this configuration non-critical (we only had to ensure that endpoints which should have been secured were).
Another problem is. looking at the code, I can no longer tell what authorization is required easily... I have to look through which authorizer is supposed to be attached (eg. CloudFormation) then the Lambda code itself.
Yes, this is true, and the nature of a hugely decoupled environment which was hard to test locally was one of the biggest gripes my team had when working with AWS infrastructure. However, I believe that it's mainly a learning curve when dealing with the AWS space. The development community as a whole is still relatively new to a lot of concepts that AWS exposes, such as infrastructure as code or microservices, so our tooling and education is lacking in this space when compared with traditional monolithic development.
Is this the right solution for your application? I couldn't tell you that without an in-depth analysis. There are plenty of opinions in the broader community which go both ways, but I would like to point you to this article, especially for the fallacies listed: Microservices – Please, don’t. Use microservices because you have developed a solid use case for them, not necessarily just because they're the newest buzzword in computer science.
Is there a good thing from using Authorizers? Or what's the best practice with this actually?
My team used authorizers for AuthN (via a custom auth service), and handled AuthZ at the individual Lambda layer (via a different custom auth service). This was hugely beneficial to our architecture as it allowed us to isolate what were often extremely complex object-specific security rules from the simple question of identity. Your use case may be different, and I certainly won't claim to know best practices. However, I will point you to the API Gateway Authorizer examples for more ideas on how you can integrate this service into your application.
Best of luck.