Manual:SessionManager and AuthManager/Linked accounts
AuthManager introduces the concept of account linking; authentication providers that use some external service (for example google.com via GoogleLogin to use Google's single sign-on) can bind remote accounts to local ones and manage them.
As a user
[edit]Logging in with a linked account happens through the login page; the specifics vary, but typically there will be a dedicated button, which will redirect to the third-party service for authentication.
There are three ways to manage linked accounts:
- use Special:LinkAccounts to link a new account; this works the same way as logging in with it.
- use Special:UnlinkAccounts to see a list of linked accounts and select some for removal
- autolink via login: use a non-linked account for logging in, in which case the authentication provider can decide to reject the login attempt, or autocreate the local user with a username of its choice, or mark the account for autolinking. In the last case, the user can proceed to log in by some other means, and the remote account from the first login attempt will be linked automatically (after allowing it with a confirmation dialog). (This functionality is experimental and initially disabled.)
As a developer
[edit]Providers that can link remote account must implement the PrimaryAuthenticationProvider interface and return TYPE_LINK for accountCreationType(). Account linking happens by implementing beginPrimaryAccountLink()/continuePrimaryAccountLink() (which is not much different from the similar methods for authentication and account creation). Linked accounts should be listed when getAuthenticationRequests( ACTION_REMOVE ) is called. Account unlinking should be implemented in providerChangeAuthenticationData() (one of the previously listed requests will be passed, with its action property set to ACTION_REMOVE and otherwise unchanged). Account autocreation happens by passing back AuthenticationResponse::newPass( <username> ) in the authentication process. Account autolinking happens by passing back an AuthenticationResponse with null as the username and its linkRequest property set to some AuthenticationRequest. This request will be passed back to providerChangeAuthenticationData() if the user successfully logs in and passes the autolinking confirmation screen.
Security
[edit]Two threats are considered:
- The attacker performs a login attempt to mark a remote account under their control for autolinking, then leaves the machine around in the hopes that a user will continue the login process (without realizing that it has already started) and then take over the user's account by logging in with the linked remote.
- To prevent this, autolinking happens via a confirmation dialog where the remote accounts that can be attached are linked, and the user has to select the ones they recognize, to confirm the link.
- The user tries to log in, the remote account is marked for autolinking, the user then abandons the login without realizing that autolinking is in progress. An attacker gains access to the machine, and is able to link the remote account to their own local account. This can be exploited to trick the target into logging in as the attacker and using user JS to present them a password prompt or something similar.
- To make this harder, we delete the authentication state every time an authentication process is started (e.g. a GET request is sent to Special:UserLogin). This is not a perfect defense (the user can miss the message about login being in progress and leave the login window open, or the attacker can reopen the window somehow) but the conditions for performing such an attack are sufficiently complex (the user must use a public machine and abandon login halfway, the attacker must gain access to it within session expiration time, realize that a login is ongoing and recover the login process without resetting it; and in the end the target gains access to the attacker's account and not vice versa so it's not trivial to utilize) that it's considered a low threat.