ferdnyc
commented
5 years ago Apologies for butting in on this, hopefully this info is helpful and not merely me saying things that are already well known.
I was surprised, when I encountered this today in LibreOffice 6.1.5.2 on Fedora 29. Not that authentication didn't work, but that LibreOffice was trying to use its own username/password dialog to do it. My experience has been that all such methods stopped working quite a while ago, especially where Google Drive is concerned. And the comments in gdata/gdata-oauth2-authorizer.c from libgdata would seem to bear that out.
libgdata is the library that powers Gnome Online Accounts' functionality for Google services, and the authentication process there is just as they describe in the code: You go into the Online Accounts pane of the Settings application, indicate that you want to add a new Google account to your online accounts list, and the app immediately pops up an embedded web browser. Google's page handles all of the interaction with the user until authentication is complete.
Their comments sketch out the flow, for more detail see the complete gdata-oauth2-authorizer.c source.
/* #GDataOAuth2Authorizer provides an implementation of the #GDataAuthorizer
* interface for authentication and authorization using the
* <ulink type="http" url="https://developers.google.com/accounts/docs/OAuth2InstalledApp">OAuth 2.0</ulink>
* process, which is Google’s currently preferred authentication and
* authorization process.
*
* OAuth 2.0 replaces the deprecated OAuth 1.0 and ClientLogin processes. One of
* the main reasons for this is to allow two-factor authentication to be
* supported, by moving the authentication interface to a web page under
* Google’s control.
*
* The OAuth 2.0 process as implemented by Google follows the
* <ulink type="http" url="http://tools.ietf.org/html/rfc6749">OAuth 2.0
* protocol as specified by IETF in RFC 6749</ulink>, with a few additions to
* support scopes (implemented in libgdata by #GDataAuthorizationDomains),
* locales and custom domains. Briefly, the process is initiated by building an
* authentication URI (using gdata_oauth2_authorizer_build_authentication_uri())
* and opening it in the user’s web browser. The user authenticates and
* authorizes the requested scopes on Google’s website, then an authorization
* code is returned (via #GDataOAuth2Authorizer:redirect-uri) to the
* application, which then converts the code into an access and refresh token
* (using gdata_oauth2_authorizer_request_authorization()). The access token is
* then attached to all future requests to the online service, and the refresh
* token can be used in future (with gdata_authorizer_refresh_authorization())
* to refresh authorization after the access token expires.
*
* The refresh token may also be accessed as
* #GDataOAuth2Authorizer:refresh-token and saved by the application. It may
* later be set on a new instance of #GDataOAuth2Authorizer, and
* gdata_authorizer_refresh_authorization_async() called to establish a new
* access token without requiring the user to re-authenticate unless they have
* explicitly revoked the refresh token.
*
* For an overview of the standard OAuth 2.0 flow, see
* <ulink type="http" url="http://tools.ietf.org/html/rfc6749#section-1.2">RFC 6749</ulink>.
*/
```c
/* <example>
* <title>Authenticating Asynchronously Using OAuth 2.0</title>
* <programlisting>
* GDataSomeService *service;
* GDataOAuth2Authorizer *authorizer;
* gchar *authentication_uri, *authorization_code;
*
* /<!-- -->* Create an authorizer and authenticate and authorize the service we're using, asynchronously. *<!-- -->/
* authorizer = gdata_oauth2_authorizer_new ("some-client-id", "some-client-secret",
* GDATA_OAUTH2_REDIRECT_URI_OOB, GDATA_TYPE_SOME_SERVICE);
* authentication_uri = gdata_oauth2_authorizer_build_authentication_uri (authorizer, NULL, FALSE);
*
* /<!-- -->* (Present the page at the authentication URI to the user, either in an embedded or stand-alone web browser, and
* * ask them to grant access to the application and return the code Google gives them.) *<!-- -->/
* authorization_code = ask_user_for_code (authentication_uri);
*
* gdata_oauth2_authorizer_request_authorization_async (authorizer, authorization_code, cancellable,
* (GAsyncReadyCallback) request_authorization_cb, user_data);
*/...Etc. Google have really locked down their authentication flow in recent years, and any application that's imposing itself into the password-collection process (and therefore potentially capturing or misusing users' credentials) doesn't seem to have much chance of remaining able to authenticate — even if it works for some users today, Google would prefer that it not in the future.
papermache
Freso
MeggyCal
Maybe somebody here can help me with the following problem: Using LibreOffice (which internally uses libcmis) to log into Google Drive (in LibreOffice, "File - Open Remote... - Add service - Type: Google Drive", enter "User" and "Password" and click "OK"), with two different
@googlemail.comaccounts, it consistently succeeds for one of them while it consistently fails with the other. (This is with https://github.com/tdf/libcmis/pull/20 "Properly encode OAuth2 credentials" included, so it is unlikely that this is due to differences like e.g. the exact password spelling.) Debugging intoOAuth2Providers::OAuth2Gdriveinsrc/libcmis/oauth2-providers.cxx(with passingverbose = trueintoSessionFactory::createSessioninsrc/libcmis/session-factory.cxx, plus someprintf), the two cases proceed the same up until sendingloginPasswdPostas POST request (in// STEP 3: password page). In both cases,loginPasswdPostlooks like (broken up for better readability)However, the responses from the server differ. In the successful case, we get a
302 Moved Temporarilyresponse withLocation: https://accounts.google.de/accounts/SetSID?ssdc=..., ultimately GETing a/o/oauth2/auth?scope=https://www.googleapis.com/auth/drive&redirect_uri=urn:ietf:wg:oauth:2.0:oob&response_type=code&client_id=...HTML page titled "Request for Permission" and which is apparently as expected by the next call intoparseResponse, causingOAuth2Providers::OAuth2Gdriveto return successfully with some non-emptycode. But in the failing case, we directly get a200 OKHTML page titled "Anmelden – Google Konten" (stuff is apparently localized on the server end, I'm doing this from Germany) which is apparently not as expected by the next call intoparseResponse, and which causesOAuth2Providers::OAuth2Gdriveto fail returning an emptycode. (And when deliberately trying with a bad user name, or with the otherwise successful user name and a wrong password, behavior is different still, ruling out the assumption that the failing case's user name or password is bad: For a bad user name, the HTML page retrieved in// STEP 2: send emailalready is different, containing somehas-errorstuff. And for a bad password, the HTML page retrieved in// STEP 3: password pagecontains suchhas-errorstuff.) This may not even be an issue with libcmis. It smells like something is set up differently for those two Google accounts, but I have no idea what that could be. (And I get reports from other people too that their accounts don't work, in the same way.) Does anybody have an idea what might go wrong?