Cognito authorization with two user pool

Question

I have an API Gateway and two user pools, I want to implement Cognito on my endpoints supporting both user pools. The idea I had was to create a lambda authorize which takes as input: the access_token and does a get on /oauth2/userInfo of the two user pools, knowing that the request will only be satisfactory for only one user pool if the token is valid. And my lambda returned

1. For Get Ok -> "Effect": "Allow",
2. For Get Ko -> "Effect": "Deny"

like explain here:link

Questions

• Is there another way to support authorization on two pools?
• Is it normal to manage authorizations with access_token?
• In case my lambda took as input the id_token instead of the access_token how can I verify that the id_token has been generated by one of my user pool

Thank you !

Answer 1

STANDARD BEHAVIOUR

There should be a single Authorization Server (AS) that your apps talk to. Partitioning users can be done for advanced purposes, such as multi-tenancy or storing Personally Identifiable Information (PII) in different databases per region.

Q1

A Cognito user pool is an entire Authorization Server - I would aim to use only one if possible, since this will keep the code in your apps simple.

If you have to proceed with a single app using multiple user pools, aim to get the API client to send you a hint that enables you to know which one is being used - perhaps via a value in a custom header during API requests:

• x-mycompany-user-region: EU
• x-mycompany-partner-id: ABC

This will enable you to implement a basic kind of content based routing. This type of header is only for routing and should be ot be used for security.

It is also possible to put a reverse proxy in front of Cognito to do this type of job - see this Curity article for details on this type of approach, where claims are used to route requests.

Q2

Yes - use access tokens containing or referencing scopes and claims. Note that Cognito may not allow you to customize access token JWT contents.

A way to get custom claims can be to send the access token to the user info endpoint, then cache results in the authorizer, as you seem to be doing. If it helps, see also this code of mine.

Q3

An ID token is a digitally verifiable assertion given to a UI as proof of authentication. It should not be used for authorization in APIs. It may be that Cognito has better support for customizing ID tokens - but it is not correct in OAuth terms (eg expiry is too long / no support for scopes).