AWS Builder Center is the official home for builders on AWS. Share and read what others are working on, follow people who inspire you, explore training and workshops, and find tools to support what you're building.
GetUser requiring aws.cognito.signin.user.admin scope
I want to look up a user from his access token. I asked a question about this about two years ago and was given a pretty good solution: pass the access token to GetUser and see if it comes back with a user. Worked great, and I haven't touched the app since.
Today I'm trying to replicate that for a different web app but I run into this problem:
An error occurred (NotAuthorizedException) when calling the GetUser operation: Access Token does not have required scopes
Whoop! The manual actually explains this:
Authorize this action with a signed-in user's access token. It must include the scope aws.cognito.signin.user.admin
but was that always the case? Is my app from 2 years ago (now deployed to a customer; I don't even have access to it) broken now?
It seems like when I want to call GetUser it should be using MY credentials to decide whether or not that's allowed, not the credentials belonging to the token I'm checking on. Something about this seems wrong in the process here. Was requiring this admin scope on the token itself always a requirement? I can't remember but really don't think my tokens from 2 years ago would have had that scope.
- Language
- English
asked 2 years ago1.4K views
- Newest
- Most votes
- Most comments
The requirement for the "aws.cognito.signin.user.admin" scope in the access token for the GetUser operation has been a long-standing feature of Amazon Cognito User Pools. This scope is specifically designed to authorize self-service operations for the current user in the Amazon Cognito user pools API, including operations like GetUser and UpdateUserAttributes.
It's important to note that this scope is automatically included in access tokens issued by Amazon Cognito when users authenticate through the user pools API. If your application from two years ago is still functioning correctly, it's likely because the tokens it's using already include this scope by default.
The "aws.cognito.signin.user.admin" scope is the only scope you receive in the access token when authenticating with the Amazon Cognito user pools API. It's also the only scope needed to read and write user attributes that you've authorized your app client to access.
Regarding your concern about using your own credentials instead of the token's credentials for the GetUser operation, it's worth noting that Amazon Cognito is designed to work this way for security reasons. The GetUser operation is meant to retrieve information about the currently authenticated user, so it makes sense to require the user's own token with the appropriate scope.
If you're developing a new application and encountering the "NotAuthorizedException" error, you might need to ensure that your authentication flow is correctly set up to request and receive tokens with the necessary scope. This could involve adjusting your app client settings in the Cognito User Pool or modifying your authentication requests to explicitly include the required scope.
It's also worth mentioning that if you need to perform operations on behalf of users without their tokens, there are other AWS APIs and methods available that use your application's credentials instead of user tokens. However, for user-specific operations like GetUser, using the user's own token with the correct scope is the expected and secure approach.
If you're concerned about your deployed application from two years ago, it would be advisable to verify its functionality. However, if it's still working correctly, it's likely that the tokens it's using already include the required scope.
Sources
Scopes, M2M, and APIs with resource servers - Amazon Cognito
GetUser - Amazon Cognito User Pools
Understanding the access token - Amazon Cognito
I am getting the tokens through the hosted (cognito provided) login page and a standard OIDC code grant authentication sequence, not through the API.
Hmm, the bot actually kind of answerd my question.