Skip to content
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

Ability to resume authentication flow #10469

Open
2 tasks
LouisYoungGMSL opened this issue Oct 13, 2022 · 0 comments
Open
2 tasks

Ability to resume authentication flow #10469

LouisYoungGMSL opened this issue Oct 13, 2022 · 0 comments
Assignees
Labels
Auth Related to Auth components/category feature-request Request a new feature V5

Comments

@LouisYoungGMSL
Copy link

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'd like to be able to resume an authentication flow when completing a custom challenge (MFA in this case) that requires us to navigate away from the current login page. The MFA page would redirect us back to the login page where we would then expect to send the custom challenge response via Amplify to Cognito.

Unfortunately, all session information prior to logging in is currently lost from Amplify when navigating away in the middle of a authentication flow which means we cannot simply pick up where we left off.

Describe the solution you'd like

A possible solution might be to introduce a mechanism to somehow temporarily persist the relevant session details that are used to authenticate (possibly using a browser storage API) so that it can be retrieved at a later time when resuming an authentication flow (such as after a redirect from/to the application).

This would potentially require additional APIs to allow us to store a session and retrieve an existing session such that we can support navigating away from an authentication flow without losing that vital context.

Describe alternatives you've considered

I've tested a proof of concept of the suggested possible solution above by persisting the user manually. This isn't ideal as the user returned by Auth.signIn is an instance of CognitoUser that can't be serialised and stored and then retrieved and deserialised properly.

To work around this, I've attempted to hydrate/reconstruct a CognitoUser by using the properties from the user returned by Auth.signIn that I've persisted in a browser storage API. From what I can see, there isn't a documented way to do this.

// Logic to determine whether initially signing in or continuing MFA journey.
if (resumingLogin) {
  resumeSignIn()
} else {
  doSignIn()
}

const doSignIn = () => {
  // Navigate away to MFA provider.
  ...
}

const resumeSignIn = () => {
  const deserialisedUser = ...;
  const challengeResponse = ...; // In our case, we'd retrieve this from the URL query parameters.


  const cognitoUserPool = new CognitoUserPool({
    UserPoolId: "...",
    ClientId: "...",
  });

  const cognitoUser = new CognitoUser({
    Username: deserialisedUser.username,
    Pool: cognitoUserPool,
  });

  cognitoUser.authenticationFlowType = deserialisedUser.authenticationFlowType;
  cognitoUser.challengeName = deserialisedUser.challengeName;
  cognitoUser.challengeParam = deserialisedUser.challengeParam;
  cognitoUser.Session = deserialisedUser.Session;
  
  amplify.sendCustomChallengeAnswer(cognitoUser, challengeResponse);

  ...
}

This then means that we can use the user to send the challenge response by calling Auth.sendCustomChallengeAnswer with the user that has just been reconstructed and the challenge response that we've extracted from the redirect URL.

Additional context

At the moment, we implement MFA by calling Auth.signIn and then displaying an MFA challenge (embedded in an iframe within the page) and sending the custom challenge answer by calling Auth.sendCustomChallengeAnswer which requires the user as a parameter. This works as the user is still in scope from the initial Auth.signIn response.

Now, we're using an MFA provider that works using a hosted UI redirect instead of an embeddable UI. We'd sign in by calling Auth.signIn and then redirect to the URL of the hosted UI. After the challenge has been completed, the MFA provider will redirect back to the client (a React SPA in this context) with a code in the URL as a query parameter which we'd send by calling Auth.sendCustomChallengeAnswer (which then gets exchanged for an MFA result in a Lambda). However, Auth.sendCustomChallengeAnswer requires the user as a parameter. As the hosted UI redirects back to the client, any context/state of the user from the initial Auth.signIn response is lost so we are unable to call Auth.sendCustomChallengeAnswer with a user.

I stumbled across a conceptually similar issue where someone was attempting to persist a CognitoUser across the lifetime of an authentication flow on the server side. This was "solved" by storing the user in an object in memory in the Node/Express application (which only works if you have a single server) but I thought I'd reference it for completeness. #3373

Thanks in advance 🙂

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
@LouisYoungGMSL LouisYoungGMSL added the feature-request Request a new feature label Oct 13, 2022
@tannerabread tannerabread added the Auth Related to Auth components/category label Oct 14, 2022
@haverchuck haverchuck added the pending-triage Issue is pending triage label Oct 24, 2022
@stocaaro stocaaro added Service Team Issues asked to the Service Team Cognito Related to cognito issues labels Jan 19, 2023
@jimblanc jimblanc removed the pending-triage Issue is pending triage label Apr 7, 2023
@cwomack cwomack added V5 and removed Cognito Related to cognito issues Service Team Issues asked to the Service Team labels Mar 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Auth Related to Auth components/category feature-request Request a new feature V5
Projects
None yet
Development

No branches or pull requests

6 participants