Open hanslai opened 5 years ago
My annoying work around is to use AWS SDK GetUserCommand when the user only has the aws.cognito.signin.user.admin
scope, and to use the oauth userinfo endpoint otherwise. Users logging in with social have the scopes needed for the userinfo endpoint, and users who did a direct signup, logging in with the custom sign-in form, do not.
Hello! Any status update on this? Is there any workaround?
We just made big refactoring in backend to support custom scopes and after that we realised that our apps made with amplify wouldn't work with it anymore. This is frustrating situation.
We gave up on Amplify/Cognito. We've tried on multiple occasions to find a way to make it viable with different projects and, ultimately, this is the main issue that keeps us from using it. This thread is 5 years old and still active yet I haven't seen any indication that the team has any plans of fixing this.
Beyond that, they should not advertise this product as a feature-complete authentication service because it isn't. More and more teams are committing to using this product only to realize it doesn't do as advertised after the build out their applications to it. What a let down.
We gave up on Amplify/Cognito. We've tried on multiple occasions to find a way to make it viable with different projects and, ultimately, this is the main issue that keeps us from using it. This thread is 5 years old and still active yet I haven't seen any indication that the team has any plans of fixing this.
Beyond that, they should not advertise this product as a feature-complete authentication service because it isn't. More and more teams are committing to using this product only to realize it doesn't do as advertised after the build out their applications to it. What a let down.
They fixed it December last year https://aws.amazon.com/about-aws/whats-new/2023/12/amazon-cognito-user-pools-customize-access-tokens/ @apekkar
@Meags27 thanks for the link and clarification. Unfortunately, as @DavidWells mentioned in his comment, you must enable advanced security features in order to use this which drastically increases the cost and contains a lot of features we do not need. This decision means that this product will continue to not be viable for our team.
Is there any update on this? the solution as mentioned by multiple users involves a crazy diference in cost per user which I find unaceptable and unviable, however I apreciate that at least there was something made about this issue however is far form the ideal solution
Enabling advanced security features for this simple feature sounds crazy. I would appreciate it if the Cognito team could look at this request.
We're in the same boat. After reading this, we are landing where many of you have already. The markup per MAU is way too expensive to justify access token customization.
What's funny is I don't even want customization. I want the scopes that are setup on the user pool app client to simply be on the access token. That's not customization, that feels more like "the way it should work".
For now we are choosing to not use authorization scopes until we can move away from the Amplify JS libraries.
Any update here? It's insane that this still continues to be an issue.
One day you decide to become a certified AWS expert... you spend a lot of time and money to achieve that. Once certified, you share your joy with all your friends and clients. You dream about modern cloud solutions with super cool architectures. You think you know everything needed to build a cool solution, not only because of fancy marketing words - you think you know this platform.
And then... then you see such sh## like this... when a super obvious thing is not working and no one plans to fix it (only 3 years passed from the initial post). I was really disappointed when I noticed almost zero customization of the hosted UI. But this... this is just ridiculous.
Now I'm at a point where I regret the decision to use Cognito because it's a real blocker for us. I have to step back and re-architect the system to use a more bullet-proof solution than Cognito.
So... 2 years have passed, and we still need an adequate solution (the new bill multiplier feature is not an option). The good thing is that I have this thread pinned, and now I can make the right decision not to use Cognito at the beginning of the new project :D
This is really bullshit coming from AWS. This is just an example of a simple thing that never can be done right. I am also stuck now thinking what to do next. In the pre trigger lambda, it is defining its own custom scopes and bypassing the Resource Server?
First i had issues with Cognito requiring saml 2.0 redirect binding and the idp i need to add only supports POST Now the access token does not have the required info to be able to easily get the users email address (how we id users) I gave up and im now just using the Id Token.
Next time im just going to use keycloak
Which Category is your question related to? Cognito, Oauth2/OIDC Access Token
What AWS Services are you utilizing? Cognito User Pool
Provide additional details e.g. code snippets Using either Auth.signIn or the Vue Authentication Components are not able to get any OAuth or Custom Scopes.
Sorry, I only have a image of the source my coworker sent me.
I also tested, I was able to get the OAuth scopes if I use the Token Endpoint in Postman https://docs.aws.amazon.com/cognito/latest/developerguide/token-endpoint.html
Or do we have to use https://github.com/aws/amazon-cognito-auth-js to get the scopes? But with Amplify I wonder do we still need to use this amazon-cognito-auth-js library? Actually, I am confused why there are two JS libraries for cognito.
both #1884 and #1370 have the same problem, which is not solved but closed. It has been almost a year on this issues already. Any update on this?