- Newest
- Most votes
- Most comments
-
In addition to what is described in the blog, Cognito added support for a Migration Lambda trigger that allows an easier setup for a one-by-one migration, basically replacing the "migration microservice" described in the blog. This is the only way to retain passwords transparently for the user, as the user will not know the backing IdP has changed. This process will take some time to execute as it requires that each user logs in at least once, and it is important that the implementation follows the advices given in our documentation in regard to which auth flow to use.
-
This is up to the customer to decide, and depends on when the users log in the first time. The customer can decide on a given threshold (eg 70% of user migrated) before shutting down his existing auth. This would mean that the remaining users will have to use the forgotten password flow to set the password in the new system (explained in the doc above)
-
If the user already exists in Cognito, the migration lambda is not called and the user logs in directly into Cognito
-
The customer can export the content of the pool using the ListUser API. Cognito does not stores the user passwords in recoverable format hence they cannot be exported. A process similar to the one used to migrate into Cognito can be also used to migrate user out of Cognito
Relevant content
- asked a year ago
- AWS OFFICIALUpdated 18 days ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 5 months ago
- AWS OFFICIALUpdated 2 years ago