Custom scopes in access token programmatically

[rscmendes]

Describe the bug Impossible to get access tokens with custom scopes without using the hosted web ui. Authentication through the amplify drop-in UI for both Android and iOS -- used in the android-sdk-auth example -- or through cognito auth sdk always returns (the single scope) aws.cognito.signin.user.admin even if it is disabled on the app client settings.

To Reproduce Steps to reproduce the behavior: 1.Follow the android (or iOS)-sdk-auth example;

2. Create custom scope and enable on app client settings;
3. Sign-in in the app, grab the access token and check the scopes in jwt.io

Which AWS service(s) are affected? AWS Cognito (in all SDKs) and AWS API Gateway

Expected behavior Access token should return custom scope(s), regardless of using the web ui.

Screenshots

Environment(please complete the following information):

• Latest SDK versions (of both cognitoauth, mobileclient and auth-ui)

Device Information (please complete the following information):

• We tested on both iOS and Android default simulators, although we believe that this happens with any device.
  • iOS 11.3 and Android API level 28.

Additional context Our use case: We have native apps (both Android and iOS) trying to authenticate end-users in a user pool. Our API Gateway resources are scoped (none including aws.cognito.signin.user.admin scope). We want to use implicit grant as we don't want to distribute the application with the client secret in its package as that would be stored in plain text. We'd rather not use the hosted web ui for improved user experience, specially since everything we have is native. We do understand the implications of not using the web ui, as well as not using the authorization code flow. Thus, the solution would be to use the cognito auth sdk, which we believe that it doesn't support implicit grant.

We might be approaching this the wrong way, any guidance would also be highly appreciated.

Unsolved related issues throughout the different SDKs:

[Amplify JS] - Access Token does not have required scopes (Http - 400)

[Amplify JS] - How do I use amazon-cognito-identity-js to get scopes in the access_token?

[Amplify iOS] - Feature Request: Cognito "InitiaateAuth" request allowed custom "scopes" in AccessToken

[Amplify Android] - Feature Request: Cognito "InitiateAuth" request allowed custom "scopes" in AccessToken

[rohandubal]

Hello @bluetrickpt

Currently, specifying custom scopes is only supported via the Oauth client (Cognito Auth SDK) as you have mentioned above. It is not possible to to request custom scopes using the API flow.

I will take this as a feature request to the service team.

Thanks, Rohan

[fcouceiro]

Any updates on this?

[spectorar]

Agree that this would be a really useful feature. My team has a use case that requires us to implement a custom auth flow and without being able to have scopes (both built in and custom) in the token we may have to look up the scopes on the app client's resource server at each authorization with a custom auth trigger to verify that the app client has access. Even with that implementation, we can't issues tokens that have are limited to a subset of the allowed scopes.

[minbi]

Hi all,

We don't have an update on this issue, but we are communicating your requests to the service team.

[uherberg]

This would be very helpful. Is there any plan to address this soon?

[JaysonSunshine]

Hey, Amplify

We too have run into this issue. It's very useful to have custom scopes so that we can have fine-grained Cognito authorizers on our API Gateway resource. Any update would be great. :)

-Jay

[qwertynature]

Any update on this?

[cristian-stoichin]

Anything?

[hasbisevinc]

Any update?

[uokitomer]

Any updates?

[karlkilgi]

Any updates on this? @minbi @rohandubal

[juanto121]

Updates would be much appreciated.

[ebaychannel]

Any updates?

[gauravchaddha]

Any Update?

[pcashdown-tu]

Any update on this?

[pmargom]

Please, give any update about this feature.

[rupertlssmith]

Also looking for an update on this.

[cristian-stoichin]

Come on AWS, at least throw us a bone here...

[sandeepsdixit]

Need this badly

[jacogreyling]

Ditto. Any update will be greatly appreciated. Alternatively if we need to 'vote' for this feature please let us know so we can raise awareness through the product owner's radar.

[sandeepsdixit]

For now I am adding aws.cognito.signin.user.admin to custom authorizer / oauth scopes. Not a great choice but has allowed me to move forward while still using access tokens...

[ittijindaniSN]

Looking from someone in the Cognito team to provide an update. The request for custom scope has been pending for almost an year.

[DavidWells]

I am running into this issue as well. I thought pretoken lambda could customize this for me but it only effects the idToken https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-pre-token-generation.html

Any help would be much appreciated. Thank you!

Related issue here: https://github.com/aws-amplify/amplify-js/issues/3732#issuecomment-603093351

[TrekSoft]

Thanks for the update DavidWells - just so y'all know this is on our radar as a high priority issue to investigate and is next in queue to be picked up.

[TrekSoft]

Heads up that I've begun investigating this and will keep you posted as I make progress amongst other work.

[philippeback]

Same issue here, very annoying for the API Gateway.

[TrekSoft]

Quick update that this is temporarily on hold during a big release push internally but is still my top issue to return to once we get our launch done. In the meantime, if people could give specific examples of why they need the ability to customize the scope on this token, that would be very helpful.

[cristian-stoichin]

@TrekSoft the reason would be because we want to use the oAuth benefits without having to use the Hosted UI. We want to be able to truly use the scopes so we can control access to our api's based on those scopes, otherwise we end up with our own implementation of oAuth and only use Cognito as a user data store.

[rupertlssmith]

@TrekSoft The hosted UI is limited and awkward to customize. I'd rather be able to do auth against the AWS Cognito API, but through my own UI. Want to be able to use the custom scopes defined in Cognito to control access to the remainder of an application.

[DavidWells]

I agree with @rupertlssmith & @cristian-stoichin

For my specific use case, we need to customize these scopes to allow access to specific endpoints in API gateway v1.

I'm unable to alter these scopes when users log in via my apps UI and API gateway v1 (REST) will not accept the id_token with custom scopes, only the access_token

For example, I can't do this with scope my-app/read because the access_token is stuck with aws.cognito.signin.user.admin

# serverless.yml
functions:
  create:
    handler: posts.create
    events:
      - http:
          path: posts/create
          method: post
          authorizer:
            arn: arn:aws:cognito-idp:us-east-1:xxx:userpool/us-east-1_ZZZ
            scopes:
               # unable to get this working b/c only "aws.cognito.signin.user.admin" set in the token
              - my-app/read

This is described here as well

The only way to alter scopes in the access_token is to have the user login via the AWS hosted UI outside of the application flow. Using the hosted UI is not acceptable for the project.

[jollifft]

Somewhat different use case here, but similar to what @DavidWells is describing:

In our specific setup, we allow users to sign in via our enterprise OIDC provider (through the User Pool Federated Identity Providers section).

We have created custom scopes specific to our application, and would like to utilize the built in scope level authorization that API Gateway v1 provides when passing the access_token.

We are able to assign specific custom scopes to all enterprise employees who sign in through our OIDC provider. However, where this breaks down is when you need to assign specific custom scopes to different people within the same OIDC provider.

What we would like to do is before token generation, add/remove specific custom scopes to a user based off of a custom attribute coming from the third party OIDC provider. This would allow us to still use the built in scope based authorization logic using the access_token with API Gateway v1, while also adding more fine grain access control for different groups of people signing in through the same OIDC provider.

From what I can tell, this is very similar to how the Rules Feature of Cognito Identity Pools (Federated Identities) works. The difference would be we could authorize API calls using the standard OAuth2/OIDC token based approach, instead of needing to add the extra step of getting temporary credentials specific to AWS and signing our request prior to calling our API endpoints.

[LionelB5]

We are also impacted by this issue.

Very similar use case to @DavidWells . We have protected a few different API Gateway endpoints using different custom scopes and the only scope we ever get back when using AmplifyJS is the aws.cognito.signin.user.admin scope.

[TrekSoft]

Thanks for all the feedback! This will be super helpful in determining the best solution and I'll post back here once our release push is finished and I'm back on this issue.

[zedsinn]

@TrekSoft Will this be ported to the amplify-js SDK as well?

The use case for me is getting an OIDC token to pass to another service for oauth login against cognito.

[TrekSoft]

Yeah whatever solution we come up with we'll certainly want to roll out cross platform.

[TrekSoft]

Quick update that we released Amplify on Wednesday so I should be free to look into this again here. Expect an update from me within the next couple weeks on my findings.

[zedsinn]

Thanks @TrekSoft . Looking forward to it.

[jpignata]

Thanks all. We're working internally to figure out the best way to tackle this. This is our top feature request in this repo so it's top of mind. Please feel free to share your use cases here and +1 the issue.

[jsmpereira]

It seems the use cases presented are mostly in the context of users and the hosted UI.

I believe however that the underlying issue is more general and not exclusive to the context of amplify. It boils down to allowing the access_token to be modified, for example via a trigger (see related issue https://github.com/aws-amplify/amplify-js/issues/4015).

Providing something like a pre-token-generation trigger (used to modify the id_token) for the access_token would address any issues related to what is/should/shouldn't be in the access_token. How the authentication is being done (hosted UI or API) should be irrelevant. What the developer decides to put on the access_token is application specific and should just be there.

My particular use case is wanting to modify an access_token when executing the Client Credentials Grant. It doesn't involve users but it shows how this issue is indeed transversal to several contexts.

It makes sense that there is a trigger to modify the id_token, given the support for custom/additional claims (https://openid.net/specs/openid-connect-core-1_0.html#AdditionalClaims). However it makes even more sense to have one for the access_token since id_token is arguably more strict in it's structure (there's a spec for it: https://openid.net/specs/openid-connect-core-1_0.html#IDToken) while an OAuth2 access_token has no specific format or structure as per the OAuth2 spec (https://tools.ietf.org/html/rfc6749#section-1.4, https://tools.ietf.org/html/rfc6750) effectively making it application specific.

@jpignata @TrekSoft It seems to me that this is not an amplify issue but rather a cognito issue. Are you able to forward this to the "Cognito Team"?

[cristian-stoichin]

@jpignata

Any updates? Thank you.

[jpignata]

@cristian-stoichin No updates as of yet. Can you share your use-case if possible? Thanks!

[cristian-stoichin]

@cristian-stoichin No updates as of yet. Can you share your use-case if possible? Thanks!

Use the oAuth benefits without having to use the Hosted UI. We want to be able to truly use the scopes so we can control access to our api's based on those scopes, otherwise we end up with our own implementation of oAuth and only use Cognito as a user data store.

[jpignata]

@cristian-stoichin Ah thanks, missed that!

[cristian-stoichin]

Plus the ones also mentioned above, with regards to API Gateway and custom scopes.

[daslani-canopy]

This is a much needed feature for our team! It's the only way we can control our UI for localization and more customization. Thanks

[vishal62189]

We want our custom ui to have oAuth benefits without having to use the Hosted UI. We want to be able to truly use the scopes so we can control access to our api's based on those scopes Any Update will be useful @TrekSoft

[fredski02]

Any update on this?

[TrekSoft]

@jpignata is working with the Cognito team to figure out a way to provide a solution since this would involve a change on their end.

[InLoop-TOCA]

In our case we are moving from Identity server 3 to Cognito, we are having a set of apis that expect custom attributes in the access_token, now there will be a phase which we will have to use both Cognito and old identity server 3 in the same time (some clients will take longer to get in the new Cognito). So ideally we want to keep the access token exactly the same as possible, otherwise this will be a very big change and maybe it will be very hard to have both of them running together in the transition phase. So, in my opinion, it will be great to add another lambda trigger that enriches the Access_Token (in this case we will get the values from the database and add it to the token)

[matthias-pichler-warrify]

In our use case we provide services to retailers. We provide them with a web app where we would need to use custom scopes to handle permissions for API request.

Furthermore they can enter their credentials into their PoS (point of sale) system which then sends requests to our api on their behalf. For machine to machine authentication it is normally recommended to use the client_credentials grant type (as described here) due to the way this works in cognito (with App Clients) we can't use it here.

Hence we wanted to expose a token endpoint where the PoS system can use the password grant type, which also supports scopes, and use a lambda handler to acquire an access token with the specified scopes. We would use them for authentication for api calls again.