Handling Appsync Lambda Authorization and Cache on multiple Operations

0

I have an AppSync configured with Lambda authorization and using cache. The key that the cache checks is the API ID and the token. So in my AppSync, I have several operations, and within the token information, which is a token issued by Cognito, I have data that allows me to authorize or deny the request. But since the cache works at the token level, if I have at least one permitted operation, what happens is that I first perform that one, and then I do the others with the same token, and it lets me through on all of them because it takes the cache. How can I solve this problem without completely eliminating the use of the cache? Shouldn’t something like a hash of the token, the API ID, and the payload be considered for the cache so that it applies correctly per operation? I would appreciate your help on this topic because otherwise, I see this cache feature as not very useful unless there is only one operation in the AppSync or you have to create a new token for each operation.

Thank you.

2 Answers
0

You need to modify the cache key strategy.

  1. Create a unique cache key for each operation by combining: The authorization token The API ID The specific operation being performed

  2. Modify the Lambda authorizer to: Generate a unique hash for each request Include it in the response as the cache key Perform the actual authorization check for the specific operation

profile pictureAWS
EXPERT
answered a month ago
  • Hello thanks for the answer. But I have some questions about this. The first step im already doing it. But I don't understand the second step when you talk about include in the response of the lambda authorization and this line Perform the actual authorization check for the specific operation loss me. Becouse the cache is check on the token that is now the token + apiId + operation so they call the first time with a valid cobination that the lambda responds true to isAuthorized then he use the same combination in the token but call another operation because the cache key is the same, make a hit in the cache and the lambda it's not executed and let pass the request to the resolver. So unless I check on the resolver again that this hash in the response from the lambda (requestContext object) match and is not an intent to surpass authorization I don't see how this fix the problem or fix the problem . I mean im still need to write code of authorization in the resolver. What I missing here.

-1

You've identified an important consideration when using AWS AppSync with Lambda authorization and caching. The behavior you're experiencing is indeed a limitation of the default caching mechanism, which uses the API ID and token as the cache key. This can lead to unintended access to operations that should be restricted.

To address this issue without completely eliminating caching, you have a few options:

  1. Per-resolver caching: Instead of using full request caching, you can configure per-resolver caching. This allows you to have more granular control over what gets cached and how. You can explicitly opt-in specific resolvers for caching and define custom cache keys that include operation-specific information.

  2. Custom cache keys: When using per-resolver caching, you can define custom cache keys that include not just the token and API ID, but also operation-specific information. This could include the operation name, arguments, or other relevant data from the request. By doing this, you ensure that the cache entry is specific to each operation.

  3. Shorter cache TTL: You can reduce the time-to-live (TTL) for cached entries. This won't solve the problem entirely, but it will reduce the window of potential unauthorized access.

  4. Dynamic cache eviction: In your Lambda authorizer, you can use the evictFromApiCache extension utility to remove specific entries from the cache when necessary. This allows you to invalidate cache entries when you detect that they may lead to unauthorized access.

  5. Operation-specific authorization logic: In your Lambda authorizer, you can include logic that considers the specific operation being requested, not just the token. This way, even if a cached response is returned, it will still contain operation-specific authorization information.

It's worth noting that your suggestion of using a hash of the token, API ID, and payload as the cache key is a valid approach and aligns with the concept of creating more specific cache keys. However, this isn't directly supported out-of-the-box by AppSync's caching mechanism.

To implement this level of granularity, you would need to use per-resolver caching and carefully construct your cache keys to include all relevant information for each operation. This might involve some additional complexity in your resolver logic, but it would provide the level of control you're looking for.

Remember that while caching can significantly improve performance, it's crucial to balance this with security requirements. In cases where fine-grained access control is critical, you might need to accept some performance trade-offs to ensure proper authorization for each operation.

Sources
Configuring server-side caching and API payload compression in AWS AppSync - AWS AppSync
LambdaAuthorizerConfig - AWS AppSync
ApiCache - AWS AppSync
AwsAppSyncGraphQlApiLambdaAuthorizerConfigDetails - AWS Security Hub

profile picture
answered a month ago
  • The thing is that resolver caching is not the same as lambda authorization caching

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions