gapi.auth.authorize silently failing due to returned X-Frame-Origins: SAMEORIGIN

[cowsrule]

I posted this question to stack overflow, but have started getting an increasing number of customers complaining about the same issue. The stack overflow link has more information: https://stackoverflow.com/questions/35779351/google-oauth-gapi-auth-authorize-x-frame-options-sameorigin

Summary
Start ~2wks ago a few customers have started hitting an issue that prevents them from authenticating with Google services. All of the instances that I have encountered so far appear to be on non-gmail domains. The issue appears to be that the https://accounts.google.com/o/oauth2/auth request from gapi.auth.authorize is returning a response with the 'X-Frame-Options: SAMEORIGIN' header for these particular clients. I have been unable to reproduce this issue locally, but have been given multiple HARs of the failed request.

This same authentication method is working well for a variety of other clients including other hosted domains (non-@gmail accounts) that are all running the same code and request the same set of OAuth scopes.

Are there known patterns that would cause the Google authorization servers to return this particular header? Is there more information that I can provide?

[cowsrule]

I've added an answer to the stack overflow post, but the general problem is that requesting over 7 OAuth scopes for an account on a hosted domain (non-@gmail) causes the Google authorization server to return an X-Frame-Options header. This behavior also appears to be affected by the presence of the 'jsh' URL param that the JS GAPI library senders, but I am not sure what the significance is.

Repro Files

[bsittler]

Thanks! I will investigate further.

[cowsrule]

Is there anything else that I can provide to help the investigation? Were you able to track down the issue?

[bsittler]

I believe that the URL is simply growing too long. Can you provide the full list of scopes you are requesting? It's possible some of them can be abbreviated or removed from the list.

[bsittler]

Also it's possible we can work around this issue somewhat in the library; I'll continue to investigate that

[cowsrule]

It the URL length a potential problem even if the same request works for @gmail addresses, just not for hosted domain addresses? Is there a different length requirement on the backend that would cause this?

https://www.googleapis.com/auth/drive.file,https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/drive.appdata,https://www.googleapis.com/auth/contacts.readonly,https://www.googleapis.com/auth/gmail.modify,https://www.googleapis.com/auth/gmail.compose,https://www.googleapis.com/auth/drive.metadata.readonly,https://www.googleapis.com/auth/calendar.readonly

[bsittler]

I would not be surprised if there were differences, especially if the hosted domain accounts use SAML or have different two-factor auth configurations from the Gmail accounts. It's unfortunate that there are three different scopes just for Drive access, but I'm not sure yet whether there's a single shorter one with equivalent access. However, you certainly can shorten the .../userinfo.email scope to just "email" and that may help

[bsittler]

For the Drive access is it possible that either https://www.googleapis.com/auth/drive.appfolder or https://www.googleapis.com/auth/drive.appdata by itself would be sufficient and also not too broad? I don't know what your app needs to do, of course, but three separate Drive API scopes may not be needed

[cowsrule]

Thanks for the help and suggestions and we have implemented a workaround that is suitable for the time being by conditionally dropping scopes. What worries me is that at some point in the future we will not be able to reduce the length of requested scopes to a the required string length. It would be great to know that this restriction was going to be potentially changed or what the sanctioned workaround is.

My best guess is that we will have to use 'include_granted_scopes' and perform multiple authorization requests which will work for us just complicates things.

One further suggestion would be to try and have a more meaningful error message for this scenario. I realize this is likely not a common scenario, but it was incredibly frustrating to have some portion of our users silently fail to authenticate. Having a better error returned in this case would save others from having the same experience or at least notify that there is a potential problem.

[TMSCH]

Hi @cowsrule, we recommend migrating to the more recent gapi.auth2 library as gapi.auth is now deprecated. Doc: https://developers.google.com/identity/sign-in/web/sign-in if you are still experiencing the bug. Otherwise, please close the issue. Thanks!

[dvanderb]

This looks like a question about Google Login and Authentication. Please address this question to the google-signin tag on stackoverflow(https://stackoverflow.com/questions/tagged/google-signin)

If you believe this is in error, please reopen the issue.