Well, we can't both offer OAuth1 and OAuth2 tokens at the same time - at least not while there is no way to get an OAuth1 token from an OAuth2 one or vice-versa. Well, we *could*, but that would include making the user authenticate *twice* (once for the OAuth1 token and once for the OAuth2 token) and we don't want that.

So we will have to have a flag day where everything in GNOME use GOA switches to OAuth2. This is, however, not yet possible because some Google services, such as IMAP, only supports OAuth1 right now. Maybe GNOME 3.4 or GNOME 3.6, I don't know.

As I said in bug 659435 comment 2, we (e.g. the GNOME foundation) probably needs to establish a relationship with Google so they are aware of our needs. Maybe that would help. I don't know.

For now I'm closing this bug WONTFIX in lieu of a CANTFIX resolution.

Maybe in the meantime an option could be to re-use the login/password entered by the user when authentificating for OAuth1 and re-use them to authentificate using OAuth2. That would be a dirty hack, for sure, but that's the best we can do until Google unify the accesses to its services (and it can take a while...).

(In reply to comment #2)
> Maybe in the meantime an option could be to re-use the login/password entered
> by the user when authentificating for OAuth1 and re-use them to authentificate
> using OAuth2. That would be a dirty hack, for sure, but that's the best we can
> do until Google unify the accesses to its services (and it can take a
> while...).

GOA is completely ignorant on how the provider authenticates the user (for better or worse) so this would require snooping on the embedded Webkit-gtk widget.. and in fact, it could be that authentication does not even require a password.. or, in my case, requires two-factor authentication (a password and a mobile device) [1]...


[1] : http://googleblog.blogspot.com/2011/02/advanced-sign-in-security-for-your.html

(In reply to comment #1)
> Well, we can't both offer OAuth1 and OAuth2 tokens at the same time - at least
> not while there is no way to get an OAuth1 token from an OAuth2 one or
> vice-versa. Well, we *could*, but that would include making the user
> authenticate *twice* (once for the OAuth1 token and once for the OAuth2 token)
> and we don't want that.

Since we already make the user authenticate twice (see bug 652546) I think it's still better to do that in a single step (i.e. from the Online Accounts panel) than once there and once in Empathy, as a stop-gap solution until we can support OAuth2 for everything. Jon, what do you think?

Reopening, because GMail supports OAuth 2.0 for IMAP and SMTP since April 20, 2012:
https://developers.google.com/google-apps/gmail/oauth_protocol

This has now been implemented in the wip/oauth2 branch:
http://git.gnome.org/browse/gnome-online-accounts/log/?h=wip/oauth2

Created attachment 225037 [details] [review]
google: Implement OAuth 2.0

    As of April 20, 2012 [1] GMail finally implements the SASL XOAUTH2
    mechanism. With that Google now supports OAuth 2.0 for all the
    different services that we care about.
    
    Unlike their OAuth 1.0 implementation, they don't support "anonymous"
    keys with OAuth 2.0. We need to register for a client_id /
    client_secret pair. However, we are allowed to embed the client_secret
    in our source code:
    https://developers.google.com/accounts/docs/OAuth2InstalledApp#overview
    
    With this we can leverage services like GTalk and Google Drive that
    did not support OAuth 1.0. For starters, the scope for GTalk has been
    added so that Empathy can use it.
    
    [1] https://developers.google.com/google-apps/gmail/oauth_protocol
        The documentation was updated retroactively because it did not
        mention anything about OAuth 2.0 weeks after the mentioned date.
        Yay Google!

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.