When signing up for a new account with a web application, it is standard to send a validation email. I don't want to go into the pros and cons of the validation email though.

When receiving a validation email and following the validation link, an application will typically show some screen letting you know that your email address has been validated. At that point there are one of two options.

  1. Let the person sign into the application with their username & password (or some such combination).
  2. Automatically sign the person into the application with the appropriate account and let them start doing whatever it is that you do with the application.

Option 1 appears better security wise, while option 2 gives the person less to do - better UX wise.

When does it justify making a security tradeoff (option 2) for a better initial user experience?

  • 9
    God, number 1 is one of my pet peeves... especially because I tend to immediately confirm my email, so the flow for me is fill out form > check email/click confirm > return to site as authenticated user. If, after doing that, I have to log in again, it drives me up the wall! At the very least, allow your users who are confirming their email address in the same session as they create the account to just be logged in, please! Commented Dec 15, 2011 at 17:53
  • @DanielNewman You should make that into an answer - I like the idea of option 2 if within same session, and option 1 otherwise - ensuring that the workflow loop you describe above is maintained if at all possible - and when it works it feels real nice. Commented Dec 15, 2011 at 22:14
  • @RogerAttrill Answered, as requested. Commented Dec 15, 2011 at 22:46
  • good job +1'd you. Commented Dec 15, 2011 at 22:57

6 Answers 6


Number 1 is one of my pet peeves... especially because I tend to immediately confirm my email, so the flow for me is fill out form > check email/click confirm > return to site as authenticated user. If, after doing that, I have to log in again, it drives me up the wall! At the very least, allow your users who are confirming their email address in the same session as they create the account to just be logged in, please!

For all others (or for cases where the session data is unclear), requiring them to log in again is fine.

One thing to consider is whether you even really need the user to confirm their email address before using your service. At my organization, we have some applications that allow a user to sign up and start using them right away. They receive a email confirmation message, but are not required to actually complete the confirmation prior to beginning to use the service. This works best when there is no real consequence to impersonating another user -- I would not recommend it for social apps. For instance, compare Facebook's sign-up process to Twitter's... Facebook requires you to confirm your email address before using the service; Twitter allows you immediate access to the service (but with restrictions on what you can do).

One other option is to leverage the email confirmation as a strength... Web time management tool Nozbe only requires the user to enter a name/email address (no password!) when they fill out the registration form, and after the user has confirmed their email address, they are taken back to the app to choose a password. This progressive engagement method is (apparently) successful for them (Example via UX And All).

  • +1 Nice differentiation based on the session. Makes for what seems to be the best of both worlds.
    – JohnGB
    Commented Dec 16, 2011 at 7:42

There's an issue where multiple people share an email; husbands and wives often do this. With Option 1 anyone can validate your account (which isn't a big deal), but since they have access to the email but not the password information, they won't have access to the other person's account.

Another problem with logging them in automatically is they may be checking the validation email from a browser other than their usual, personal computer. They may have opened it on their phone, their work PC, even a public library machine. This machine will stay logged in as long as you allow your sessions to exist.

For a service like Facebook this could give this other computer to sensitive information for a very long time (facebook leaves you logged in for days). Users are often unaware of the need to "log out" of such services as well; hence the numerous stories of Facebook accounts "hijacked" or "hacked" when people leave their facebook account logged in at work, at school or on a demo Laptop or Smartphone.

Since users often don't log off of websites, logging them on by default could easily leave them in a (dangerous) situation where they aren't in direct control of the state of the system (being logged in) and may not know how to correct the situation or worse they may not know such a problem exists at all.

  • Sometimes logging out of a service isn't enough, but Facebook is the only service I'm aware of with that, shall we say, feature.
    – Ben Brocka
    Commented Dec 15, 2011 at 19:04
  • 1
    Husbands and wives often do this? Really? I'd go nuts if I got all my wifes email! DELETE DELETE DELETE! Commented Dec 16, 2011 at 18:50
  • I am logged into Gmail for weeks. And I log into from mutliple locations with multiple devices.
    – Evik James
    Commented Dec 19, 2011 at 22:38

It depends on your application. #2 makes for a seamless experience but if you have sensitive information stored about the user, I'd suggest leaning towards #1. By "sensitive" I mean anything from storing their mailing address to preferences about what type of information they receive.

I speak from experience -- I have a @gmail address that is my first and last name together. My name is fairly common so I often get emails intended for someone that likely are supposed to have a middle initial in there or maybe a number at the end. I've received these exact "account confirmation" emails that were intended for someone else. And this happened because people mistype their own email addresses all the time. I've received emails from systems that use the #2 approach and have been able to see details that I certainly shouldn't have access to.

If you do go with #2, be sure that the sign-up form requires that you enter your email twice and then performs the usual validation.

  • If as Daniel says above, option 2 happened only within the same session, that should avoid the problem you describe above. If original session has timed out or it's a different computer then option 1. Commented Dec 15, 2011 at 22:11
  • 1
    Thanks for pointing that out Roger. Yes, keeping it in the same session would IMO make #2 worthwhile. Not all developers have implemented that as I've found out.
    – Voodoo
    Commented Dec 16, 2011 at 1:26

I think the ideal situation will generally fall somewhere in between the two examples. Of course some sites will need to focus more or less on security.

In general there are going to be two cases after that, immediate activation and delayed activation. If the email link is clicked immediately there is little need to force the user to log back in. However if they don't click the link until the next day or two a log in is likely needed.


The other answers are long and comprehensive so I'll throw my two cents: use OpenID!

It's simple, It's easy for both the developer and the user, it is used by Stack Exchange sites and it will make both power users and dummies happy either because they expected it or because they didn't. It's such a shame having a zillion accounts and having to make up logins for each,

  • 1
    Have you done any usability testing with using OpenID with the average person?
    – JohnGB
    Commented Dec 21, 2011 at 15:33
  • @JohnGB no, but who doesn't have a GMail, etc. account already? If it's implemented like in SE sites (and it can be further dumbed down), I think a grandma with a computer gets logged in. It can even be worded differently, as in "do you have a mail account? Use it as your login!" and big buttons with e-mail providers that support OpenID. Commented Dec 22, 2011 at 3:50
  • I think you are confusing OpenID with OpenAuth.
    – JohnGB
    Commented Dec 22, 2011 at 16:08
  • @JohnGB Am I? In my understanding, OpenID is a login system (i.e., click the FooMail button and a FooMail page asks if the BarApp should have your name and e-mail address (sent securely by a trusted provider e.g., GMail and Facebook)) and OpenAuth is a content-sharing system (i.e., FooGallery asks you if it can share your photos with BarCloudPrint). en.wikipedia.org/wiki/… Commented Dec 23, 2011 at 4:14

I think the answer is NOTHING. Well, I really mean that email validation should be treated as validation of email, no more no less.

If the user already has an active/authenticated session, let it be. If not, let them sign in.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.