An automatic login URL is a mechanism whereby an existing but logged out user of your website or application can click a link with a random token and be automatically recognized and logged-in to your website. Often these mechanisms are used in other fashions such as password resets.

I am wondering what some "defense in depth" security measures are that you suggest when building an "automatic login" mechanism that reduces risk of user account compromise.

Is there anything that can be done beyond the typical measures?

  • Token with short expiration time
  • Token that can only be used once

2 Answers 2


In addition to ensuring a token is single use, has a short expiration and that the token is sufficiently random and long:

  • I'd recommend limiting the number of valid tokens in existence at any given time (preferably to 1). That way your exposure to compromised codes is limited to a fixed number.
  • Having the code in the parameters of a GET request will expose the code in most HTTP logs (eg. browser history). This is mostly mitigated by making the codes single use, but ideally you'd only send them the login link without the code embedded and make them copy the code from the email to the login page manually.
  • 1
    Justification for #2 - Google being too smart and visiting any link you feed it in your mail. Mar 6, 2016 at 21:36
  • History can be a security issue, but that is mitigated by having the links one-use. Sending a code inside email and have them copy the code, is not more secure than having it in a GET request. When it comes to short lifetime, I would recommend that it can only exist one token for a specific account at a time, but the lifetime should preferable be longer than 24 hours. The reason is that some providers employ forced-greylisting with no recourse for the end user to whitelist users, which will delay all mail with a couple of hours, normally 12-24 hours. Mar 7, 2016 at 1:36
  • However if you can insert a feedback loop between the mailserver and your authentication script, you can have as short lifetimes as 15 minutes-1hour, by ensuring that the code isn't starting to be valid before the target mailserver confirms successful delivery. Mar 7, 2016 at 1:38
  • @sebastiannielsen a one-time code significantly reduces the threat, but doesn't entirely eliminate the it. Say the server is down or an attacker interferes with the connection, then the one-time code will be in the history but the code won't be invalidated on the server side. Plus, there's the issue Deer Hunter mentioned.
    – thexacre
    Mar 7, 2016 at 2:23
  • The #2 can be solved by having a button that must be pressed to continue. Google won't press the button, thus the link will only be invalidated when the button is pressed. The second issue by server is down, or attacker interferes with the connection, can be solved by user education, by telling the user that the link is sensitive and should not be visited from public computers or computers that others have access to. Even typed codes are saved very often, so that is just adding a inconvience for the user to have to type a code, while it barely adds to security. Mar 7, 2016 at 2:27

If possible, learn where you user typically comes from (geo-locate their IP addresses). If that single-use token is used from an unusual location, don't authenticate them.

This way you can hopefully prevent account compromises from email account hijacking, or MiTM of the emails (which are plaintext, remember!).

(Ideally you wouldn't have to implement a feature like this, because of the security risks!)

  • You can insert a feedback loop between the mailserver and your login solution, such as different solutions are used depending on the target server supports (and uses) STARTTLS or not. Eg, you can send a less-secure link to someone via STARTTLS, and a more restrictive link to someone who don't support STATTLS. If the mail goes under a STARTTLS session, then it wont be in plain text. Mar 7, 2016 at 1:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .