To repeat this:

1. Authenticate with Guard
2. While authenticated, try to login again, but fail (e.g. put in the wrong password). You become de-authenticated.

The cause is this code:

This was put in very purposely by me. But actually, I was just following the lead from AbstractAuthenticationListener:

In reality, I can't think of any reason why the token should be set to null when you fail authentication. If you're still authenticated via some other mechanism (e.g. a session cookie), then you should still be authenticated. The original $this->tokenStorage->setToken(null); code was actually added during the original creation of the security component - sha: f216f31. My theory is that this was an oversight/bug way back then... but nobody really caught it. Then, I copied it for Guard.

I think we should fix this. But, it's a behavior change: technically, someone could for some crazy reason, be relying on the fact that a failed login attempt would cause the user to be logged out. Do others agree? Would changing this behavior be a BC break? If not, the fix is SUPER easy. Otherwise, we'll need to add some flag for the new behavior, and trigger a deprecation warning if the flag is not set.

My guess is that in a lot of cases, the token would've been NULL (never set in the exception), and thus never triggered this, but that's the best I could come up with.

I can't think of any reason why the token should be set to null when you fail authentication

Doesn't this happen when elevating by requiring IS_AUTHENTICATED_FULLY in a IS_AUTHENTICATED_REMEMBERED setting? I would certainly expect those cases to cause logout if failed, as it could indicate a session hijack.

Doesn't this happen when elevating by requiring IS_AUTHENTICATED_FULLY in a IS_AUTHENTICATED_REMEMBERED setting? I would certainly expect those cases to cause logout if failed, as it could indicate a session hijack.

Hmm. Well, your session would be hijacked in that case, it would be the remember me cookie that was hijacked. But, fair statement. Though, I'm not convinced that you would want to be logged out anyways. Without the password, I still couldn't access any IS_AUTHENTICATED_FULLY areas, I would remain only IS_AUTHENTICATED_REMEMBERED. It really comes down to the question: if I'm authenticated, should entering my password incorrectly render me not authenticated suddenly? If the answer is yes, then the feature is created correctly.

I'm not sure whether there's any golden rule to this, but I would myself implement this as it is done now, assuming that the most recent authentication is always leading. If you can't confirm your identity now - don't trust the previous confirmation either.

Perhaps we should have a bit of research on how big common sites solve this?

@curry684 but your identity is confirmed, hence the PostAuthenticationGuardToken.

Also note that in my previous setup with Simple* authenticators, this worked just fine

Yes I know that the behavior is inconsistent, the question is now whether the Simple* authenticators are 'wrong' or the Guard.

I see it like this: when I go the airport I have to show my passport multiple times. The first time I use it to authenticate myself I am given a boarding pass (a 'token') which implicitly confirms my identity. When boarding the plane my passport is checked again, and if it is rejected my boarding pass becomes untrusted automatically. Authentication is, imho, only ever as valid as your most recent attempt.

Authentication is, imho, only ever as valid as your most recent attempt.

I disagree with that statement. I've already confirmed that the user is authenticated. In this scenario, a typo in the password would throw away the previous authentication, rather than leaving it at the current level. The previous authentication was correct, only the new one is incorrect.

Your scenario also seems incorrect. You first identify with a passport, but if your boarding pass is rejected, that doesn't automatically invalidate your passport.

In this scenario, a typo in the password would throw away the previous authentication, rather than leaving it at the current level.

Correct, and intentional on my part.

You first identify with a passport, but if your boarding pass is rejected, that doesn't automatically invalidate your passport.

It's the other way around - if my passport is rejected, it invalidates my boarding pass. That makes sense as it casts doubts on how I got the boarding pass in the first place.

I don't think the two of us should be arguing here, I see your point and I'm not even really opposed to it. I would just do it like it's done currently myself as I'm in the strictness-above-all camp where security is concerned. I think it's up to others to decide "the Symfony way", and based on that we should either fix this one or the Simple authenticators.

It's the other way around - if my passport is rejected, it invalidates my boarding pass. That makes sense as it casts doubts on how I got the boarding pass in the first place.

Except that if your passport was already checked and confirmed, it should yield the same result next check, otherwise the first check can't be trusted. My first check can be trusted, thus I expect my authenticator to work like this.

Security and usability often conflict. The better the security, the less user friendly a system becomes. However, in this scenario it doesn't increase or decrease security, it only hinders usability.

What you are experiencing seems more like an unfortunate side effect of code that is in itself suitably strict. The scenario you're describing isn't "your average web site with a customer login" anymore 😉

Let's take a look at a real example from big websites: If you are trying to perform a checkout at Amazon, you will have to reauthenticate. If you fail to do so (maybe because of a typo), you won't be logged out immediately, but you can try to login a again. In my opinion that's the expected behaviour. Just because you made a typo when typing your password shouldn't mean that the whole session should be destroyed.