AWS: Authorize users to specific clients

Question

So I have the following setup on AWS Cognito:

AWS Cognito User Pool: UserPool_1

Under this User Pool I have 3 users defined: Mike, Sarah, John

I have 3 App Clients under thhis user pool:

WebClient_1

WebClient_2

WebClient_3

I want Mike to be able to access: WebClient_1, WebClient_2, and WebClient_3

I want Sarah to have access only to: WebClient_3

And John to have access only to WebClient_2

Currently all users are able to access all 3 web apps defined under this user pool, that's not what I want.

How do I restrict users in the user pool to have access to specific app clients?

So let's say Sarah tries to access WebClient_1, I want her to get a message saying: "User not authorized"

How do I achieve this?

Answer 1

The way I would solve this is with the Cognito Pre Authentication Lambda. When a user requests authentication, the Cognito trigger runs a custom Lambda script. In your Lambda script you will receive an event with some common parameters. You can take the parameters callerContext.clientId and userName and do some processing. For a few users you could just keep the user-client mapping in the script, but more likely you will want to look up the mapping in a database like DynamoDB.

Edit: To accept the authentication you do callback(null, event); and to reject it you do callback("you are not coming in", null);

Answer 2

I was able to solve this by utilising multiple pieces:

• User Migration Trigger
• Pre Authentication Trigger

Attempting to utilise just the Pre-Authentication trigger results in an incomplete and insecure solution. The trigger only runs when a user attempts to authenticate against the user pool. This means that after a user has been authenticated for an app client they have permissions for, given the URL for any other app client, the user will be able to access it.

As a workaround, I decided to go for a different setup where I have a separate user pool for each app client and one general pool to store all my users. This obviously can get annoying when it comes to creating the same accounts in each user pool, so I mitigated that by using a migration trigger.

For example, on Sarah's first sign-in attempt to WebClient3, the migration trigger runs and imports her data to the new user pool while also preserving her password. You can combine the functionality for the pre-authentication trigger into the migration trigger such that if a user shouldn't have access to that app client then the migration fails.

A caveat here is that if the user is created by an admin with a temporary password, then they would need to first reset the password using the first pool's client before the migration can work. Also, after the migration process, the user's account is now independent of the general pool which may lead to inconsistencies if not managed properly.