New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AWS-Amplify : Making Google account selector screen mandatory #4044
Comments
Hey @mdsadique2, Can you provide a bit more information about which framework (if any) and platform you are using for this? |
Sorry for not providing enough details, It is a React App which use AWS Amplify federatedSignIn feature to use google authentication |
@mdsadique2 thanks for the additional detail. I marked this as a feature request to evaluate with the team. |
@mdsadique2 Are you doing federation with the Cognito User Pool or the Cognito Identity Pool? If you are using the identity pool you can use the google api ('gapi'), which should allow you to force the select_account screen. I am not positive how the would be accomplished with Hosted UI. Update: This is actually not possible using the Cognito Hosted UI, but I have logged a ticket with the service team for their backlog. If you are doing federation with the identity pool, then it should possible by following the instructions in the docs linked to above. |
Semi-related, but is there a specific way to sign out a user authenticated via a social IdP, such that the next time they attempt to sign-in with that IdP, they aren't automatically signed in? It seems my app maintains some sort of authenticated state, even when local storage appears to be cleared on sign out. When I sign back in, I can't even trigger a pre- or post-authentication trigger. Possible related to #3933 |
semi-related: for those like me who spent a lot of time figuring how to force account selection: I am using
Note that |
@saadtazi, could you please clarify where exactly did you get |
The hack that @saadtazi posted about won't work if you use Cognito user pools because it bypasses the user pool and instead calls federation against the identity pool. You'll only have the Google JWT, and not the Cognito user pool JWTs. Here's the hack in question, and it's actually on amazon's docs under Identity Pool Federation. https://docs.amplify.aws/lib/auth/advanced/q/platform/js/#google-sign-in-react The code in question is
The My research has come up with nothing in terms of how to exchange the Google JWT directly for a Cognito User Pool JWT. You can further find the same question here: |
I still got the same issue here which cannot select the account once signed in. Any update? Also found some related issue closed but don't have the way to resolve yet #4720 |
I can't believe it's been three years and nobody on the Cognito/Amplify team has addressed this 👎. Please, guys. All we need is the ability to set |
We're moving to FusionAuth after evaluating our use-cases against around 10+ other providers (including Auth0, which was our original first choice when doing the evaluations - what didn't work for us is they had a limit on IdPs you can provision; we are a SaSS product that have orgs that want to do multiple SAML SSO integrations, so we can't have such limits). This isn't the only hack we've had to do with Cognito. The FusionAuth APIs have covered all our needs without all the hacks that Cognito has required. |
We are facing a similar issue with Amplify-iOS. Not being able to select a specific google account has caused a really bad user experience that we now are considering moving to other providers. As @theogravity stated above, this isn't the only hack we had to do with Cognito as well. |
Thanks @theogravity. I'll definitely be checking out FusionAuth. |
Has there really been no word on this? It's becoming a dealbreaker for us as well. |
Hi @ebk46 - unfortunately, there is still a limitation on this from the Amazon Cognito service. We have communicated this limitation to their team, and we will update this issue when a solution is in place. |
Any updates? I am still facing the same problem, too |
Same problem still exists in 2022! |
We just transitioned to FusionAuth after a few months of work. I can say there has been no hacks required compared to the multitude of hacks Cognito needed to get basic functionality to work. It was surprisingly a smooth process, and will never recommend anyone use Cognito. They don't care about it's users at all. |
I don't know about FusionAuth but Google Identity Platform from Google Cloud works exactly like Cognito but it does not have those limitations (they even have the same interesting free-tier) I might migrate to it at some point. |
A basic feature still is not supported in 2023. If we use AWS Cognito to implement login with Google, it leads to a bad UX because users can not select which Google account to login. If someone are still looking for a solution for it, it highly recommend using service from GCP instead of AWS Cognito. |
@ArduinoGetStarted what is the name of the service from GCP that is equivalent to Cognito? |
The way around this is to use Google as an OpenID authentication provider for your user pool in Cognito. I have just written a solution for this problem on stack over flow Here is the link https://stackoverflow.com/a/75291833/13889098 |
I guess the even better idea might be to implement critical feature within the reasonable timeline as well as communicate to your customers why its still not implemented. I don't know what was in the deleted post but man... waiting for 5 years for a simple but crucial feature... There are so many bad words in my mind towards cognito team... |
Is there any news on this? The communication with service team is ongoing since April, when can we expect at least news about possible dates? |
We had an incident again with a customer stuck in the wrong account session. We're about to stop using amplify/auth, because this is really frustrating... |
If you have bad words in my mind towards cognito team, do not say it, keep it secretly. If not, your comment will be deleted. That team may be happy if you praise them instead of poiting out something that can make their product better. |
Hello everyone, unfortunately - we still do not have a specific timeline to communicate on when this feature can be available. The Cognito team is aware of this limitation, and we will provide an update when we have made more progress. |
This issue wasn't an issue for me until now, and now that I need to choose the account this is a critical oversight. Seems like it should be a simple fix but very disappointing to see that this has gone unaddressed |
Also having the same problem as most of the people here, it is really frustrating how this hasn't been yet addressed. |
Just stumbled upon this. Why am i not surprised that this crucial issue has been open for more than 4 years and unaddressed. Both cognito and amplify are half-baked products, i hope people realize this and stop wasting their time on these broken technologies. |
It really does seem like such an easy thing to change. I imagine if it can't be exposed as an option, setting it as a default seems reasonable and imo not too intrusive. For those with users who get stuck in the wrong account, the only workaround I can think of is asking them to revoke OAuth permissions for your app. This should prompt them to re-authorize when logging in.
Unfortunately I believe this will deactivate any existing access tokens, so any integrations the user set up are probably broken. If you're just using OAuth to support the google login then you should be fine, but if you're requesting additional scopes for things like Drive, Calendar, etc. then be aware existing tokens are probably invalid. Edit: You could also suggest to the user to use different browser profiles. Not supported in every browser, and you shouldn't expect a user to have to change their workflow, but something to help them continue using your app. |
Adding in that this is a very needed "feature". This simply is feature parity with other Google Sign In flows. Expecting a user to log out of a browser or use different profiles for just our app is unreasonable overhead that I just heard back from product is a definitive no on. (I agree with this decision). PLEASE fix this AWS-Amplify team OR provide for us a single endpoint that we can hit in our Cognito domain to log them out of their session in our system. |
I'm done with cognito. After all the workarounds involving lambda triggers and confusing documentation, this is the straw that broke the camel's back. This is such an important feature that other auth providers have solved and the cognito team can't even provide an update on what's going on. I can't believe how many hours I've spent configuring my cognito setup, just having to give it up because of this. |
@Wigglor I am migrating my whole system to another auth provider too |
@ambrosdavid Which provider are you looking at? I'm thinking Auth0 atm, but might reconsider. |
We may have to do this too, so anything you all can recommend or guides
would be great! Especially in regards to how to handle the link between end
user and AWS IAM roles/permissions mapping.
I just stumbled upon this problem as I thought I was finished with Amplify
V4->V6 upgrade and adding Google Sign In. But now thinking I may really
need to try and figure out how to quickly migrate to another option....
…On Sun, Jan 28, 2024, 1:05 PM Wigglor ***@***.***> wrote:
@ambrosdavid <https://github.com/ambrosdavid> Which provider are you
looking at? I'm thinking Auth0 atm, but might reconsider.
—
Reply to this email directly, view it on GitHub
<#4044 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJCJJ3BPBNCPHY4TCSAKAXLYQ2VRFAVCNFSM4IYNO7J2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGM3TANRZGIZQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Will probably go with stytch |
I've been disappointed that this has been such an issue, but I see Auth0 can be a federated provider for cognito/amplify, would this be a possible workaround in your estimation? @Wigglor |
Try SuperTokens It's an open source library and can be installed on-prem or on server. Seems pretty promising. |
@pjsandwich Hmm, might be worth looking into. Looks like I should be able to add a user to the user pool via lambda triggers. I'll look into it. Thank you! @wac-eric Seems legit. Usually a bit scared when it comes to new auth services, but since they allow own server as well and the on-prem pricing looks much more predictable compared to auth0, this might be a real alternative 👍 |
I ended up migrating to Auth0 as someone suggested (instead of stytch). I am using Angular + AppSync + Amplify to some extent (Just to handle the authentication and graphql query generation). Will write a medium post on how I did it, maybe it will be helpful to someone. |
Log out and redirect user to clienthttps://docs.aws.amazon.com/cognito/latest/developerguide/logout-endpoint.html GET https://mydomain.auth.us-east-1.amazoncognito.com/logout?client_id=1example23456789&logout_uri=https%3A%2F%2Fwww.example.com%2Fwelcome |
Elaborating on this solution: a simple get request from a browser based application would actually result in a CORS issue. Instead, a working solution, though still a hacky one, would be to use Specs: Firefox: v123 Example:
Note: I haven't checked some of AWS-Amplify's latest updates nor have I used browserstack to check with windows and other browsers such as IE. |
Anything update on aws-amplify v6 ? |
@rryoung98 this your solution works fine with google or amazon account - using amplify v6 (but on incognito mode, it not work) |
So I have implemented Google authentication by using AWS Amplify (federatedSignIn) in my React app. Apparently, I want to make the google account selector screen mandatory for the user to select an account to log in. Apparently, it works only when multiple google accounts are available to choose from, but if there is only one account, the system automatically uses it to login?
How can I enforce the selection screen with only one account?
The text was updated successfully, but these errors were encountered: