API Gateway usage plans and principal_id
I have an API that utilizes a custom authorizer. This authorizer handles both authentication and authorization for my users, drawing on data from my database.
I'm aiming to set up two distinct usage plans and want to allocate users between them. My objective is to throttle users individually, either limiting them to 100 or 10,000 requests per second.
From my current understanding, I believe I need to programmatically generate a unique API key for every user and then link this key with their credentials. Subsequently, my custom authorizer can forward this using the usage_identifier_key.
For every invocation of the custom authorizer, I would have to check if a user already possesses an associated key and if this key matches the correct usage plan. If there are any discrepancies, I'd have to either remove the existing key, generate a new one, or extract the value from the correct key, among other potential actions.
Another aspect I'm concerned about is the lack of key expiration. If I've created a key for a user and that user is later removed from my database, I'd have to handle this situation and ensure the key is invalidated or deleted.
This process seems somewhat intricate to me, particularly the part about managing the collection of keys and ensuring they align with my database. What I find puzzling is that the API Gateway already recognizes all my users through the principal_id provided by the custom authorizer.
Is the approach I've described truly the standard way to handle this, or might there be something I'm overlooking?
- Newest
- Most votes
- Most comments
When you configure a Lambda authorizer, you usually also configure TTL. This value is used to cache the response from the Lambda authorizer. This means that API Gateway will not invoke the function for each request. If the response is cached, it uses it, otherwise, it calls the authorizer again. This is usually the mechanism that is used to prevent deleted users from getting in. They will have access for a few more minutes and then the GW will invoke the authorizer again, which will not find the user in the DB, and the will reject it.
Same works for API Key. The authorizer returns a key, that is cached as well, and is used to throttle the users. The API Key should not change. It remains the same for the lifetime of the user.
Each user needs a single API Key. You should create those upfront, or create them on the fly when the user logs in for the first time. Save them in a DB and get it from there the next time they login. Assign those API keys to a usage plan, depending on their quota.
You use the same API key for all operations by that user. API Keys should not be used for auth, only for throttling.
Relevant content
- asked a month ago
- asked 10 months ago
AWS OFFICIALUpdated a year ago- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated 2 years ago
Thank you, Uri!
I get what you're saying completely. My main concern was how to handle situations where my API consumers' credentials are stored in an external database. To implement usage plans, it seems I have to manage a unique API Key for each user. Even though they could potentially be identified by the principal_id in Usage Plans.
Right now, every user account action (like create, update, or delete) needs manual adjustments in the API Key set, which feels very repetitive.
What's the purpose of the API Key then? If it's not advised to use it for authentication and I'm already using an external user database, why can't I just use that for the Usage plans?