Google authentication issue on the latest macOS update

[andy61i]

Setup macOS Sierra 10.12.6 (16G1314) OR macOS High Sierra 10.13.4 (17E199) Google Chrome Version 65.0.3325.181 (Official Build) (64-bit)

Pods

• GoogleAPIClientForREST (1.3.4)
• GoogleAPIClientForREST/Core (1.3.4)
• GoogleAPIClientForREST/Drive (1.3.4)
• GoogleAPIClientForREST/Oauth2 (1.3.4)
• GTMAppAuth (0.7.0)
• GTMSessionFetcher (1.1.15)
• GTMSessionFetcher/Core (1.1.15)
• GTMSessionFetcher/Full (1.1.15)

Problem The following authentication code worked well before the latest macOS update:

#define CLIENT_ID @"382239646343-0elsgpt33tkmvod7pgdc8qbn6e9sn169.apps.googleusercontent.com"
#define CLIENT_SECRET @"deleted"
#define REDIRECT_URI @"com.googleusercontent.apps.382239646343-0elsgpt33tkmvod7pgdc8qbn6e9sn169:/oauthredirect"
#define DRIVE_SCOPE @"https://www.googleapis.com/auth/drive"

OIDServiceConfiguration* configuration = [GTMAppAuthFetcherAuthorization configurationForGoogle];
    OIDAuthorizationRequest *request = [[OIDAuthorizationRequest alloc] initWithConfiguration:configuration
                                                                                     clientId:CLIENT_ID
                                                                                 clientSecret:CLIENT_SECRET
                                                                                       scopes:@[DRIVE_SCOPE]
                                                                                  redirectURL:[NSURL URLWithString:REDIRECT_URI]
                                                                                 responseType:OIDResponseTypeCode
                                                                         additionalParameters:nil];
    self.authorizationFlow = [OIDAuthState authStateByPresentingAuthorizationRequest:request
                                                                            callback:^(OIDAuthState * _Nullable authState, NSError * _Nullable error) {
        if (authState) {
            GTMAppAuthFetcherAuthorization* authorization = [[GTMAppAuthFetcherAuthorization alloc] initWithAuthState:authState];
            self.service.authorizer = authorization;
            ...
        } else {
            self.service.authorizer = nil;
            ...
        }
    }];

Since the update there is a problem:

• Chrome starts and offer to select a Google account => Select one
• Appears a page to allow access to Google Drive files => Allow
• A popup appears with a query to start the app initiated this authentication

Then there are 3 possible scenarios:

1. Wait a couple of seconds. The underling "allow access page" will automatically forwards to Google Search (as on the screen above). Then pressing "Open SafeInCloud Password Manager" will do nothing (the auth callback never gets called).
2. Be quick and press "Open" button immediately. Then authentication will work.
3. If the "Always open these type of links" checkbox was pressed in scenario 1 (on previous macOS build) or in scenario 2, then authentication will work automatically.

So, the problem is this autoforwarding from the "allow access page" to Google Search pages.

Testing The app to test problem: https://www.safe-in-cloud.com/download/beta/SafeInCloud.dmg Steps to reproduce:

• Start the app
• Select 'Restore database from a cloud'
• Select 'Google Drive'

[StevenEWright]

Does this help? https://github.com/openid/AppAuth-iOS#bulb-alternative-custom-uri-schemes

[andy61i]

Thanks for your advice! The auth flow works fine via Redirect HTTP Handler and I will switch to this method, but I still believe the Custom URI Schemes should be fixed. Please keep this issue opened till then)

[StevenEWright]

This isn’t an “issue” with AppAuth as far as I can tell. This interstitial is part of Google Chrome. The supplied documentation and local http server are provided specifically to help ameliorate this (well known) situation.

If you can suggest a better way of working around the problem, then we can keep this issue open as a feature request for the suggested workaround.

If you can point me to anything we are doing wrong, then we can leave this open as a bug.

But unless this can either be attributed to a bug, or tracked as a feature request, then we will likely close the issue soon as an answered question.

_{Sent with GitHawk}

[andy61i]

Sure. It's up to you how to handle this. I just asked. Though it's strange that the latest macOS update (not even Chrome update) broke the default auth method for Google APIs Client Library for Objective-C For REST. Should someone in Google who might care about that?

[StevenEWright]

I think there are two teams that are related:

• Google Identity, which seems to have some javascript that performs a redirect to google.com after some (5 seconds?) timeout. This redirect obviously doesn't work well in this scenario (which they probably didn't consider). That said, I'd guess they probably don't have a lot of native clients doing custom URI scheme callbacks, and that this use case will not change a decision they made for other reasons. Between William and I, I think we can bring this edge-case to their attention and see where the chips fall, but I wouldn't rely on this being "fixed"/changed, and am still a fan of the HTTP handler as a reliable workaround.

• Google Chrome, which owns the interstitial.

I'm a bit skeptical that a macOS update changed this behavior.

This has been the behavior of Chrome for a while now (on macOS) so it's not like the interstitial is "new".

Is it possible you had previously checked the "Don't prompt be again" checkbox, forgot you were ever asked previously, and then had your chrome settings get reset (which caused the prompt to start showing up again)? Perhaps a macOS update caused Chrome to run some sort of upgrade process, and a bug in the upgrade process trashed your saved setting for this checkbox? This is all just wild speculation. But it's not clear to me at all how a macOS update would have changed this behavior since the Javascript which performs the redirect is being run in Chrome itself - so macOS isn't really even involved in the process.

Also, I know Chrome has had a bug in the past where this checkmark didn't "stick". Is it possible you're running into a regression in Chrome?

I'd add that, the HTTP handler not only "solves" this problem for Chrome, but also prevents you/us/everyone from worrying about the same sort of issues across multiple browsers (Safari, Firefox, etc.)... all reasons why that's the reliable workaround we recommend.