autoSignIn doesn't work if Auth.confirmSignUp was called in a different session than Auth.signUp

[oemer-aran]

Before opening, please confirm:

• [X] I have searched for duplicate or closed issues and discussions.
• [X] I have read the guide for submitting bug reports.
• [X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

JavaScript Framework

Vue

Amplify APIs

Authentication

Amplify Categories

auth

Environment information

``` System: OS: macOS 12.4 CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz Memory: 112.89 MB / 16.00 GB Shell: 5.1.8 - /usr/local/bin/bash Binaries: Node: 14.17.0 - /usr/local/bin/node Yarn: 3.2.1 - /usr/local/bin/yarn npm: 6.14.13 - /usr/local/bin/npm Browsers: Chrome: 104.0.5112.79 Edge: 92.0.902.84 Firefox: 102.0.1 Safari: 15.5 npmPackages: @sde/js-config: * => 1.0.0 @types/node: ^14.14.0 => 14.18.12 @types/source-map-support: ^0.5.3 => 0.5.3 @typescript-eslint/eslint-plugin: ^4.5.0 => 4.5.0 @typescript-eslint/parser: ^4.5.0 => 4.5.0 DockerImageFunctionConstruct: 0.1.0 aws-cdk: 2.22.0 => 2.22.0 aws-sdk: ^2.774.0 => 2.1111.0 cdk-assets: 2.22.0 => 2.22.0 esbuild: ^0.8.21 => 0.8.21 eslint: ^7.11.0 => 7.32.0 eslint-config-prettier: ^6.13.0 => 6.15.0 eslint-import-resolver-typescript: ^2.3.0 => 2.3.0 eslint-plugin-deprecation: ^1.1.0 => 1.1.0 eslint-plugin-import: ^2.22.1 => 2.22.1 eslint-plugin-jest: ^24.1.0 => 24.1.0 eslint-plugin-markdown: ^2.2.1 => 2.2.1 eslint-plugin-prettier: ^3.1.4 => 3.4.1 eslint-plugin-vue: ^7.1.0 => 7.1.0 hello_world: 1.0.0 husky: ^4.3.0 => 4.3.8 lerna: ^4.0.0 => 4.0.0 lint-staged: ^10.4.2 => 10.4.2 markdownlint-cli: ^0.24.0 => 0.24.0 memo-parser: 0.2.1 node-gyp: ^8.4.1 => 8.4.1 (7.1.2, 5.1.1) prettier: ^2.1.2 => 2.6.0 shx: ^0.3.4 => 0.3.4 ts-node: ^9.0.0 => 9.0.0 typescript: 4.0.3 => 4.0.3 npmGlobalPackages: npm: 6.14.13 yarn: 1.22.18 ```

Describe the bug

Using the autoSignIn option with Auth.signUp only works, when Auth.confirmSignUp is called in the same tab/session. This can lead to very bad UX during the registration process. An example where this can happen is when you have a confirmation email. The email can have a button which redirects the user to the confirmation page to enter the confirmation code. The page will be loaded in a new session/tab, which will make autoSignIn fail.

If the user remains in the same tab/session after calling Auth.signUp and calls Auth.confirmSignUp it works as expected

I took a look into the code already, and the way it's implemented it also makes sense. handleAutoSign is called in the Auth.signUp function. This functions sets autoSignInInitiated to true. However, since Auth is loaded from scratch if you click on the email link/open a new session, autoSignInInitiated is obviously still false. If autoSignInitiated is false, when Auth.confirmSignUp is called, the Hub returns the error: autoSignIn_failure.

Suggestion, if technically possible: Logically it makes more sense to me to put the autoSignIn option in the Auth.confirmSignUp function (and not Auth.signUp). The response can then contain the user and a Hub event wouldn't be required anymore.

P.S.: Not sure if this is a bug or intended. But since the autoSignIn feature has very little benefit and inconsistent behaviour as it is right now, I sort it more bug category.

This is a follow up to: https://github.com/aws-amplify/amplify-js/issues/6320

Expected behaviour

4. Hub returns success with the autoSignIn event.

Reproduction steps

1. User signs up with Auth.signUp and autoSignIn: { enabled: true } (e.g. on /register page)
2. User receives email with link to e.g.: /register/confirm?username=my@email.de&code=492994
3. User confirms registration with Auth.confirmSignUp using the URL params from 2.
4. Hub returns autoSignIn_failure

Code Snippet

// simplified, as in the official docs
// https://docs.amplify.aws/lib/auth/emailpassword/q/platform/js/#auto-sign-in-after-sign-up
import { Hub } from 'aws-amplify';

function listenToAutoSignInEvent() {
    Hub.listen('auth', ({ payload }) => {
        const { event } = payload;
        if (event === 'autoSignIn') {
            const user = payload.data;
            // assign user
        } else if (event === 'autoSignIn_failure') {
            // redirect to sign in page
        }
    })
}

Log output

``` // Put your logs below this line ```

aws-exports.js

No response

Manual configuration

import Amplify from "aws-amplify"

Amplify.configure({
    ssr: true,
    aws_project_region: "XXXX",
    aws_cognito_region: "XXXX",
    aws_user_pools_id: "XXXX",
    aws_user_pools_web_client_id: "XXXX"
  })
}

Additional configuration

No response

Mobile Device

No response

Mobile Operating System

No response

Mobile Browser

No response

Mobile Browser Version

No response

Additional information and screenshots

No response

[ar2pi]

+1

[arthur-gyulabyan1]

Also have the same scenario with confirmation after redirection from email. Would be great if autoSignIn is triggered in this case too.

[AdamFlan]

+1

[yanlin96]

+1

[cwomack]

Hey @oemer-sellwerk 👋 . I was able to reproduce the issue by signing up a user in one tab and then confirming their code in a different tab (which is likely what happens if you're sending an emailed link). This results in the "autoSignIn_failure" error being returned from Hub. I'm going to review this with the team and get back to you on next steps for this issue, but let me know if there's any additional context/updates that happen in the mean time.

[cwomack]

After discussing this with the team, we're going to label this as a feature request. Currently, it's not a default behavior for Cognito to utilize a redirect link in emails for a new user to sign up.

[chrisbonifacio]

A potential workaround to autoSignIn on another tab might be to setup a storage event listener that checks if the cognito access, id, and/or refresh tokens have been stored locally. The storage event listener will trigger if localStrage has changed from another page on the same domain, so the other tab will reload or redirect, whatever you need it to do to update state and login/logout.

something similar to this

    const storageListener = (event) => {
      console.log(event);

      if (
        event.key?.includes("CognitoIdentityServiceProvider") &&
        event.oldValue === null &&
        event.newValue !== null
      ) {
      // handle tokens being added (login) or removed (logout)
        window.location.reload();
      }
    };

    window.addEventListener("storage", storageListener);

    // cleanup
    window.removeEventListener("storage", storageListener);

[masteruser20]

+1

[ARJUNSV01]

Any solutions on this issue?

[ARJUNSV01]

I have made a Phonenumber,OTP signup and signIn in my app. In the signup page, when the user enter the phonenumber and clicks the signup button, an OTP will be sent to their phone and the field to enter OTP will appear on the screen. If the user enters the otp and submit it , he would be signedUp and also gets automatically signedIn as I have enabled the autosignIn. But , if he doesnt enter the OTP and reloads the Page, then he have to enter the phonenumber again and OTP will be sent to his phone and he will be prompted to enter the OTP. If the user enters the OTP , this time the autosignIn is not working.

Is there any solution to this issue?

[noahfaro]

After discussing this with the team, we're going to label this as a feature request. Currently, it's not a default behavior for Cognito to utilize a redirect link in emails for a new user to sign up.

Hi @cwomack , just wanted to reference this being classified as a Feature Request - given that this is happening for the default option of emailed confirmation codes as well as the other option of emailed links, I do believe this is essential for this to be fixed by the Cognito team and is not just a new feature to be added. It disrupts the user flow that the autoSignIn feature is meant to solve.

To reiterate the steps to reproduce the issue and show that they are consistent with the default options of Cognito's verification system, reference below:

1. User signs up on app.
2. User receives email confirmation code, but does not use it and exists the app's browser tab.
3. User reopens app and signs in, as they already have an account (unconfirmed).
4. User is sent a new email confirmation code.
5. User confirms code on app, which results in an autoSignIn_Failure.
6. User now has to reinput their username and password and sign in again to get a session.

Since it has been over 3 years since this issue was initially opened on https://github.com/aws-amplify/amplify-js/issues/2562 , I and many others would love if this issue could be resolved. We appreciate any help that you can give.

[ghost]

+1

[Cloud11PL]

Still an issue

[cwomack]

@noahfaro, appreciate the detailed reply and reproduction steps. We use the Feature Request label if it's not a bug and not an existing feature from the Amplify side.

I reviewed this issue again today with the team internally and it's now added to a list of Feature Requests that are blocked by and need to be reviewed with the Cognito Service team (hence the new labels). We'll update this issue with any progress as it comes.

[joroe]

+1

[sdedmlevi]

+1

[CarlosMMVieira]

+1

[TheTimeWalker]

Please don't endlessly post +1 without any context as this notifies everybody, like me, that are just silently subscribed to the issue. You can use the thumbs up reaction on the first post to show support for it. Though I would assume that there's no priority from thumbs ups or +1 messages.

[Arturo-Lopez]

1+

[davemackintosh]

Hi folks!

I fixed this problem by calling Auth.signIn each 5 seconds.

 await Auth.signUp({
        username: this.email,
        password: this.password,
        attributes: {
          given_name: this.firstName,
          family_name: this.lastName,
          birthdate: this.dateOfBirth,
         }
      })
        .then(() => {
          this.intervalId = setInterval(() => {
            Auth.signIn(this.email, this.password).then(data => {
              this.updateAuthState(data);
            });
          }, 5000);
        })
        .catch(async e => {
          await store.dispatch(
            "ui/setErrorMessage",
            `Error while creating account: ${e.message}`
          );
        });
    }

Because user and password are the correct one, you can call Auth.signIn as many times as you needed.

This is misleading and has nothing to do with the actual issue being reported.

[thesnups]

+1

[rogueturnip]

Has anyone had success with this in the v6 release? I just got hit by it. I've created a link that auto populates the code but it opens in another tab so has this redirect failure.

[OperationalFallacy]

A potential workaround to autoSignIn on another tab might be to setup a storage event listener that checks if the cognito access, id, and/or refresh tokens have been stored locally. The storage event listener will trigger if localStrage has changed from another page on the same domain, so the other tab will reload or redirect, whatever you need it to do to update state and login/logout.

@chrisbonifacio, thank you. It's a great idea, and it is working well.

I used a CustomMessage lambda that generates a confirmation link with a code, but instead of using hacky "backend" to run confirmation API call (I explain below why its hacky and not functional), I've added a simple page that parses URL, stores code and email in local storage. Auth page is using it to continue with the confirmation and signing in user.

URL: /signupcode?data=encodedUserInfor=&code=123123

And then in Auth component, I do this

useEffect(() => {
  const storageListener = (event: StorageEvent) => {
    if (event.key === "signUpConfirmation" && event.newValue) {
      try {
        const userConfirmEvent = confirmSignUpDecoder(event.newValue);
        if (route === "confirmSignUp" && !userConfirmEvent.confirmed) {
          confirmUser(userConfirmEvent);
        }
      } catch (error) {
        console.error("Error processing signUpConfirmation data", error);
      }
    }
  };

  const confirmUser = async (confirmEvent: userConfirmationEvent) => {
    let s: ConfirmSignUpOutput = {
      isSignUpComplete: false,
      nextStep: {
        signUpStep: "DONE",
      },
    };

    try {
      s = await confirmSignUp({
        username: confirmEvent.email,
        confirmationCode: confirmEvent.code,
      });
    } catch (error) {
      console.log("error confirming signup", error);
    }

    // User now confirmed, notify signupcode page it can be closed
    localStorage.setItem(
      "signUpConfirmation",
      confirmSignUpEncoder({ ...confirmEvent, confirmed: true })
    );

    // Auto signin user
    let t: SignInOutput = {
      isSignedIn: false,
      nextStep: {
        signInStep: "DONE",
      },
    };

    if (
      s.nextStep.signUpStep === "COMPLETE_AUTO_SIGN_IN" ||
      s.nextStep.signUpStep === "DONE"
    ) {
      try {
        t = await autoSignIn();
      } catch (e) {
        console.log("autoSignIn failed", e);
      }
    }
  };
}, [router, route]);

A few notes:

1. I believe confirmSignUp call requires user's email in the username param (I thought it would be the sub, as in CustomMessage Lambda example the Amplify encoding originally)

2. I'd like to understand how autoSignIn() works with the Authenticator. I'm using plain Authenticator UI without any low-level functions. There is useEffect that checks AuthenticatorRoute to match confirmSignUp state, and that magically works.

Finally, to add even more confusion with Authenticator and Auth modules, it is not clear why Amplify has the custom message functionality with a confirmation link in the form of this junky code:

ls ../xxx-api/amplify/\#current-cloud-backend/auth/xxx/assets/   
index.html spinner.js style.css  verify.js

It doesn't do much except makes a confirmSignUp API call in verify.js

function confirm() {
  const urlParams = new URLSearchParams(window.location.search);
  const encoded = urlParams.get('data');
  const code = urlParams.get('code');
  const decoded = JSON.parse(atob(encoded));
  const { userName, redirectUrl, clientId, region } = decoded;

  var params = {
    ClientId: clientId,
    ConfirmationCode: code,
    Username: userName,
  };

  AWS.config.region = region;

  var cognitoidentityserviceprovider = new AWS.CognitoIdentityServiceProvider();

  cognitoidentityserviceprovider.confirmSignUp(params, function (err, data) {
    if (err) {
      if (err.message === 'User cannot be confirm. Current status is CONFIRMED') {
        window.location.replace(redirectUrl);
      }
    } else {
      window.location.replace(redirectUrl);
    }
  });
}

As you can see, "hosted" confirmation is using these params in confirmSignUp:

    ClientId: clientId,
    ConfirmationCode: code,
    Username: userName, // sub

and for Authenticator UI I had to use a different set:

        username: confirmEvent.email,
        confirmationCode: confirmEvent.code,

It would be great if Amplify had some documentation about these nuances.

By the way, all that custom messaging is broken anyway; there is an issue somewhere that the cli is not deploying these files correctly. The Amplify team could clean it up to avoid confusing developers with this half-baked option.

[oemer-aran]

I used a CustomMessage lambda that generates a confirmation link with a code, but instead of using hacky "backend" to run confirmation API call (I explain below why its hacky and not functional), I've added a simple page that parses URL, stores code and email in local storage. Auth page is using it to continue with the confirmation and signing in user.

These workarounds are tedious and only work when the initial tab is still open. But what if the user just registered and opens his email on another device or the next day? Then the tab won't be open. We need a dedicated solution from the amplify team. This feature is essential for any smooth registration flow.

If possible I would suggest an Auth.confirmSignUp function that has an option of autoSignIn, which is independent of existing sessions and just works.

We are currently thinking of abandoning Cognito and look for other options, primarily because of this issue. Including other similar tickets, it's been more than 3 years.

[joroe]

This is an absolutely crucial feature. Looking at critical optimizations of our registration flow, using amplify is a major disadvantage. We do loose a lot of potential customers with this break in user-flow. All our competition can provide a seamless flow. It is just what users expect to work. This problem costs us money. Please do fix this now!

[brettstack]

This blog hints at combining Magic Links with the verification flow to achieve this. I haven't tried it myself, but it sounds interesting. https://www.zeile7.de/insight/user-authentication-with-aws-cognito/

And you can do some awesome things, like Magic Links or things like authentication via QR-Codes. It’s easy to implement – it’s called “custom challenges” within AWS Cognito. OK, easy if you know Cognito, Lambdas and understand the flows 😉 I used it for example to do an auto-login after the email was verified. It’s just one Lambda function away. OK, in this case, I needed three 😉 One for creating the magic link, one to verify it and another to determine if there is another challenge or the authentication was successful.

[alexan]

@brettstack which blog?

very disappointing that there is no movement in this topic

[OperationalFallacy]

This blog hints at combining Magic Links with the verification flow to achieve this. I haven't tried it myself, but it sounds interesting. https://www.zeile7.de/insight/user-authentication-with-aws-cognito/

This is great write up :)

When you see a blog about cognito listing shortcoming upfront and mentioning bad, ugly and worst 20 times combined - you know its good Lol

[Lschulzes]

If there is any need to move a session token around, we could send this over the email link for the next tab, the amplify team only needs to expose the session token on ConfirmSignUpOutput and allow us to pass it on autoSignIn as a parameter.

[NairiAreg]

My autoSignin is not working even in the same tab

[timheilman]

I also cannot get autoSignIn to work at all, even in the same session, same tab. After confirmSignUp is called, I get the expected response { isSignUpComplete: true, nextStep: {signUpStep: 'DONE'} }, however any call to the client from generateClient() in amplify v6 gives this error: 8069-503a136a0f5f1e58.js:1 NoValidAuthTokens: No federated jwt. This is from the same session, in the same tab. Perhaps it is because autoSignIn does not work in amplify v6? Or because this is a next.js app? Regardless, I will need to get a workaround in place that passes username and password through and calls signIn after confirmSignUp.

[raegen]

For us, autoSignIn doesn't work in the same tab either. Furthermore, it fails inconsistently, sometimes working, sometimes failing. Repeating the exact same steps in the exact same tab, no page (re)loads of any sort. Steps are the following:

• open one tab with the app, another with your mail client
• sign up
• confirm sign up by copy/pasting the code from the email
• autoSignIn
• signOut (not signing out prior to redoing the sign up leads to other issues, due to leftover state I suspect, NotAuthorizedException: Logins don't match)
• repeat the above steps

But then again, I just saw the brilliant way state is handled in the auth package jesus christ and it makes me wonder how anyone ever expected this to work exactly? Doesn't it make sense that the eslint rule wasn't created because someone got bored, but for an actual reason?

// TODO(Eslint): can this be refactored not using `let` on exported member?
// eslint-disable-next-line import/no-mutable-exports

There's even a TODO left (kudos to the author of the comment)

[oemer-aran]

So after several years, we did "unfortnately" create a custom auth flow with Cognito admin actions. This missing feature was one of the main reasons.

We use Auth.signUp only for validation now (e.g. if the user already exists). The confirmation will be very custom, as I will explain now.

After PreSignUp lambda was successful, we autoConfirm the user. This ensures that the PostConfirmationLambda is triggered. At this point the user is already created, which lets us use some Cognito admin actions.

In the PostConfirmationLambda we then call AdminSetUserPassword with a random generated password (like a code). We then call AdminCreateUser with MessageAction: "RESEND" to trigger the email including the generated password using CustomEmailSenderLamda.

After the user clicks on the email button link, we get the code from the URL and try to log him in. Then we show a Set Password Form where he can set his own password.

Now comes the part with auto sign in: Since the user enters his password AFTER receiving the email, we can immediately log him in with the new password. No autoSignIn needed.

Ofc, this is just a simplified description, but you should get the gist of it.

I don't like the fact we had to do so much on our own to achieve a basic auth flow, but it seems to work very well for some weeks now. Hopefully amplify team will find some time to fix this in the core.

[Lschulzes]

So after several years, we did "unfortnately" create a custom auth flow with Cognito admin actions. This missing feature was one of the main reasons.

We use Auth.signUp only for validation now (e.g. if the user already exists). The confirmation will be very custom, as I will explain now.

After PreSignUp lambda was successful, we autoConfirm the user. This ensures that the PostConfirmationLambda is triggered. At this point the user is already created, which lets us use some Cognito admin actions.

In the PostConfirmationLambda we then call AdminSetUserPassword with a random generated password (like a code). We then call AdminCreateUser with MessageAction: "RESEND" to trigger the email including the generated password using CustomEmailSenderLamda.

After the user clicks on the email button link, we get the code from the URL and try to log him in. Then we show a Set Password Form where he can set his own password.

Now comes the part with auto sign in: Since the user enters his password AFTER receiving the email, we can immediately log him in with the new password. No autoSignIn needed.

Ofc, this is just a simplified description, but you should get the gist of it.

I don't like the fact we had to do so much on our own to achieve a basic auth flow, but it seems to work very well for some weeks now. Hopefully amplify team will find some time to fix this in the core.

I have implemented a similar approach based of resetting the preset password, this workaround is cumbersome but strictly necessary to guarantee a competitive parity even while using cognito...

[scholtz-gnome]

I'm running into a similar issue. Sad to see it's been so many years without a solution that doesn't involve a bloated workaround.

The way I understand the problem is that aws-amplify/auth doesn't consider a user authenticated once they have signed up with signUp(). In a custom implementation, one might store a user's email and password but disallow them from using the rest of the app until they have verified their email. However, although Cognito stores the user on their backend, they don't expose that through aws-amplify/auth for one's app to make that decision yourself. You need to keep calling signUp() and handle the rest based on the (failed/unauthenticated) response from that each time.

[Ladvace]

same problem here

[yinka0136]

I am surprised this is still an issue after 2 years. Has anyone implemented autoSignIn recently?

[oznekenzo]

the way it works and its proper implementation is also hardly discussed in the documentation