AADSTS50126: "Invalid username or password" returned even when the password is valid
While trying to log in to Microsoft 365 with OAuth2, some customers are getting this error code, although the username and password is indeed correct.
This is because this error code appears to be returned for another error situation which is not related to the password that the user entered.
No matter the actual cause of the error, it is crucially important to properly pinpoint the actual cause of the error, so that the software can respond correctly. Different error cases need different responses from the software.
From the client software side, the perspective of a client software developer, we must unambiguously distinguish between a) an actually invalid password, where the user entered the wrong password, and b) some technical problem or incompatibility with the domain setup. The reason why it's crucial to differentiate is because the error recovery is very different. In the first case a), I tell the user that his password is wrong and he needs to enter it again. In the second case b), I either do some fallback code or tell the user that I cannot support his account. If I pick the wrong case, because the error code I get is wrong - as in this case -, then I'll keep asking the user to re-enter the passwords, which is completely useless, confusing, and might even lead him to enter other passwords, which is dangerous. In any case, it's a really bad end user experience.
The documentation for this error code AADSTS50126 specifically says that this error code means that is an invalid password. However, we see this code when the password is correct, so the error message is flat out wrong. In most configurations, the error code is returned correct, and really only for wrong passwords, but not in all configurations.
This causes serious problems for software trying to authenticate, because the software cannot know whether to ask the user to re-enter the password, or use fallback code to use another authentication path.
There's no way for us to fix this properly. The bug here is simple: The Microsoft servers return the wrong error code and message. The error message and code are flat out wrong. A MS developer was just re-using the wrong error code, instead of creating a new error code as he should. This must be fixed in the Microsoft software. That's the only place where it can be fixed.
This leads to hurt and setup pains for end users. Please fix it.
Many people ran into this. Please see comments and more details on
Ben Bucksch commented
Given that this is an error situation, a slower response is fine, if that gives a more correct response. The effects of the current situation cost the user a lot of time or lead to a complete failure of the entire process. With a proper error message, the error may be rectifiable. This is well worth a few ms or even a few seconds.
Worse, the current situation means that I cannot trust the error code in any situation, even where it's valid and correct.