NEVER

Never auto-login based on links that are received by email.

There are an infinite number of scenarios that can cause the email to reach someone else and / or the email being read by third parties.

This poses a high security risk because you are giving access without credential validation! If the email is not in the hands of your real owner, you can access the supposedly protected area with nothing more than a click on a link ... imagine the sea of problems that come from it!

I suggest that you rethink the strategy in order to ensure that the link works but the user always has to enter at least a password.

Recommendation

I suggest that login is always done through user input, where after successful validation you can direct it to the hyperlink page in the email:

• In the email comes the link:

    

  link

• When you get to the page with no login:

  // apanhar URL atual
  $urlAtual = "http://$_SERVER[HTTP_HOST]$_SERVER[REQUEST_URI]";
  
  // guardar na sessão
  $_SESSION["minhaSessao"]["redirect"] = $urlAtual;
  
  // login e tal...
  
  // login correu bem, direcionar:
  header('Location: '.$_SESSION["minhaSessao"]["redirect"]);
  

Note:
The success of this operation and / or methodology varies depending on how the login is performed and how the session is handled.

You can add a column called token to the users table and every time you need to send a notification, generate a new token and send the link to an activation route where you can read the token you sent.

You can generate the token as follows:

$token = bin2hex(openssl_random_pseudo_bytes(16));

The route would be something like:

www.seusite.com.br/ativa-notificacao/a127be805346054046f75a31f8e4043d

On this page you should check if there is any user on your system with this token , if so, you will get the information from that user and save what you need in the session, as if he had logged in.

When token is validated and logged in on your system, delete the user's token and only generate another one when you need to send another notification. This process is very important, otherwise someone may have access to another user's token and log in to their name.

I suggest this solution because I use this to validate emails when someone creates an account on my system, I send an activation email.

Authenticating a user directly from an email, while being a very interesting feature from a user experience point of view, needs to be implemented with care and balance from the point of view of system security.

I will present some approaches, which include some things that the other answers have already spoken.

Concern about Security

As @Zuul mentioned, email link authentication is a major security issue. This includes two main reasons:

Even so, we can think of ways to improve the user experience with direct links without compromising security.

Login with redirect

The safest and easiest way to experience the user is to have the email link point to a page that performs the following:

In this approach, the original link can be stored in the URL itself. Examples:

• Email Address:

  http://servidor/administracao/secao1

• Login screen address:

  http://servidor/login?page=administracao/secao1

In this way after login you can find out which screen the user should be redirected to.

The approach with authentication causes the user to authenticate. However, the login can be kept for longer than the current browser session. For example, Evernote has a login option to "remind the user for a week". This means that the user would not have to authenticate for a week. Note that this is only feasible for private computers.

Login with token single

This is the approach mentioned by the @ gerep user. The idea is to generate a single token per link so that no one can guess it and then invalidate the token after its use.

The problem with this approach is that the user will certainly try to repeat the same action some time later and will have access denied. This is good from a security point of view, but a bad experience for the user.

Limited login with token

Another alternative that some sites like LinkedIn use is to generate a token that is not invalidated, however, it gives only restricted access to the system.

In the case in question, the token can only give access to the e-mail screen. Or maybe screens that are just data viewing.

If the user tries to access some action or edit in the system, then the complete login would be required.

Considerations

Finally, define the level of security and, depending on the system, you can use a mixed set of approaches.