User hash to use in a link

Just wondering about 3 things, hope you can provide your view on these questions:

1. Should such a request only provide access to the given destination as a single page request or should the user who belongs to the given hash be authenticated, i.e. such that a session gets created, and they can continue navigation as a logged-in user after that?
2. If the user is already logged in as another user, this request should be skipped. In other words, the request only works for anonymous users?
3. If the URL really should be /authenticate/[hash]?dest=[target], if this is being used without a destination, should that URL be available for a simple login mechanism without username and password?
4. An alternative URL pattern could be to use any regular path of the current site and just add ?auth=[hash]. That way we wouldn't have to implement a redirect but only decide if an otherwise hidden page would be accessible because of the given hash.

Ad 1: I prefer a session to be created. Anything else will supposedly be harder to explain to users.
Ad 2: If the user should already be logged in as the intended user, only the given target should be reached. If it should be a different user, either creating a new session for that one or throwing an error would be desirable.
Ad 3: Yes. The hash however will have to be regenerated from time to time for security reasons. I'd expect that ECA can do that.
Ad 4: Sounds like a good idea. I was simply wondering how to invoke the authorization check. If that can be done either way, I'm fine.

Ad 1: I prefer a session to be created. Anything else will supposedly be harder to explain to users.

I'm not sure, it may well introduce security concerns when suddenly users get unintentional sessions.

Ad 2: If the user should already be logged in as the intended user, only the given target should be reached. If it should be a different user, either creating a new session for that one or throwing an error would be desirable.

If it's the same user, we should just go to the destination, otherwise it should raise an error, just like the password-reset link does as well.

Ad 3: Yes. The hash however will have to be regenerated from time to time for security reasons. I'd expect that ECA can do that.

How sites are managing their hashes is not directly related to this issue.

After all those thoughts, this new feature could be defined this way:

• Provide a new controller /user/authenticate/{ hash } which will be like a login but using the hash instead of user name and password. If there is a destination argument given, that will afterwards go there, just like with the login form as well
• Provide a new middleware which sets the current user for the request to the user of the given hash if an optional user_hash query argument is provided in the request. The access control will then be performed for that user instead of the anonymous user so that a page can be made available even if it would be access denied otherwise. But this one doesn't start a new session, unlike the former one.
• The hash should be available as a token so that both URLs above can be built with logic.
• If either URL is being called in a browser where there is an active session for a different user, this will display an error message just like the password reset URL.

Once we have the specification agreed, we should update the original issue description to reflect the final version. After that, we need to find a developer who is willing to spend their own time to implement this or get some funding to pay a developer.