I've just tested this pattern on ASafaWeb with the same result (it uses the same default implementation). Here's what I believe is happening
- Both login forms load with the same __RequestVerificationToken cookie (it's just the same one set in the same DOM) and the same __RequestVerificationToken hidden field. These tokens are keyed to an anonymous user.
- Login form A posts with the above tokens, validates them then returns an auth cookie which is now in the browser DOM
- Login form B posts also with the above tokens but now it's also posting with the auth cookie set from login form A as well.
The problem is that the token isn't validating in step 3 because it's keyed to an anonymous user but it's being passed in the request by an authenticated user. This is why you're seeing the error: The provided anti-forgery token was meant for user "", but the current user is "admin"
You're only having this issue because form B loaded before form A posted therefore form B is expecting to be posted by an anonymous user.
Is it an issue to remove it from a form which by definition will be used by unauthenticated users?
The predominant underlying risk that anti-forgery tokens protect against is CSRF which usually takes advantage of authenticated users due to the fact that any requests their browser can be tricked into issuing will be automatically accompanied by an auth cookie hence the action will be performed on their behalf. This risk doesn't exist on the login form because usually the user isn't authenticated and the worst CSRF case here is that a login is forged and then fails; you're not exactly transferring money on the user's behalf!
There are other advantages to the anti-forgery token though: for example it prevents brute force attacks actually executing the method and hitting the DB. You need to decide if you're less worried about this and more worried about the scenario you're encountering in your question. Either that or you need to drop down into the request pipeline somewhere and take action if an auth cookie is already present in the request before the anti-forgery validation occurs.
Frankly though, I'm not sure I see the problem; to reproduce this issue the user has to have multiple login forms open at the same time and then try logging into each in succession - is this really going to happen enough to worry about? And when it does happen, does it really matter that the second login returns a custom error page (which of course you'd do in production)? IMHO, leave the default behaviour.