Sign In with Auth.confirmSignUp

[mousedownmike]

Is your feature request related to a problem? Please describe.
This feature is related to closed issue #2562, that request was to support signing in a user with the Auth class when a successful Auth.confirmSignUp request was made. The ticket was closed based on a UI implementation that does not solve the issue for users of the Auth class directly.

Describe the solution you'd like
The Auth library should have the option to automatically sign-in a user when they successfully complete the Auth.confirmSignUp request. This should be made possible without requiring the calling application to persist the user's credentials (username and password) between requests.

The following would be my ideal use case:

1. A new site user is successfully registered with Auth.signUp. The site/app does NOT persist the user's password so it is no longer known by the local client.
2. The site presents the code delivery details (e.g. SMS, Email...) to the new user so they know where to find their confirmation code.
3. The site presents a form with a field for the username/email (pre-populated if the user has not left the flow) and an empty field for the confirmation code.
4. The user retrieves the confirmation code from the indicated delivery method.
5. The user enters the valid confirmation code (and username if not pre-populated) and submits the form.
6. The site successfully performs Auth.confirmSignUp with the supplied username and code.
7. The Auth library validates the username and code and upon receiving a valid response is able to generate a fully realized/signed-in CognitoUser locally. No further calls to Auth.signIn are required.

This flow is essentially using the confirmation code as a one-time password which seems reasonable.

Describe alternatives you've considered
Multiple alternatives are discussed in #2562 and the React UI implementation is one alternative although it appears to require persisting the user's password locally between requests which seems like a potential security risk.

Additional context
My assumption based on reading #2562 was that this would require some changes to the Cognito service. I imagine that is the case so that confirmSignUp returns a valid token but I can't find any tickets that represent that change request nor do I even know where to look for such a request.

[jordanranz]

Hey @mousedownmike,

To clarify on the closing of the other issue, this is now implemented in all framework UI implementations of Authenticator and not just React.

Alternatively, if you would like this functionality using only the Auth category, you would just call Auth.signIn on a successful Auth.confirmSignUp. That being said, maybe the functionality could be baked into the Auth.confirmSignUp, is that what you are asking for?

[mousedownmike]

Thank you for the response @jordanranz. I've updated the original post to remove mention of other UI frameworks and focus just on the use of the Auth class.

The request is to have the ability to get a signed-in user from Auth.confirmSignUp without providing the user's password. It appears that the React solution (and I presume the Angular solution) relies on having the user's password stored in the app so that it can be used to call Auth.signIn once a successful response from Auth.confirmSignUp is received.

• The solution I propose would help in cases where the user has started a new session after registering and before confirming their account (say the confirmation email was delayed for some reason or they just changed to a different task). In that scenario, the password should no longer be stored in cache/memory so it wouldn't be available to call Auth.signIn.
• This approach treats the username/confirmation-code as a temporary set of credentials. That's not really different from a password reset request so my preference is to take this approach over storing the user's password in the client.

I'm proposing that confirmSignUp return a promise with CognitoUser (possibly based on ConfirmSignUpOptions) giving something along the lines of:

public confirmSignUp(username: string, code: string, options?: ConfirmSignUpOptions): Promise<CognitoUser | any>

Under the covers, I would presume that if the confirmation were successful and a valid CognitoUser were returned, Auth.currentAuthenticatedUser would reflect that user.

Looking at the Cognito API documentation for ConfirmSignUp, it doesn't appear the Cognito APIs provide a trivial way to implement this so I'm guessing that this needs some support from the Cognito team.

Let me know if I can provide more information, I think it would improve the user and developer experience and possibly help keep things more secure. Thanks again!

[ianmartorell]

Hey @mousedownmike,

To clarify on the closing of the other issue, this is now implemented in all framework UI implementations of Authenticator and not just React.

Alternatively, if you would like this functionality using only the Auth category, you would just call Auth.signIn on a successful Auth.confirmSignUp. That being said, maybe the functionality could be baked into the Auth.confirmSignUp, is that what you are asking for?

I'm using email verification with a link, which I believe is the most common way of user confirmation on the Internet, and the approach you suggested won't work for those cases unless the password is stored in local storage, which definitely isn't a good idea. Ideally, confirmSignUp should sign the user in automatically, it feels like a no brainer to me.

[nickolanick]

Hey @mousedownmike,
To clarify on the closing of the other issue, this is now implemented in all framework UI implementations of Authenticator and not just React.
Alternatively, if you would like this functionality using only the Auth category, you would just call Auth.signIn on a successful Auth.confirmSignUp. That being said, maybe the functionality could be baked into the Auth.confirmSignUp, is that what you are asking for?

I'm using email verification with a link, which I believe is the most common way of user confirmation on the Internet, and the approach you suggested won't work for those cases unless the password is stored in local storage, which definitely isn't a good idea. Ideally, confirmSignUp should sign the user in automatically, it feels like a no brainer to me.

One approach might be the following - on the signUp page user enters the credentials and the confirmation link is sent to our email. Meanwhile, the user is going through the confirmation process, we can try to sign in once every second on the signUp page because we have the credentials in our client memory. The first few requests will fail, with an error of non-confirmation, but after our client clicks the confirmation URL, the user will be automatically signed in, because our request will no longer fail.
The part with checking every few seconds did the user confirm the email is a bit tricky, but in this case, we don't need to save our password in any local storage.

[ianmartorell]

One approach might be the following - on the signUp page user enters the credentials and the confirmation link is sent to our email. Meanwhile, the user is going through the confirmation process, we can try to sign in once every second on the signUp page because we have the credentials in our client memory. The first few requests will fail, with an error of non-confirmation, but after our client clicks the confirmation URL, the user will be automatically signed in, because our request will no longer fail.
The part with checking every few seconds did the user confirm the email is a bit tricky, but in this case, we don't need to save our password in any local storage.

I guess that approach would work in some cases, but it requires you to implement checking whether the user is now signed in repeatedly on the confirmation page. If you're simply redirecting after confirmation, then it's a race condition with the sign in requests. And what if the user closes the sign up browser tab? Or if they're on mobile, will the background tab still be able to send the requests?

It gets a lot trickier when the simpler and surefire way is to sign the user in automatically after confirming their account. If their action allowed them to confirm their account, we know for sure they're who they claim to be, so there's no reason to not sign them in.

[jefelewis]

I'm having the exact same dilemma. Has there been any resolution to this? These are the issues I'm having/possible scenarios, but I feel like there should be an easier way.

Overview:
After the user receives a Verification Code, the user enters the Verification Code, and the Account Status becomes CONFIRMED. Now that the sign up process is completed, I want to automatically sign in the user in after. It seems inefficient and redundant to redirect the user to the Sign In page to have user enter their information and sign in.

Possible Solutions:

1. Create a confirmSignUpAndSignIn method that does what confirmSignUp does, but signs in the user after. Use the email and password from the sign up process and then dispatch the signIn action to sign in the user, but that creates a security risk as mentioned above + edge case if the user doesn't confirmSignUp right away.
2. With the AWS Amplify Hub (Auth Listener), emit a confirmSignUp event to keep track of the user confirms the sign up process.

Possible Amplify Enhancements:

1. Find a way combined method for both confirmSignUp and signIn, which would be something along the lines of confirmSignUpAndSignIn (If a method exists). I have looked through the AWS Docs and through the issues Amplify-js Github Repo, but have only found that others have had a similar dilemma with no apparent resolution. @mousedownmike would that be a possible solution to add a new confirmSignUpAndSignIn method?
2. Use the AWS Amplify Hub (Auth Listener), but there aren't any events emitted when the user confirms sign up. It would make sense that confirmSignUp would emit an event, but it doesn't. (See Below)
   Additional context

I'm using the AWS Amplify Hub (Auth listener) and the only events that are emitted are the following from the docs:

    case 'signIn':
        logger.error('user signed in'); //[ERROR] My-Logger - user signed in
        break;
    case 'signUp':
        logger.error('user signed up');
        break;
    case 'signOut':
        logger.error('user signed out');
        break;
    case 'signIn_failure':
        logger.error('user sign in failed');
        break;
    case 'configured':
        logger.error('the Auth module is configured');

[ianmartorell]

I'm using verification by link and as it currently stands I see no possible way to reliably (and securely) sign users in after confirming their account. This would have to be integrated into the confirmSignUp method. 😕

[mousedownmike]

Until this gets resolved, my low tech solution is to redirect the user to the sign-in page with their email address pre-populated and the following message:

You have successfully verified your account, for security purposes, please sign in to access the service.

Onboarding users is something I want to make as frictionless as possible and this is the best approach I've come up with in light of the confirmSignUp limitations. It's not great, but it's something the user experiences only once so it isn't the end of the world.

[jefelewis]

Until this gets resolved, my low tech solution is to redirect the user to the sign-in page with their email address pre-populated and the following message:

You have successfully verified your account, for security purposes, please sign in to access the service.

Onboarding users is something I want to make as frictionless as possible and this is the best approach I've come up with in light of the confirmSignUp limitations. It's not great, but it's something the user experiences only once so it isn't the end of the world.

Thanks for the help! This seems like the best route as that I'm not storing the password anywhere. Autofill should also come up on web or iOS/Android.

Ultimately, the less steps the better and it would flow better if it automatically logged in. I think Amplify should improve confirmSignUp to automatically sign in the user in OR add a new method of confirmSignUpAndSignIn to automatically sign in after signing up.

[mousedownmike]

@ashika01 and @elorzafe, is there a public roadmap for Cognito and Amplify JS? It feels like both are due for a significant revision and I'm wondering if it's time to start looking at alternatives or continue waiting for improvements.

[jjalonso]

Totally agree, on all websites when you sign up, you are already signed in, it should be already available like firebase and the rest of the world does, we use Amplify to have a almost-ready-easy-to-use platform and doing that is quite bad for us/it

[mikerudge]

+1

[enhancement-ventures]

+1

[liamlevesque]

+1

[karray3000]

+1, I wonder if it's possible to generate a one-time sign-in token from the Cognito API in general?

[dwhiteGUK]

+1

[piotrmoszkowicz]

+1

[bmovement]

This has been an issue for 5 years: amazon-archives/amazon-cognito-identity-js#186

The problem is much worse if you have enforced 2FA, as the user has to perform the verification twice, back to back. I wish our company hadn't selected Cognito for auth.

[Arvanaghi]

Brutal. This feature needs to be added.

[jrnewton]

Anyone have recommendations for a Cognito alternative that works well with AWS? I've got a lot of API Gateway services that I'd like to migrate sooner than later based on this issue.

[disbelief]

@jrnewton if I were starting from scratch today I'd go with Auth0.

[kyokosdream]

@aws-amplify it doesn’t breed trust with the community when you delete someone’s comment that mentions a competitor’s authentication service. There’s enough censorship in the world already for you guys to be deleting people’s GitHub comments.

We’re all trying to solve a problem here. Please be more constructive.

[elorzafe]

@mousedownmike @ianmartorell @nickolanick @jefelewis @jjalonso @mikerudge @enhancement-ventures @liamlevesque @karray3000 @dwhiteGUK @piotrmoszkowicz @bmovement @Arvanaghi @jrnewton @disbelief @dlamon1 @mashuoyi111 @Crashtor @dan-cooke @matthewtmoran @jonatassales @zakyg @geauser @AchrafBn @shawn-southwell @dlamon1 @kyokosdream @oemer-sellwerk

Today we released autoSignIn feature on Amplify JS. We will be updating the docs tomorrow, but the feature is available now on version aws-amplify@4.3.29

If you are using code verification for new users you only have to do.

 Auth.signUp({
      username: 'xxxxxx',
      password: '*********,
      attributes: {
        email: 'xxxxxxxxxx'
      },
      autoSignIn: {
        enabled: true
      }
    })

The library will login in the user automatically after the user is confirmed on the App when doing Auth.confirmSignUp

If you are using link verification the library also handle that case but you need to configure the library is using link verification on Amplify.configure like this

Amplify.configure({
    Auth: {
       // OPTIONAL
       signUpVerificationMethod: 'link'

        // REQUIRED only for Federated Authentication - Amazon Cognito Identity Pool ID
        identityPoolId: 'XX-XXXX-X:XXXXXXXX-XXXX-1234-abcd-1234567890ab',
        
        // REQUIRED - Amazon Cognito Region
        region: 'XX-XXXX-X',

        // OPTIONAL - Amazon Cognito Federated Identity Pool Region 
        // Required only if it's different from Amazon Cognito Region
        identityPoolRegion: 'XX-XXXX-X',

        // OPTIONAL - Amazon Cognito User Pool ID
        userPoolId: 'XX-XXXX-X_abcd1234',

        // OPTIONAL - Amazon Cognito Web Client ID (26-char alphanumeric string)
        userPoolWebClientId: 'a1b2c3d4e5f6g7h8i9j0k1l2m3',

        // OPTIONAL - Enforce user authentication prior to accessing AWS resources or not
        mandatorySignIn: false,

    }
});

Also if the user is autoConfirmed the library will sign in the user as well automatically.

Amplify will emit the event that the user is signed in, or in case you have to use MFA you can use it as well.

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
        }
    })
}

[abdallahshaban557]

We also have documentation available here now! https://docs.amplify.aws/lib/auth/emailpassword/q/platform/js/#auto-sign-in-after-sign-up

[bakerue-owner]

Wow this is amazing timing...I've moved from Cognito to Next-Auth to Auth0 to Cognito (Again!). I implemented it yesterday and ran into this login UX issue.. I found a post from 2016 that pointed me to this post. And happy to read that AWS just fixed it TODAY! 👯

Will now try the fix and report.

UPDATE: Works like a charm! Thank you Amplify team!

[dlamon1]

Thank you amplify team for adding this feature!👍

…

On Fri, Jul 29, 2022 at 8:19 PM Bakerue ***@***.***> wrote: Wow this is amazing timing...I've moved from Cognito to Next-Auth to Auth0 to Cognito (Again!). I implemented it yesterday and ran into this login UX issue.. I found a post from 2016 that pointed me to this post. And happy to read that AWS just fixed it TODAY! 👯 Will now try the fix and report. — Reply to this email directly, view it on GitHub <#6320 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKJQCJ54FZMO6TIHY7MITZDVWSNKHANCNFSM4OZPM72Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[kyokosdream]

@helgabalashova @elorzafe Thank you for being responsive to this issue lately and for getting this done. Developers all around the world myself included thank you for making it easy to develop smooth authentication flows with AWS.

[OrelVaizman]

@mousedownmike @ianmartorell @nickolanick @jefelewis @jjalonso @mikerudge @enhancement-ventures @liamlevesque @karray3000 @dwhiteGUK @piotrmoszkowicz @bmovement @Arvanaghi @jrnewton @disbelief @dlamon1 @mashuoyi111 @Crashtor @dan-cooke @matthewtmoran @jonatassales @zakyg @geauser @AchrafBn @shawn-southwell @dlamon1 @kyokosdream @oemer-sellwerk

Today we released autoSignIn feature on Amplify JS. We will be updating the docs tomorrow, but the feature is available now on version aws-amplify@4.3.29

If you are using code verification for new users you only have to do.

 Auth.signUp({
      username: 'xxxxxx',
      password: '*********,
      attributes: {
        email: 'xxxxxxxxxx'
      },
      autoSignIn: {
        enabled: true
      }
    })

The library will login in the user automatically after the user is confirmed on the App when doing Auth.confirmSignUp

If you are using link verification the library also handle that case but you need to configure the library is using link verification on Amplify.configure like this

Amplify.configure({
    Auth: {
       // OPTIONAL
       signUpVerificationMethod: 'link'

        // REQUIRED only for Federated Authentication - Amazon Cognito Identity Pool ID
        identityPoolId: 'XX-XXXX-X:XXXXXXXX-XXXX-1234-abcd-1234567890ab',
        
        // REQUIRED - Amazon Cognito Region
        region: 'XX-XXXX-X',

        // OPTIONAL - Amazon Cognito Federated Identity Pool Region 
        // Required only if it's different from Amazon Cognito Region
        identityPoolRegion: 'XX-XXXX-X',

        // OPTIONAL - Amazon Cognito User Pool ID
        userPoolId: 'XX-XXXX-X_abcd1234',

        // OPTIONAL - Amazon Cognito Web Client ID (26-char alphanumeric string)
        userPoolWebClientId: 'a1b2c3d4e5f6g7h8i9j0k1l2m3',

        // OPTIONAL - Enforce user authentication prior to accessing AWS resources or not
        mandatorySignIn: false,

    }
});

Also if the user is autoConfirmed the library will sign in the user as well automatically.

Amplify will emit the event that the user is signed in, or in case you have to use MFA you can use it as well.

Hub.listen('auth', ({ payload }) => {
     const { event } = payload;
     if (event === 'autoSignIn') {
          const user = payload.data;
     }
    // ...
})

This feature is so necessary and its blessed that you've made it. However - no documentation for a failed event. Now go figure out the following results:

{event: 'autoSignIn_failure', data: null, message: 'autoSignInError'}

[elorzafe]

@OrelVaizman

We can improve our docs to make more clear, currently on Auto Sign In after Sign Up docs we have this.

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
        }
    })
}

I will add the event information also on Auth events section

[OrelVaizman]

@OrelVaizman

We can improve our docs to make more clear, currently on Auto Sign In after Sign Up docs we have this.

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
        }
    })
}

I will add the event information also on Auth events section

Yes I could see this. I have a flow where a user first signs up to cognito, then confirms himself "by code" - I pass the code & username through URL to my frontend from a lambda trigerred by "CustomMessage_SignUp".

I am confirming the signup on the front once he visits the link. Listening to the events of autoSignIn and I get the failed event.

What I am saying is that you can't know why it failed or what went wrong, and the fact that this feature is so new also puts the case in troubles. Perhaps its good to document it properly on the firstplace. Anyway if you have any clue or idea, would love to hear.

[elorzafe]

@OrelVaizman

Thanks for your feedback, we can always improve our docs to make it more clear for our customers.

The use cases Amplify is supporting are this:

1. User confirmation by code -> this means the app calls Auth.signUp and then on the same app is called Auth.confirmSignUp.
2. User confirmation by link -> this means the app calls Auth.signUp (lets call that env1) and then the user press the link on the email (env2). Then env1 will be automatically logged in.
3. User verified automatically during sign up -> this means app calls Auth.signUp and then the user is logged in immediately.

In your use case it seems you have 2 enviroments.
Front-end-1 -> here the user signs in
Front-end-2 -> the link that user pressed to confirm the user

I think what you can do here is similar to use case 2. In that case when your user pressed the link Front-end-1 will be automatically logged in after the user presses the link. Unfortunately Front-end-2 cannot be notified automatically that the user is signed. Can this solved your problem?

[OrelVaizman]

@OrelVaizman

Thanks for your feedback, we can always improve our docs to make it more clear for our customers.

The use cases Amplify is supporting are this:

1. User confirmation by code -> this means the app calls Auth.signUp and then on the same app is called Auth.confirmSignUp.
2. User confirmation by link -> this means the app calls Auth.signUp (lets call that env1) and then the user press the link on the email (env2). Then env1 will be automatically logged in.
3. User verified automatically during sign up -> this means app calls Auth.signUp and then the user is logged in immediately.

In your use case it seems you have 2 enviroments. Front-end-1 -> here the user signs in Front-end-2 -> the link that user pressed to confirm the user

I think what you can do here is similar to use case 2. In that case when your user pressed the link Front-end-1 will be automatically logged in after the user presses the link. Unfortunately Front-end-2 cannot be notified automatically that the user is signed. Can this solved your problem?

Thank you for your reply.
I must say that even if this feature was planned this way, that the automatic sign in will be existing only at the signed up user tab then it's just horrible by my opinion. My use case is probably very common for this feature, and why limiting the users on different tabs and make it harder then it is already. In my use case I have another step after confirmation where I would like to request for personal details for my db, and now I am forced to ask the user to sign in in-between. It just ruins the user experience and there's no way out if you're customizing some confirmation link.

Anyways, as you described the auto signin should've worked at the first tab where the user signs up at, and yet I could see any event there, I can only see a failed event at the link that the user clicked on the email, but I couldnt see any event on the other page where the user signed up at.

[wangf1978]

If end-user input the verification code to confirm the email in another session, this new autoSignIn does not work, here is the scenario I hit:

1. Sign up with the specified userID and password
2. Refresh the page, and go into the sign in page w/o inputting the verification code to confirm the email
3. Input the userID and password, and redirect the left sign-up process
4. After inputting verification code, and confirm the email, but no way to sign in automatically

How to solve this case?

[oemer-aran]

I have the same problem, that autoSignIn only works if the user remains on the same tab after signUp, here is my scenario:

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

(Side note: The user also has the possibility to directly copy the code from the mail and paste it into an input field. This approach works with autoSignIn, since the user remains on the same tab)

I took a look into the code already, and it makes total 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, autoSignInInitiated is obviously still false.

The question now is: Is this intended to work only in the same tab/session or can we extend the feature so it works for every scenario? Logically it makes more sense to me to put the autoSignIn: { enabled: true } option to the Auth.confirmSignUp function. Is this technically possible?

[abdallahshaban557]

Hi @oemer-sellwerk - can you please submit a new Github issue for us to track this ask?

[ataibarkai]

To confirm I understand --
Auto-signin after signup is now possible even when using 2FA with a text message code?
I.e. the user won't have to enter 2 confirmation codes on initial signup/signin?
All you need is to set signUpVerificationMethod to code?

If so -- fantastic news!

When is this coming to iOS?

[abdallahshaban557]

@ataibarkai - unfortunately, the user would still need to enter two confirmation codes. One for user confirmation, and the other for 2FA. This is a limitation that has been communicated to the Cognito team.

[bmovement]

@ataibarkai - unfortunately, the user would still need to enter two confirmation codes. One for user confirmation, and the other for 2FA. This is a limitation that has been communicated to the Cognito team.

Wow, that’s quite a limitation. Good to know, thanks.

[wangf1978]

@abdallahshaban557 This autoSignIn does not introduce clientMetadata/ValidationData in signUp to PreAuthentication_Authentication and PostAuthentication_Authentication trigger, is it possible to keep the client metadata of context?

[littlefeatheradmin]

@ataibarkai - unfortunately, the user would still need to enter two confirmation codes. One for user confirmation, and the other for 2FA. This is a limitation that has been communicated to the Cognito team.

Is there any progress on this issue? Is there any recommended workaround?

UX vice we're either forced to remove MFA (which would be unacceptable security vice) OR skip autoSignIn. The current flow is both confusing to most users and it looks unprofessional :(

[MikeSchlosser16]

@ataibarkai - unfortunately, the user would still need to enter two confirmation codes. One for user confirmation, and the other for 2FA. This is a limitation that has been communicated to the Cognito team.

Is there any progress on this issue? Is there any recommended workaround?

UX vice we're either forced to remove MFA (which would be unacceptable security vice) OR skip autoSignIn. The current flow is both confusing to most users and it looks unprofessional :(

I totally agree with this - still no updates?

[ponyshchen]

@ataibarkai - unfortunately, the user would still need to enter two confirmation codes. One for user confirmation, and the other for 2FA. This is a limitation that has been communicated to the Cognito team.

Is there any progress on this issue? Is there any recommended workaround?
UX vice we're either forced to remove MFA (which would be unacceptable security vice) OR skip autoSignIn. The current flow is both confusing to most users and it looks unprofessional :(

I totally agree with this - still no updates?

Is there any workaround or bug to track this issue?