Ability to resume authentication flow (v6)

[RyanElliottPotterGMSL]

Is this related to a new or existing framework?

React

Is this related to a new or existing API?

Authentication

Is this related to another service?

No response

Describe the feature you'd like to request

We're looking to upgrade from Amplify v5 to v6, but currently have sign in custom challenge work around which doesn't look possible with the new v6 API.

We have a requirement for custom sign in challenge which involves redirecting the user away from the login page to an external MFA page, and back, to which we can then perform the custom challenge response. We've solved this in Amplify v5 by persisting most of the CognitoUser data in session storage and hydrating the client after the redirect back to the login page. Whilst this isn't ideal, it allows us to resume the session and perform the custom challenge response to successfully sign in.

In v5, this is possible because the sendCustomChallengeAnswer function takes the cognito user session as an argument, allowing us to re-create the CognitoUser object and pass that in manually. Now in v6, I believe this is handled automatically in memory and the concept of CognitoUser has been replaced and is no longer passed around manually.

Describe the solution you'd like

A possible solution to this in v6 could be to expose the ability to read and hydrate the sign in store manually. This would allow us to initiate the sign in store with the persisted values after an external redirect.

Describe alternatives you've considered

I've tested a proof of concept locally which exposes the sign in store and related functions to the consumer.

By calling the setActiveSignInState function with the serialised value from signInStore.getState() that was persisted in session storage, it allowed the ability to continue the authentication session, call confirmSignIn and successfully sign in.

Additional context

For additional context, we also have a pre-existing issue open which describes the v5 issue/solution in better detail. The resolution of this in v6 will likely allow us to close that older issue once we've upgraded.

Let me know if you need any additional context. We're looking forward to upgrading to v6 - the new API and improved types are looking great.

Is this something that you'd be interested in working on?

• [ ] 👋 I may be able to implement this feature request
• [ ] ⚠️ This feature might incur a breaking change

[nadetastic]

HI @RyanElliottPotterGMSL thank you for opening this issue. This does sound like an interesting use case that you were able to address in V5, but would need a different approach in V6. I'm discussing this internally to determine if there are any potential work arounds, and will mark this as a feature request for now. Let me know if you have any additional questions. Thanks!

[cwomack]

As @RyanElliottPotterGMSL stated in description of this issue, related to #10469.

[mtwilliams-code]

Any progress or workarounds here yet? +1 on experiencing this blocker

[awadhwanan]

@cwomack @nadetastic @josefaidt Do you guys have any update on this?

[awadhwanan]

Do you have an example solution for handling the use case where the email is sent first and then the user clicks on the same and needs to resume with the next challenge for sms otp?