By using AWS re:Post, you agree to the Terms of Use

Restrict access to the users in groups via scope in cognito user pool

1

Assume I have a resource service defined in cognito user pool which has 5 scopes. There are 2 set of user groups - admin and users. Admin group will have access to all the scopes in the resource server. But I want to restrict certain scopes to users group. Can we able to achieve this in cognito user pool ? I can see the scopes assigned to the resource server, but i could not able to find the way to restrict to group of users. Any leads on this will be super helpful.

asked 9 months ago855 views
2 Answers
2
Accepted Answer

Hello,

Firstly, I would like to mention that a scope is a level of access that an app can request to a resource. The scopes are not based on individual users, groups etc, rather they are defined on an app-level.

https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-define-resource-servers.html

For example if you have a resource server for photos, it might define two scopes: one for read access to the photos and one for write/delete access. When the app makes an API call to request access and passes an access token, the token will have one or more scopes embedded inside of it.

Secondly, coming to an app itself, an app/app-client (these two terms are used interchangeably) is an entity within a user pool that has permission to call unauthenticated API operations. You can create multiple apps for a user pool. Typically, an app corresponds to the platform of an app. For example, you might create an app for a server-side application, a different Android app and a different iOS app etc. Each app has its own app client ID.

https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-client-apps.html

It is in the app client settings, where you define what scopes are allowed. For example - read_product, delete_product etc.

https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-app-settings.html

Now, say for example, if a user only had access to your Android platform (android app client) and that app client had only read_product scope allowed in app client settings. Then the User accessing this Android platform (app client) can only get an access token which has the scope read_product allowed. Hence, thereby restricting their access to only the read access to the resource server. Where as you could have another platform (another app client under the same Cognito Userpool) which allows all scopes of the resource server.

Hence, to reiterate, scope is a level of access that an app can request to a resource. It all comes down to the developer to decide what platform (app client) has what scopes allowed (that one will get in access token), and which base of users get the access to which specific platforms (app clients) to exercise the granular restricted access. Please note, that each app client has its own unique ID, hence you can differentiate the app clients/platforms from each other even when they are found to be under the same Cognito Userpool.

Now coming to your query -

"Admin group will have access to all the scopes in the resource server."

This is only true when the app client settings for the specific platform (app client) accessed by the Admin group Users has all the scopes allowed in configuration.

"But I want to restrict certain scopes to users group."

Currently the scope configuration for Cognito is based on app client/platforms not on individual/group level. The end user (on successful authentication) gets the access token vended for the specific platform/app client in consideration to what scopes were actually allowed for that platform/app client.

You should be providing the Admin's platform (app client) access to the Admin Users, while providing a separate platform (another app client under the same cognito userpool) with less permissive allowed scopes access to the other group's Users.

"Can we able to achieve this in cognito user pool ?"

You can create your own OAuth2.0 resource servers, and define custom scopes within them. Custom scopes can then be associated with an app client, and the app client can request those scopes in OAuth2.0 authorization code grant flow, implicit flow, and client credentials flow. Finally, the end user accesses these app clients/platforms which are defined with what scopes they are actually allowed. So the association of scope is on the app-client/platform level with which the end users interact with at the end of the day.

Finally, one last note, all of the above discussed information touches upon the multi tenancy application practices which are mentioned in details here for your reference -

Multi-tenant application best practices - https://docs.aws.amazon.com/cognito/latest/developerguide/multi-tenant-application-best-practices.html

App Client based multi tenancy specifically can be found here - https://docs.aws.amazon.com/cognito/latest/developerguide/application-client-based-multi-tenancy.html

profile picture
SUPPORT ENGINEER
answered 9 months ago
0

You could implement your own authorization service and call it with the Pre token generation Lambda trigger:

https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-pre-token-generation.html

You can use this AWS Lambda trigger to customize an identity token before Amazon Cognito generates it. You can use this trigger to add new claims, update claims, or suppress claims in the identity token.

answered 2 months ago

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