Closed davidgatti closed 4 years ago
Can you elaborate what issues you're having with Cognito? I'm quite far down the Cognito path and although it's difficult to work with sometimes, I've found that I can usually get things working the way I want. Auth is hard to do right and re-inventing the wheel sounds like a lot of work with lots of implementation details to get right.
Hi @cliffordh,
Sure, check the following Issue #3330, and follow the URL. And this is one thing, then if you check let say the Issue section of this repo for the past 30 days, you'll see an endless stream of issues. From something just not working at all, or something not being implemented following the security guide lines.
I also use AWS Teach Support to figure out issues, and with my private chats with them, I found out that even if you get the oAuth working with 3th party ISPs, the SDK they provide to handle oAuth wont create a valid user session for the main SDK to use. So you "login" but can't use the session for anything - and that is just plain broken.
Their excuse is to just use Amplify. The problem is that Amplify is build on top of the Cognito SDK they have here and this code doesn't work - meaning they building software on top of broken software.
On top of that, the simple function that should log out a user cognitoUser.signOut();
won't clear the browser storage, so if you have two users sharing the same browser, when the 2nd user logs in, the user won't get a valid session since the query to Cognito will fail.
You have to clear the storage yourself with localStorage.clear();
The global log out feature cognitoUser.globalSignOut();
never worked, from the beginning. How more basic than this can you be?
Around I think 6 months I discovered an issue where someone forgot to copy and paste some code in a class, and it took 2 weeks to fight with AWS Teach Support to make them acknowledge the problem is on their side and not mine, thankfully they fixed the issue quickly once they accepted the blame.
Sadly they'll blame you first and you have to spend weeks making videos, screenshots and giving them details to prove they have an issue. It is just exhausting, and basically you test their code, something that should not happen.
And I'm done doing this for free.
I implemented myself countless credentials system with oAuth for every social network out there + SAML 2.0 and SSO. It is not rocket science.
But I liked the idea to use Cognito and not think about this part of a project. But right now, after 1 year, and seeing zero improvement - even worse, discovering more and more issues. I came to the conclusion that sadly this part of a project is to important to rely on others.
Probably this yer I'll make a solution using Lambda, and CloudFormation - do it once and never think about this again.
ps. this issue #2707 is a classic example, where they blame you, confident that you are in the wrong, and then you slap them in the face with prove that the issue is on their side. It's frustrating.
I share the same frustration working on Amplify Auth for the past 4 weeks, which I was expecting Cognito to handle our authentication requirement pretty smoothly, as we are just wanting to have federated authentication with google and create user on Cognito user pool.
I am using Vue and there's no many examples, and none on the above that we are trying to achieve.
We have 2 projects running to have user records centralised on Cognito, one is our internal system where all users are using Google gsuite account; and the other is a public facing web site + mobile app that we need user records to be captured, even if user chose to login via google or facebook.
today, I thought I have finally get the amplify auth with google signin to work on our internal system, only to find out just a while ago that users are not created in UserPool, a feature required for both our projects.
I am not sure whether I have the patience to dig around for solution, trying to adapt examples, posted codes, mainly react, to vue to see if it works.
we have been big fan of AWS all these while, but Amplify/Cognito workflow may lead us to seriously consider whether we should continue with AWS or migrate to other cloud provider who may have cleaner auth workflow + decent cloud functionality.
@The-Edge-Malaysia did you use the CLI to bootstrap your project with social providers? If using vue, the docs have some examples here, which i'm assuming you've already seen: https://aws-amplify.github.io/docs/js/vue
But also in terms of using a social provider with amplify we've recently launched some things to greatly simplify this process documented here: https://aws-amplify.github.io/docs/js/authentication#social-provider-setup
Did you see/use those docs when you setup your apps? If you haven't, do you think they help? Otherwise would definitely like to hear feedback on improvements to them.
There is also a blog post here by one of our developer advocates on building a vue app: https://hackernoon.com/how-to-build-serverless-vue-applications-with-aws-amplify-67d16c79e9d6
If you are using Auth the users should definitely be created in the user pool, and they should be automatically added to a group per IDP. Do you have any code to share that I can take a look at to see some of your setup?
I think part of the problem is that most people leveraging these libraries are doing so for commercial purposes, so they have little incentive to share what discoveries they make about individual services.
Perhaps the real FR here is documentation littered with samples of various use cases for Cognito.
comments below:
@The-Edge-Malaysia did you use the CLI to bootstrap your project with social providers? If using vue, the docs have some examples here, which i'm assuming you've already seen: https://aws-amplify.github.io/docs/js/vue
this does not cover federatedSignIn, I found one pending review branch from @OrozcoJonathan on Vue, and extracted the relevant part, i.e. google sign in button, and it works, unfortunately without adding signed in users to user pool as per your documentation.
But also in terms of using a social provider with amplify we've recently launched some things to greatly simplify this process documented here: https://aws-amplify.github.io/docs/js/authentication#social-provider-setup
Theres no reference to Vue, I did follow the steps, i.e.
amplify init amplify add auth Default configuration with Social Provider (Federation)
Did you see/use those docs when you setup your apps? If you haven't, do you think they help? Otherwise would definitely like to hear feedback on improvements to them.
No, the docs does not, @OrozcoJonathan's branch does
There is also a blog post here by one of our developer advocates on building a vue app: https://hackernoon.com/how-to-build-serverless-vue-applications-with-aws-amplify-67d16c79e9d6
this is without federated signin
If you are using Auth the users should definitely be created in the user pool, and they should be automatically added to a group per IDP. Do you have any code to share that I can take a look at to see some of your setup?
` const awsmobile = { "aws_project_region": "ap-southeast-1", "aws_cognito_identity_pool_id": "ap-southeast-1:XXXXXXXX", "aws_cognito_region": "ap-southeast-1", "aws_user_pools_id": "ap-southeast-1XXXXXX", "aws_user_pools_web_client_id": "XXXXXXXXX", "oauth": { "domain": "authXXXXXXXX-dev.auth.ap-southeast-1.amazoncognito.com", "scope": [ "phone", "email", "openid", "profile", "aws.cognito.signin.user.admin" ], "redirectSignIn": "http://localhost:8080/", "redirectSignOut": "http://localhost:8080/", "responseType": "code" }, "federationTarget": "COGNITO_USER_POOLS" };
export default awsmobile; `
below is extracted from @OrozcoJonathan 's vueFederatedIdentity branch
federatedSignIn (googleUser) { const { id_token, expires_at } = googleUser.getAuthResponse() const profile = googleUser.getBasicProfile() let user = { email: profile.getEmail(), name: profile.getName(), picture: profile.getImageUrl() } if (!this.$Amplify.Auth || typeof this.$Amplify.Auth.federatedSignIn !== 'function' || typeof this.$Amplify.Auth.currentAuthenticatedUser !== 'function') { throw new Error('No Auth module found, please ensure @aws-amplify/auth is imported') } this.$Amplify.Auth.federatedSignIn('google', { token: id_token, expires_at }, user) .then(credentials => { this.$AmplifyEventBus.$emit('authState', 'signedIn') this.$router.push({ name: 'announcement' }) }) .catch(error => this.logger.error(error)) }
the above does not record new users to userpool
if I use hostedUI, currentAuthenticatedUser() sure to fail the first time after sign in, after a page refresh, then currentAuthenticatedUser() will return desired result
I have also noticed that localStorage's CognitoIdentityServiceProvider.xxxxxx.userData will only registered after page refresh.
@The-Edge-Malaysia did you use the CLI to bootstrap your project with social providers? If using vue, the docs have some examples here, which i'm assuming you've already seen: https://aws-amplify.github.io/docs/js/vue
But also in terms of using a social provider with amplify we've recently launched some things to greatly simplify this process documented here: https://aws-amplify.github.io/docs/js/authentication#social-provider-setup
Did you see/use those docs when you setup your apps? If you haven't, do you think they help? Otherwise would definitely like to hear feedback on improvements to them.
There is also a blog post here by one of our developer advocates on building a vue app: https://hackernoon.com/how-to-build-serverless-vue-applications-with-aws-amplify-67d16c79e9d6
If you are using Auth the users should definitely be created in the user pool, and they should be automatically added to a group per IDP. Do you have any code to share that I can take a look at to see some of your setup?
Well one of the problem is comments like yours, for every issue, someone just throws this link https://aws-amplify.github.io/docs/js/authentication and close the issue. look at this and this and many other issues Well If that link helps and clear enough nobody asks here. This whole amplify project seems low quality, vague product to me I had many issues with amplify's GraphQL and also Storage library too
I have tested the following scenarios
Auth with google, then pass the Auth result to federatedSignIn, which amplify documentation mentioned somewhere that user wont be created. But this works for me partly since currentAutenticatedUser not working, but I still can check whether user is authenticated, and get user email from google.
Auth via amplify using federatedsignin({ provider: ‘Google’ }), it redirected back to my page after authenticated, but I dont have user email though the user is created in Cognito.
In both scenario, if page is manually refreshed then currentAutenticatedUser will return the correct result.
But in first scenario, I bypassed amplify and get user email directly from google prior passing result to federatedsignin, that’s why I am able to identify user email upon signin without refresh.
The down side is: I don’t have the user registered in Cognito userpool
In second scenario, it is disastrous to ask user to refresh manually the page after signed in, in order to proceed.
In both scenarios, userData in localstorage created after manual page refresh.
On Sat, 22 Jun 2019 at 2:16 PM, Omid notifications@github.com wrote:
@The-Edge-Malaysia https://github.com/The-Edge-Malaysia did you use the CLI to bootstrap your project with social providers? If using vue, the docs have some examples here, which i'm assuming you've already seen: https://aws-amplify.github.io/docs/js/vue
But also in terms of using a social provider with amplify we've recently launched some things to greatly simplify this process documented here: https://aws-amplify.github.io/docs/js/authentication#social-provider-setup
Did you see/use those docs when you setup your apps? If you haven't, do you think they help? Otherwise would definitely like to hear feedback on improvements to them.
There is also a blog post here by one of our developer advocates on building a vue app:
https://hackernoon.com/how-to-build-serverless-vue-applications-with-aws-amplify-67d16c79e9d6
If you are using Auth the users should definitely be created in the user pool, and they should be automatically added to a group per IDP. Do you have any code to share that I can take a look at to see some of your setup?
Well one of the problem is comments like yours, for every issue, someone just throws this link https://aws-amplify.github.io/docs/js/authentication#social-provider-setup and close the issue. look at this https://github.com/aws-amplify/amplify-js/issues/1316 and this https://github.com/aws-amplify/amplify-js/issues/1521 and many other issues Well If that link helps and is clear nobody asks here. This whole amplify project seems low quality, vague product to me I had many issues with amplify's GraphQL library too
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aws-amplify/amplify-js/issues/3495?email_source=notifications&email_token=AE6WG3QXTGDPFY66GHJEGL3P3W7TXA5CNFSM4HZP3UMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYKB6DI#issuecomment-504635149, or mute the thread https://github.com/notifications/unsubscribe-auth/AE6WG3US4EX6QVMQV7IWUD3P3W7TXANCNFSM4HZP3UMA .
Hi!
Took me a while to dig and found this
https://github.com/aws-amplify/amplify-js/issues/1386
Am not sure will this help but definitely I will try later today
On Sat, 22 Jun 2019 at 2:49 PM, CY CHIA chinyau.chia@bizedge.com wrote:
I have tested the following scenarios
Auth with google, then pass the Auth result to federatedSignIn, which amplify documentation mentioned somewhere that user wont be created. But this works for me partly since currentAutenticatedUser not working, but I still can check whether user is authenticated, and get user email from google.
Auth via amplify using federatedsignin({ provider: ‘Google’ }), it redirected back to my page after authenticated, but I dont have user email though the user is created in Cognito.
In both scenario, if page is manually refreshed then currentAutenticatedUser will return the correct result.
But in first scenario, I bypassed amplify and get user email directly from google prior passing result to federatedsignin, that’s why I am able to identify user email upon signin without refresh.
The down side is: I don’t have the user registered in Cognito userpool
In second scenario, it is disastrous to ask user to refresh manually the page after signed in, in order to proceed.
In both scenarios, userData in localstorage created after manual page refresh.
On Sat, 22 Jun 2019 at 2:16 PM, Omid notifications@github.com wrote:
@The-Edge-Malaysia https://github.com/The-Edge-Malaysia did you use the CLI to bootstrap your project with social providers? If using vue, the docs have some examples here, which i'm assuming you've already seen: https://aws-amplify.github.io/docs/js/vue
But also in terms of using a social provider with amplify we've recently launched some things to greatly simplify this process documented here: https://aws-amplify.github.io/docs/js/authentication#social-provider-setup
Did you see/use those docs when you setup your apps? If you haven't, do you think they help? Otherwise would definitely like to hear feedback on improvements to them.
There is also a blog post here by one of our developer advocates on building a vue app:
https://hackernoon.com/how-to-build-serverless-vue-applications-with-aws-amplify-67d16c79e9d6
If you are using Auth the users should definitely be created in the user pool, and they should be automatically added to a group per IDP. Do you have any code to share that I can take a look at to see some of your setup?
Well one of the problem is comments like yours, for every issue, someone just throws this link https://aws-amplify.github.io/docs/js/authentication#social-provider-setup and close the issue. look at this https://github.com/aws-amplify/amplify-js/issues/1316 and this https://github.com/aws-amplify/amplify-js/issues/1521 and many other issues Well If that link helps and is clear nobody asks here. This whole amplify project seems low quality, vague product to me I had many issues with amplify's GraphQL library too
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aws-amplify/amplify-js/issues/3495?email_source=notifications&email_token=AE6WG3QXTGDPFY66GHJEGL3P3W7TXA5CNFSM4HZP3UMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYKB6DI#issuecomment-504635149, or mute the thread https://github.com/notifications/unsubscribe-auth/AE6WG3US4EX6QVMQV7IWUD3P3W7TXANCNFSM4HZP3UMA .
I have tried #1386 adopted to Vue but not working for me
@cliffordh, and as you can see, there is an issue, a random link is sent out, that dose not solve anything or is even related to the issue, and then silence. The problem is gone :D The lack of responsibility in the Cognito team is on a different level.
Hi
I managed to get Amplify auth federated sign in work properly in my Vue app.
Based on react example, there’s Hub listener that does not appear in Vue documentation do the work I need, ie user auth using google via Cognito, and create an entry in userpool.
I can share the codes later as now on mobile
On Wed, 3 Jul 2019 at 3:03 AM, David Gatti notifications@github.com wrote:
@cliffordh https://github.com/cliffordh, and as you can see, there is an issue, a random link is sent out, that dose not solve anything or is even related to the issue, and then silence. The problem is gone :D The lack of responsibility in the Cognito team is on a different level.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aws-amplify/amplify-js/issues/3495?email_source=notifications&email_token=AE6WG3SMLLM7XBQNYYTVU7TP5ORARA5CNFSM4HZP3UMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZCH66I#issuecomment-507805561, or mute the thread https://github.com/notifications/unsubscribe-auth/AE6WG3WTHG4DUWHHXJPFBM3P5ORARANCNFSM4HZP3UMA .
Mmm undocumented functionality, one of the pillars of Cognito SDKs. And the documentation never to be updated - because treasure hunts are fun.
To be precise, amplify-Vue does not mention Hub listener, but in the authentication example in react, uses Hub listener.
It took me 6 weeks with countless builds to realized that Hub listener is the one that do the magic!
Hub is implemented in amplify core btw
On Wed, 3 Jul 2019 at 3:25 PM, David Gatti notifications@github.com wrote:
Mmm undocumented functionality, one of the pillars of Cognito SDKs. And the documentation never to be updated - because treasure hunts are fun.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aws-amplify/amplify-js/issues/3495?email_source=notifications&email_token=AE6WG3XIKZDUWHBPGI53SM3P5RH7ZA5CNFSM4HZP3UMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZDRHAQ#issuecomment-507974530, or mute the thread https://github.com/notifications/unsubscribe-auth/AE6WG3QJG3WIKJTLEB4AAB3P5RH7ZANCNFSM4HZP3UMA .
I tried to use the simplest default configuration for setting up Cognito with google federated auth and using react's withAuthenticator. When the user signs in with Google, nothing happens besides the error "Token is not from a supported provider of this identity pool"
I'm starting from scratch using only the simplest default tools and settings provided, and it doesn't even work. It's as if nobody has actually tried this. I reported the issue many months ago but it seems no progress has been made.
I want to like and use Cognito but it is really clearly an unloved part of AWS.
@revmischa, yep, and even if you were to fix this issue (there is a way), there will be yet another issue, ingrained with the SDK, that can't be overcome. So you spend weeks, thing you finally got it working, and then the SDK won't create the right session for the main SDK to use 🤣.
Your issue is a miss-configuration with you know the urls, but don't bother with solving that since the oAuth SDK AWS provide dose not create the user session the right way anyway. So... waste of time.
@revmischa had this too, using Gatsby and the HOC, seems like aws-exports.js cannot be read, so ended up using:
import Amplify from "aws-amplify"
import { withAuthenticator } from "aws-amplify-react"
import awsmobile from "./../aws-exports"
let awsmobileMandatorySignIn =
awsmobile.aws_mandatory_sign_in == "enable" ? true : false
Amplify.configure({
Auth: {
// REQUIRED - Amazon Cognito Identity Pool ID,
identityPoolId: awsmobile.aws_cognito_identity_pool_id,
// REQUIRED - Amazon Cognito Region
region: awsmobile.aws_cognito_region,
// OPTIONAL - Amazon Cognito User Pool ID
userPoolId: awsmobile.aws_user_pools_id,
// OPTIONAL - Amazon Cognito Web Client ID (26-char alphanumeric string)
userPoolWebClientId: awsmobile.aws_user_pools_web_client_id,
// OPTIONAL - Enforce user authentication prior to accessing AWS resources or not
mandatorySignIn: awsmobileMandatorySignIn,
// OPTIONAL - Configuration for cookie storage
// cookieStorage: {
// // REQUIRED - Cookie domain (only required if cookieStorage is provided)
// domain: ".bodycode.app",
// // OPTIONAL - Cookie path
// path: "/",
// // OPTIONAL - Cookie expiration in days
// expires: 365,
// // OPTIONAL - Cookie secure flag
// secure: true,
// },
},
})
...
const federated = {
google_client_id:
"471zzzzzzzzzzzzzzzzs37f2.apps.googleusercontent.com",
}
export default withAuthenticator(App, {
includeGreetings: false, // disable the signout menu bar
federated: federated,
})
Note that I commented out the cookie stuff as (if I remember correctly) it breaks something with federation
@aldegoeij Were you able to get the Amplify Cognito feature working with Gatsby?
I'm using Gatsby and Amplify Cognito together and started here: https://github.com/dabit3/gatsby-auth-starter-aws-amplify
I got it working okay, but the aws-amplify version is "1.0.5", the aws-amplify-react version is "1.0.5" and so I decided to update them to the most recent versions ("1.1.33"/2.3.12").
After that, I just had a blank white screen without any errors/warnings. I updated these packages because the out-of-the-box UI looked really old and not like the UI components in the docs: https://aws-amplify.github.io/media/ui_library
Please let me know if you had a similar issue, or if you know how to resolve.
Finally, I do agree with @davidgatti in that the Cognito stuff is a real pain. I've actually bailed on Cognito for a few projects to go use Auth0 (which I don't like much BTW but is cake) or Passport or some other time-consuming work-around. My eyes bleed from trying to make it work and then I'm very afraid to release it into the wild.
Sorry to the maintainers, I know it is hard work.
I'd love to use Cognito for anything possible but it is very troubling for me every time.
UPDATE: After testing various aws-amplify-react packages, it appears that any package after aws-amplify-react@2.0.0 gives me a blank white screen. The aws-amplify package does seem to be working okay so far as I tested it with aws-amplify-react@1.0.5. So, my next step is to drop the withAuthenticator HOC and go without.
UPDATE #2 LOL: sorry guys I did make some errors on my end with the aws-amplify & aws-amplify-react packages. I did get it working and so far I cannot claim it is a Cognito bug/issue.
So, my AWS Cognito works fine now. I do agree that I've had many issues with Cognito and a lot of them may be on the AWS Cognito side, but I think most of them come from my own lack of experience.
With that being said, I do not agree with these folks saying there's a level of incompetence because that is simply no true. My issue is that Cognito is TOUGH and troublesome, but then I'm under tight time constraint and I'm doing login/signup + UI + server + DB so I typically run away from Cognito because it is more difficult than other options.
Keep the peace, they're working on it...
I really would like to use Cognito! But it just feels very unfinished and scary. Especially I dislike the fact that if I change one small detail of my Cognito pool (such as password min length) in CloudFormation, it will helpfully destroy the user pool and remake it, deleting all users!
From the issues created in this repo, the lack of responsiveness from the Cognito team which keep issues not being acknowledged, the state of the code for all the SDKs related to Cognito, and the incoherent mess that this SDK are in, and the private chats that I had with AWS Teach Support I understand the problem that the Cognito service has.
There is nobody responsible for the Cognito project which explains the state of Cognito.
To give you some perspective, when on Github for the Kinesis Video Stream services I mentioned about some issues within 1 day the manager for the project got in touch with me, and called me to have a chat - and the complaint was marginal compared to what's happening with Cognito.
I see that there is no future for Cognito, and from now on, I'll start to transition my clients to a custom solution that I have control over, and what I build will just work.
I'm truly disappointed that nobody at AWS can be held accountable for Cognito, and there is no way for someone from the outside to point to the problem. The consequence of this are reflected in the product itself.
To sum it up, my feature request is this: I hope this level of incompetence won't spread to other AWS services.
We would like to do the same but they make it almost impossible to transition off of the platform unless you want to ask all of your users to create new passwords on a new system. That is the most infuriating part.
I really would like to use Cognito! But it just feels very unfinished and scary. Especially I dislike the fact that if I change one small detail of my Cognito pool (such as password min length) in CloudFormation, it will helpfully destroy the user pool and remake it, deleting all users!
Nice feature :D
From the issues created in this repo, the lack of responsiveness from the Cognito team which keep issues not being acknowledged, the state of the code for all the SDKs related to Cognito, and the incoherent mess that this SDK are in, and the private chats that I had with AWS Teach Support I understand the problem that the Cognito service has. There is nobody responsible for the Cognito project which explains the state of Cognito. To give you some perspective, when on Github for the Kinesis Video Stream services I mentioned about some issues within 1 day the manager for the project got in touch with me, and called me to have a chat - and the complaint was marginal compared to what's happening with Cognito. I see that there is no future for Cognito, and from now on, I'll start to transition my clients to a custom solution that I have control over, and what I build will just work. I'm truly disappointed that nobody at AWS can be held accountable for Cognito, and there is no way for someone from the outside to point to the problem. The consequence of this are reflected in the product itself. To sum it up, my feature request is this: I hope this level of incompetence won't spread to other AWS services.
We would like to do the same but they make it almost impossible to transition off of the platform unless you want to ask all of your users to create new passwords on a new system. That is the most infuriating part.
In theory you would not have to ask that question. You could do the transition, and send out an email explaining your password was reset (not set at all), or when they log in next time, you tell the user that the account was locked for security reason and they'll get a verification email which will allow when to set the new password.
I believe this is a good flow and secure.
Someone made this to allow modifying custom attributes without accidentally deleting all of your users https://github.com/michaelduminy/serverless-cognito-add-custom-attributes
Nice, one guy for free made it, a billion dollar company with unlimited resources - unable. Nice - this just is to fun :)
@damianesteban you can create a new userpool and implement a migrate hook, there you will have the change to migrate the user in the pool on the first login keeping their passwords
@davidgatti this info is already in the docs https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-import-using-lambda.html
IMHO authentication is a complex thing, cognito is not perfect but if you try something similar (like auth0) with a custom signup or UI it will be hard too. At least for me auth amplify worked great for the 80% of the auth process (like in the pareto principle) of course we have a bit of experiencies in the oauth stuff for adding the extra 20%
As stated in the documentation:
This approach enables seamless migration of users from your existing user directory to user pools when they use your new Amazon Cognito-enabled app for the first time, either during their first sign-in or during the forgot-password process.
So if I understand correctly, your old user pool that got it's user base deleted by a poor AWS implementation won't work, since it seams you need a database of user to move to a new location? Or did I miss something?
You don't have to change the conf on your current userpool (i think that most of the things should be readonly after the creation), you need to create a new one with the new configurations and configure the migration trigger on the new one.
We usually work with cloudformation , sdk or cdk so create a new resource is not a problem.
I don't think that cognito or amplify are perfect, but auth is something really serious and risky, IMHO writing it by yourself is not an option (It could be acceptable only if I decide to start a competitor ;-) ) , even running it by yourself (at least for me the GDPR stuff is painful). Cognito is a good alternative to other similar services, and from my point of view it's free (the free tier is 50K monthly active user) and other competitor services like auth0 will cost you a lot if you need things like SAML. It's not only a username and password login, it's IAM roles, social login, federation, brute force detection, one time password.
If you need more control over cognito you can also use a custom login flow,
I tried to use the simplest default configuration for setting up Cognito with google federated auth and using react's withAuthenticator. When the user signs in with Google, nothing happens besides the error "Token is not from a supported provider of this identity pool"
I'm starting from scratch using only the simplest default tools and settings provided, and it doesn't even work. It's as if nobody has actually tried this. I reported the issue many months ago but it seems no progress has been made.
I want to like and use Cognito but it is really clearly an unloved part of AWS.
This exact thing happens to me. Is a hosted UI required to use federated login? Exact same error. Incredibly annoying.
Share the same frustration. I am following the exact process for Vue Authenticator. First I could not import the components and when that worked, the following error appears:
[Vue warn]: Error in mounted hook (Promise/async): "TypeError: Cannot read property 'Logger' of undefined"
found in
---> <Authenticator>
<Login> at src/renderer/components/Login.vue
<Satmind> at src/renderer/App.vue
<Root>
Share the same frustration. I am following the exact process for Vue Authenticator. First I could not import the components and when that worked, the following error appears:
[Vue warn]: Error in mounted hook (Promise/async): "TypeError: Cannot read property 'Logger' of undefined" found in ---> <Authenticator> <Login> at src/renderer/components/Login.vue <Satmind> at src/renderer/App.vue <Root>
My recommendation: Just code up the Auth flow yourself. That's what I had to do and it was better than tinkering with their Auth wrappers. I was able to accomplish this with "full-featured" auth flows using Gatsby.
https://www.gatsbyjs.org/starters/ben-siewert/gatsby-starter-auth-aws-amplify/
Same problem with social auth for React Native. Many users request federated auth with amplify via Cognito User Pools but issues just disappears between the Amplify and Cognito team. No clear solutions and roadmap, only "hacky" solutions from the community.
yup, completely agree with everything. I'm trying to get our team away from this plague knows as amplify
I have a lot of problems setting up cognito with lambda and apigateway, am using serverless and am getting CORS exceptions, I dont understand why am getting them, everything works without cognito.
Same here. We come from Firebase Auth and everything was smooth and easy. I didn't appreciate how great was Firebase until trying to migrate to Cognito, which has caused our team countless pains (and is still causing)
With the changes we've deployed in the last few weeks to Cloudformation, you now have the ability to configure any User Pool feature including domains and adding custom attributes. If you make a change that is incompatible with your pool, i.e. changing your alias type or removing a custom attribute it will error instead of tearing down your pool. Hope this helps with some of your pain points.
@behrooziAWS great to see some input from AWS on these issues. There is a lot of frustration in the community surrounding Cognito and Amplify. It seems things are relatively great if you simply use the cli to bootstrap an app and go from there, but in other scenarios the pain points are numerous. It would be really good to see a little more attention and help from AWS on these issues since Auth is such a critical component in almost every application.
@davidgatti
What are you moving to instead? I also - think - that to access AWS resources you will at some point need to use cognito identity pools, right? The alternative would be to create signed urls for each endpoint?
Also, for those curious, here is an issue I posted a few weeks ago pointing out that the official javascript cognito auth sdk appears to be dead without comment: https://github.com/aws/amazon-cognito-auth-js/issues/214
Incredibly disappointing that a core AWS service -- arguably the most critical component of any app -- has such poor management. This prevents us from quickly spending money on AWS infrastructure, which we all want to happen
@ajhool I mentioned that I’m going to do my own login thing using Serverless. And I have no issue with Cognito Identity Pool, I don’t wan to use the User Pool part. The only thing that I have to figure out is how to interact with the Identiy Pool to get the right data and based on that create a Cookie for the browser that the AWS SDK for the Browser can use.
And that is it.
@davidgatti yes, was just curious if you had gone through with the Serverless implementation and how you had found it to be.
Not yet, bit busy with the business, but the plan is to do this hopefully next year, and for sure I will release it for free on my company GitHub Page - https://github.com/0x4447, you can check there every 3 months and see how it goes. And rest assure I will share the link to the project here to :)
It's too late for my project to move away from Cognito. Whenever someone asks for auth solutions, I specifically warn them not to use Cognito. aws-amplify is a mess, the Cognito API is a mess, the source is a mess, the user experience is a mess.
The only reason this repo has "only" 480 open issues and not more, is b/c stalebot closes old issues. A lot of my issues have been "marked as a feature request", which I've come to learn is a euphemism for "shut up and go away"
/rant
Unrelated, does anyone know if yelp for open source projects exists?
@guanzo I think everyone on this thread wishes this was truly an open-source project, but as much as AWS is soliciting feedback and contributions for the community, we're completely beholden to what AWS want to do in amongst their own priorities. In other words, you're looking for a Yelp for commercial software reviews. And to your other points (and many made by others), it is striking how oddly mismanaged the Cognito product appears to be. There's a comment in here presumably from an AWS employee saying that there is no product manager for Cognito for some reason.
I have a lot of problems setting up cognito with lambda and apigateway, am using serverless and am getting CORS exceptions, I dont understand why am getting them, everything works without cognito.
@viktor You probably need to setup your API gateway default 4XX response to include the appropriate CORS headers
@davidgatti Thank you for writing this up. I feel like I just dodged a bullet.
I've taken a couple of stabs at cognito over the last year or two. The title of this thread hits the nail on the head. Good idea in theory, but horribly mismanaged in practice. Most of AWS is solid, so this particular product seems like an outlier. It would be nice if someone from aws would sound off on this topic.
It's too late for my project to move away from Cognito. Whenever someone asks for auth solutions, I specifically warn them not to use Cognito. aws-amplify is a mess, the Cognito API is a mess, the source is a mess, the user experience is a mess.
Unfortunately I also read this too late :(
Does anybody have suggested alternatives to Cognito user pools? These are the things that I like about Cognito and would like to see in other implementations:
Easy fine-grained access control to AWS resources. By placing the cognito "sub" in an IAM policy for S3, I can limit user access by path (eg. allow s3://private/{sub}/) would allow cognito users to access that sub. Maybe custom claims can be used in the same way (eg. allow s3://private/{custom:auth0Id}).
When using AWS resources, I usually don't need to worry about token management. For instance, when a cognito authenticated user makes an API Gateway call, the request is transformed to include their user information (username, sub, etc.). This "magic" implementation is convenient but perhaps a custom implementation would not be too challenging. Under the hood, is API Gateway simply making a backend request to Cognito to unwrap the JWT token? To replicate this with a different auth provider (eg. Auth0, firebase, azure, etc.), would you make an API call at the top of the lambda function to unwrap the token? Would that call need to go over the network or can a secret key be added to the lambda? Auth0 jwt management: https://github.com/auth0/node-jsonwebtoken
HostedUI - the hosted UI is quite convenient.
While cognito has many flaws, surely other auth providers do, too. For example, there are complaints that you can't export user pools from cognito without requesting a new password from users... but, that seems like an inherent limitation to all auth providers because passwords can't be stored in plain text. If other auth providers have an "export" button, then that might be convenient -- but doesn't seem that much more convenient than writing a script to migrate usernames/emails to another auth provider from cognito.
It seems highly unlikely that the best alternative to Cognito for everybody is "write it yourself". Surely there would be good competitor auth providers if this were such an easy task that every team could robustly implement it themselves. I see a few mentions of Auth0 and firebase auth; however, writing it yourself seems to be the dominant alternative suggestion in this thread...
Thank God I found this thread before even starting. God bless you guys.
Edit: During the past week I've been testing and inspecting the rest of the project and I have to say that, overall, Amplify is a good product. Also, considering the fact that it is open source and the current alternatives, I've decided to use it on a main project.
That aside, I'd really like to hear what @undefobj, @dabit3 and other people from the Amplify team have to say about this thread.
I'm looking into alternatives myself. This one looks fairly mature and is free until you hit 1000+ users. https://developer.okta.com/
I love Cognito ❤️ but amplify-js
is such a mess and buggy 😭 I hope AWS will hear from us and improve this project
From the issues created in this repo, the lack of responsiveness from the Cognito team which keep issues not being acknowledged, the state of the code for all the SDKs related to Cognito, and the incoherent mess that this SDK are in, and the private chats that I had with AWS Teach Support I understand the problem that the Cognito service has.
There is nobody responsible for the Cognito project which explains the state of Cognito.
To give you some perspective, when on Github for the Kinesis Video Stream services I mentioned about some issues within 1 day the manager for the project got in touch with me, and called me to have a chat - and the complaint was marginal compared to what's happening with Cognito.
I see that there is no future for Cognito, and from now on, I'll start to transition my clients to a custom solution that I have control over, and what I build will just work.
I'm truly disappointed that nobody at AWS can be held accountable for Cognito, and there is no way for someone from the outside to point to the problem. The consequence of this are reflected in the product itself.
To sum it up, my feature request is this: I hope this level of incompetence won't spread to other AWS services.