1238631 - Google talk cannot login when enable 2-factor auth

Status: ASSIGNED

(Chat Core :: XMPP, defect)

Description

[Thomasy]

There is always password fail when enabling 2-factor auth.
An workaround right now is using "Sign in using App Passwords".

Comment 1

[Thomasy]

I think it need to use Oauth as ./chat/protocols/twitter/twitter.js .

Comment 2

[Patrick Cloke [:clokep]]

Similar to bug 984027, yes it'd be nice to support oauth. I think this was never done because Google doesn't return a good error message (e.g. "You have 2 factor enabled!") it just returns the "invalid password" error if you try to use a password.

We should just bite the bullet and use 2FA.

We'd want to use https://dxr.mozilla.org/comm-central/source/mailnews/base/util/OAuth2.jsm or https://dxr.mozilla.org/comm-central/source/mail/base/modules/oauth.jsm

Comment 3

[Patrick Cloke [:clokep]]

Attachment: gtalk-oauth.diff

This adds support for using OAuth to log into GTalk, which is necessary for newer accounts / accounts that have 2FA / probably other situations. (I've had a GTalk account configured forever which works fine with an app password, I'm able to use that app password on another profile, but my other accounts need to use OAuth it seems.)

I'm not 100% sure all the changes to OAuth2Providers.jsm are wanted (do we really want to ask for GTalk when setting up a mail account? I just matched what we did for CardDAV/CalDav). Not sure if that file needs a separate review or not. GTalk does handle using a bare name (e.g. clokep or [e-mail]) while I think the other protocols require the full email? So it is possible that the password manager would end up with separate OAuth tokens anyway, I don't think this is a huge deal.

I also documented the way the XMPP authentication mechanisms work since I hate reverse engineering that each time.

One oddity with this is that if you take too long to finish the OAuth flow then it will cause the account to disconnect, but will attempt to reconnect in the background. So once you finish it will eventually connect properly, but it might take a few tries. (Note that you won't get multiple OAuth windows though.) Any thought on what to do here?

Comment 4

[Martin Giger [:freaktechnik]]

Comment on attachment 9242847 [details] [diff] [review]
gtalk-oauth.diff

Review of attachment 9242847 [details] [diff] [review]:
-----------------------------------------------------------------

> Not sure if that file needs a separate review or not.

I don't feel like I have the authority to approve the scope request change for new gmail accounts.

> GTalk does handle using a bare name

I think trying to normalize the username would make sense to me. Though discovering the existing entry doesn't seem to work at all for me, unless I get prompted again for a scope extension (which I shouldn't right now, from how I understand the code), which I think would honestly be the best way to handle it. But not sure how easy that is to implement in our OAuth infrastructure.

> So it is possible that the password manager would end up with separate OAuth tokens anyway, I don't think this is a huge deal.

Not sure how google handles multiple authorizations for the same OAuth app, but I'd assume it'd at least be confusing to the user if they are trying to manage their authorized applications.

> One oddity with this is that if you take too long to finish the OAuth flow then it will cause the account to disconnect, but will attempt to reconnect in the background. So once you finish it will eventually connect properly, but it might take a few tries. (Note that you won't get multiple OAuth windows though.) Any thought on what to do here?

That sounds like we're not responding to pings on the socket or similar during auth?

::: chat/protocols/gtalk/gtalk.jsm
@@ +52,5 @@
>    }
>  }
>  
> +// OAuth2 is an authentication mechanism that allows the client to never receive
> +// the password from the user. The logs into the website directly and the client

> The logs into

This logs into? The user logs into?

@@ +58,5 @@
> +//
> +// This is required for use with accounts which have two-factor authentication
> +// configured (without app passwords) and maybe other configurations.
> +//
> +// See https://developers.google.com/talk/jep_extensions/oauth

This is a 404 for me, but so are other talk docs. Did they finally get nuked?

@@ +94,5 @@
> +  // Create a new promise which fires when the OAuth callback finishes.
> +  let stanza = yield new Promise((resolve, reject) => {
> +    oauth.connect(resolve, reject, true);
> +  }).then(() => {
> +    // Login was successful, store the information for subsequence logins.

*subsequent

@@ +96,5 @@
> +    oauth.connect(resolve, reject, true);
> +  }).then(() => {
> +    // Login was successful, store the information for subsequence logins.
> +    if (isNew) {
> +      console.log(`Saving refresh token for ${aUsername}`);

I guess we have no reference to the account here to log to it?

@@ +117,5 @@
> +      }
> +    }
> +
> +    // Generate the stanza for login.
> +    let key = btoa("\0" + aUsername + "\0" + oauth.accessToken);

Do we have to handle the access token expiring?

@@ +154,5 @@
>        this._jid.domain = "gmail.com";
>        this.authMechanisms = { PLAIN: PlainFullBindAuth };
>      }
>  
> +    // If the account has no password configured, use use OAuth to authenticate.

use use

::: chat/protocols/xmpp/xmpp-authmechs.jsm
@@ +12,5 @@
> +// * send: The next XML stanza to send.
> +// * log: The plaintext content to log (instead of the stanza, which likely
> +//   contains sensitive information).
> +//
> +// Each time the generator is yielded it is sent the response stanza from the

Each time the generator yields it gets resumed with the response stanza...?