I'm adding bug 42131 as a see also (and leaving it marked resolved/wontfix), but it may properly be a dependency of this bug.

Just to document the problem with this right now, here is the current workflow:

1. Do preliminary login checks
2. Run AbortLogin hook
3. Check password
4. Log in the user

All extensions are forced to hook in at step 2, which is before the password check. So if an extension needs to gather more information, and it redirects to another page, the password check has never happened and the password itself is no longer in the request.

Right now in OATHAuth, I'm getting around this by taking the WebRequest, storing it, and basically replaying the request once the new information is gathered. Of course, this is a risk because now private information is stored in Memcached. This can be mitigated with some sort of symmetric encryption, but it'd be better to just avoid it entirely.

The preferred workflow would be to have AuthManager organize its checks and be able to store the results of those checks so that further information can be gathered and further checks can be performed before the user is determined to be authenticated.

In AuthManager SecondaryAuthenticationProviders fulfill this role: they are invoked after the identity of the user has been established, can request further information (which will be handled by Special:UserLogin by showing a second form after the normal login form), and can block or abort the authentication process based on the reply.