Modify AccessToken via cognito trigger

[jacintoArias]

** Which Category is your question related to? **

Authentication

** What AWS Services are you utilizing? **

Cognito, Lambda

** Provide additional details e.g. code snippets **

This issue is just to confirm that this can be done, or to ask for a different strategy.

We are using federated signin to allow a code_grant OAuth flow using the Cognito Hosted UI and everything works great.

We have a custom authorizer in API Gateway that uses access tokens included in the authorization header of the requests as a bearer token. We were wondering if we could include custom information (e.g. additional scopes) or modify existing information (remove existing scopes) at token generation in cognito by using a lambda trigger.

We are succesfully managing two lambda triggers, one for pre-autentication and another one for pre-token-generation to perform some identity logic for our users and customize the idtokens, however we have not found how to modify the access tokens in the same way.

I am starting to think that this cannot be done, however I would just like to confirm if there is any workaround to modify the access token before sending it to the user.

[dienomb]

Would be awesome to know if someone manage to do it??

[dbly]

We are also stuck with this.

It is beyond me that there is no lambda trigger for overriding acess token claims and I am gutted that we have chosen Cognito!

It has been an absolute abysmal product to work with and it is a waste of time in every regard.

[ajenkins-cargometrics]

It seems there really is no way to do this through lambda triggers. The only way that Cognito seems to provide for controlling which scopes are granted to an access token is by creating different app clients with different sets of scopes enabled.

So for instance you could create an admin app client and normal-user app client for the same user pool. Then your app would need to have different sign-in URLs for admin and normal users that use the correct client.

You could make it so only users who are in the Admin group can sign in via the admin app client by using a pre token generation trigger.

This doesn't seem like a great solution though because it would be preferable to not make admin users sign in using a different URL. Plus this scheme wouldn't scale if you needed more permission levels than just admin and normal users. It seems we're stuck with using id tokens with custom auth based on Cognito group membership if we want per-user permissions.

[speed-of-light]

hi I'm also stuck on this, after seeking a lot of documentations, blog posts from aws there seems no official way to do it programmatically. The only way I observed is when user try to login with Authorization code grant process, it first redirect user to the hosted UI, and after hit submit, it will try to post the data to [your domain]/login and the scope may hence get.

However in the amazon-cognito-identity-js package, it calls cognitoUser.authenticateUser and under the hood it calls the initiateAuth and I don't see any where it could accept a scope as parameters.

[elorzafe]

@jacintoArias

According to this guide pre-token-generation trigger is for identity tokens.

In this other document You can add custom scopes that can be use on API Gateway authorizers.

[alph486]

@elorzafe I think what the OP is asking for is to customize what the identity server is providing in the access tokens without necessitating multiple APP CLIENTs.

I also have run into this and don't see an OOTB way to customize scopes. it's unfortunate.

[jfazzini]

Hello @elorzafe,
Can you please let us know if this feature is in the Cognito roadmap? Sadly I'm in the same boat. Having a trigger similar to pre-token-generation and use it to implement a lambda function for adding claims to the access token will solve this issue.

[jgcoding]

Ditto here. I convinced my product owner to allow me to migrate their auth from Auth0 to Cognito. I have lost a day scouring for a solution. I started with what should be the easiest and most seamless transition, migrating the Auth0 machine-to-machine solution.

Auth0 not only returns all 3 token types, it provides easy to implement "Rules" and "Hooks" to enrich tokens as fully as one dares.

Do any other the other triggers allow for token enrichment of any kind for an accessToken?
As I see it, 3 alternatives exist:

• choose a work-around within a trigger to retrieve the information with which to enrich the token (triggers don't respond to access-tokens apparently)
• implement a custom authorizer to man-handle the enrichment process
• abandon the Auth->Cognito migration before I waste any more time and discover even more shocking limitations

Any ideas?

JG

[ajenkins-cargometrics]

@jgcoding Cognito only lets you modify identity tokens in triggers, not access tokens. If you really need to enrich access tokens in a trigger you should probably stick with Auth0. That said, for machine-to-machine authentication I'm not sure why modifying the access token in a trigger would be necessary. Usually when I've seen this need come up it's with user authentication, when you might want to grant different sets of scopes to different users. For machine-to-machine auth, there's no concept of a user, so I would think either auth succeeds or it doesn't.

In Cognito you can control which set of scopes are in an access token through App Clients. In a single user pool, you can create multiple App Clients for machine-to-machine auth, each with a different set of standard and custom scopes. Then you could have different apps use different app clients for authentication depending on which set of permissions they're supposed to have. From what I can tell this is Cognito's intended way of configuring scopes. Maybe someone from the Cognito team can confirm or differ, but my impression is that they assume that for user authentication, you'd mainly use identity tokens, or the IAM role mapping features, for implementing per-user permissions.

For our use cases, we've been fine with using identity tokens and Cognito groups. Our apps can check the cognito:groups property of identity tokens to see which groups a user is in, and use that in a similar way to how scopes would be used with access tokens to implement fine-grained permissions.

[mararrdeveloper]

@jgcoding Cognito only lets you modify identity tokens in triggers, not access tokens. If you really need to enrich access tokens in a trigger you should probably stick with Auth0. That said, for machine-to-machine authentication I'm not sure why modifying the access token in a trigger would be necessary. Usually when I've seen this need come up it's with user authentication, when you might want to grant different sets of scopes to different users. For machine-to-machine auth, there's no concept of a user, so I would think either auth succeeds or it doesn't.

In Cognito you can control which set of scopes are in an access token through App Clients. In a single user pool, you can create multiple App Clients for machine-to-machine auth, each with a different set of standard and custom scopes. Then you could have different apps use different app clients for authentication depending on which set of permissions they're supposed to have. From what I can tell this is Cognito's intended way of configuring scopes. Maybe someone from the Cognito team can confirm or differ, but my impression is that they assume that for user authentication, you'd mainly use identity tokens, or the IAM role mapping features, for implementing per-user permissions.

For our use cases, we've been fine with using identity tokens and Cognito groups. Our apps can check the cognito:groups property of identity tokens to see which groups a user is in, and use that in a similar way to how scopes would be used with access tokens to implement fine-grained permissions.

I will reply to that.
In my use case, I need to encode the aws gateway api key into the M2M access token.
The idea is that each (third party) application has specific grants to access resources and that's obtained through the custom scopes. However, each application has also a quota limit that is tracked with the gateway api key.
Without trigger on access token creation I am not able to include the APIkey as part of the access token payload, hence I cannot have the API key on my custom lambda authorizer.
Of course I can implent the logic in the authorizer, but running this logic on every call is not sustainable (not without a proper cache strategy at least)

[harrysolovay]

Like @elorzafe mentioned...

pre-token-generation trigger is for identity tokens.

Customizing the token / claims is doable, but it's not within the scope of AmplifyJS (the front-end client). You'll need to build the token generation trigger yourself.

This guide and this guide should do the trick––they'll walk you through the code to update the token and the CLI commands to deploy the code respectively.

[ajenkins-cargometrics]

Regarding your explanation for closing the issue, I agree that this issue is outside the scope of AmplifyJS and should be closed. I wanted to point out though that the links you provided do not offer a solution to this issue. The issue was asking about customizing access tokens, whereas the links you provided show how to customize identity tokens. Cognito does not AFAIK provide any way to customize access tokens via triggers.

[github-actions]

This issue has been automatically locked since there hasn't been any recent activity after it was closed. Please open a new issue for related bugs.

Looking for a help forum? We recommend joining the Amplify Community Discord server *-help channels or Discussions for those types of questions.