Error: invalid_scope from oauth2

[BartGarciaNathan]

Hey, I just installed Hangups and when trying to set it up, when I try to open the webpage url given by hangups I get this message :
400. That's an error
Error: invalid_scope
Request Details
scope=https://www.google.com/accounts/OAuthLogin
response_type=code
redirect_uri=urn:ietf:wg:oauth:2.0:oob
client_id=936475272427.apps.googleusercontent.com

The recently used devices list by google does not show anything 'new' that could be hangouts. Am I doing something wrong? Do you need any other info?
I am running Linux 4.1.31-1-MANJARO

Any help will be much appreciated

[EionRobb]

I've just had 2 people trying to use purple-hangouts report the same thing. There's probably a new scope needing to be requested :s

[KwisatzHaderach]

Changing scope in hangups/auth.py to https://www.googleapis.com/auth/plus.login gets you the token, but KeyError: 'SAPISID' happens.

Apparently we need 3 scopes according to this: https://developers.google.com/+/hangouts/running
This is still not returning SAPISID cookie. Bloody google.

[gravitypriest]

Interestingly, this showed up on my Gmail a little earlier

[dequis]

This didn't work for me with purple-hangouts, but mentioning it for the sake of documenting what was tried, the android app requests these scopes to https://android.clients.google.com/auth, separated by spaces and prefixed by oauth2:

https://www.googleapis.com/auth/chat
https://www.googleapis.com/auth/plus.me
https://www.googleapis.com/auth/plus.peopleapi.readwrite
https://www.googleapis.com/auth/hangouts
https://www.googleapis.com/auth/identity.plus.page.impersonation
https://www.googleapis.com/auth/chat.native

Specifically, it fails at https://accounts.google.com/accounts/OAuthLogin?source=pidgin&issueuberauth=1 with status 403 and Error=badauth in the body.

I guess I need an iOS device to figure this one out.

[dequis]

Forgot to mention, out of those scopes, the last two are rejected as invalid_scope by the oauth method we use:

https://www.googleapis.com/auth/identity.plus.page.impersonation
https://www.googleapis.com/auth/chat.native

The second one is recognized by the error page as A native application: iOS Account Manager, which is why I said we should look at the iOS app instead (also that the client_id seems to be used by other iOS google apps)

The Error=badauth stuff I got was after getting a token that didn't have those scopes, which seems obvious in hindsight.

[ghost]

Hi!
Did anyone found solution for this problem?
I am using scope "https://www.googleapis.com/auth/plus.login" and after that get SAPISID cookie, but request to "https://account.google.com/MergeSessions"doesn't work :(
So I can't use multi-account because can't get cookie after each re-login (refresh token) :(

[eddielu]

It looks like this is an issue for third party Hangout clients:
https://productforums.google.com/forum/#!topic/hangouts/LU2YZNDhN_s

[tdryer]

Might be related to this announcement:
Modernizing OAuth interactions in Native Apps for Better Usability and Security

One possible workaround is to revert to the old pre-OAuth login method (simulating a browser login):
https://github.com/tdryer/hangups/blob/82786f40567acf811cc83340162e7bfc2e1dfa65/hangups/auth.py

[tdryer]

I tried logging into Hangouts for iOS while running mitmproxy, but Google blocks this now (probably certificate pinning). It did capture this one response which contains some OAuth details:

https://accounts.google.com/embedded/setup/ios?scope=https://www.google.com/accounts/OAuthLogin+https://www.googleapis.com/auth/userinfo.email&client_id=936475272427.apps.googleusercontent.com&delegated_client_id=183697946088-m3jnlsqshjhh5lbvg05k46q1k4qqtrgn.apps.googleusercontent.com&hl=en-US&device_name=iPad&auth_extension=ADa53XJhK96KggHR83VRjcIJuKYWqPQPMmAUB9gG7qDOz8WkZ45RmsGC30ftQLlvctIoWPTNE-oqvvtAxbRWv41tFM7NqoNLl0OChtAWkFoE6xHujd3DwDU&nosignup=1&system_version=9.3.4&app_version=11.5.129049038

[davibe]

Apparently you CAN request that scope to https://accounts.google.com/embedded/setup/ios but not to https://accounts.google.com/o/oauth2/auth

[davibe]

@tdryer i tried your url in a browser, inspected calls but i can't find a code

[dmunafo]

is there any update on this one? Was this issue root cause? Any workaround?

[avaidyam]

@tdryer Is there a way to check Web Hangouts instead? Perhaps that'd be easier.

[dmunafo]

Can it be something related to the client ID and secrets?

[Cbhihe]

Same issue here as posted by @BartGarciaNathan, for the last 6 days as of 2016.09.07.

[Pidgin 2.10.9; pidgin-hangouts 1.0; purple-hangouts 1.0]
[Ubuntu Desktop 14.04.4 - 3.16.0-50-generic x86_64 GNU/Linux)]

[JJLeMay]

@tdryer
If you are still interested in inspecting that iOS app's traffic, Check this out:
https://github.com/nabla-c0d3/ssl-kill-switch2

It will disable ssl certificate validation allowing you to MiTM and inspect traffic.
It requires root on the device, however.

[tdryer]

I haven't had a chance to work on this. If anyone is interested in helping out, I'd suggest trying to update the old pre-OAuth login method:
https://github.com/tdryer/hangups/blob/82786f40567acf811cc83340162e7bfc2e1dfa65/hangups/auth.py

[dequis]

Got a workaround here!

Using one of the urls linked above, you can get to a programmatic_auth url that sets the oauth code to a cookie. This is somewhat awkward to use, but certainly possible and better than being locked out.

I've made a video explaining how to get it:

https://www.youtube.com/watch?v=hlDhp-eNLMU

It's 41 secs long, no sound, with annotations. Used chrome but firefox is pretty much the same thing.

The programmatic_auth url:

https://accounts.google.com/o/oauth2/programmatic_auth?hl=en&scope=https%3A%2F%2Fwww.google.com%2Faccounts%2FOAuthLogin+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email&client_id=936475272427.apps.googleusercontent.com&access_type=offline&delegated_client_id=183697946088-m3jnlsqshjhh5lbvg05k46q1k4qqtrgn.apps.googleusercontent.com&top_level_cookie=1

Text version:

1. Go to that url
2. Enter your username, click next.
3. Right click page background, inspect
4. Go to the network tab.
5. Enter your password, click sign in
6. Click the first row in the network panel, the one that says "programmatic_auth"
7. Scroll down in the right-side panel, find "set-cookie"
8. Your code should be there, after "oauth_code=", up to but not including the semicolon.
9. Copy it and use it.

[Ezwen]

@dequis Wow, this indeed works. Thanks!

[mydongistiny]

Where do I put the code once I got it?

[Finlay87]

Copy and use it... Where?

[dequis]

In the same place where you'd put the code after clicking the url that throws the invalid_scope error.

I'm being rather generic here because I don't use hangups, but purple-hangouts. The method is pretty much the same for any client that displays the url.

If you're using a hangups derivative that doesn't ask for the code after displaying the url, but uses an embedded browser, ask the devs of that project for help.

In the case of yakyak this comment says how to use it it's fixed in 1.3.2 and there's no need to do this.

[Finlay87]

Thank you good sir.

[hurricanehrndz]

@danhimalplanet care to share how! I'm trying to do the same thing, I can't figure where to paste the oauth code into ? I'm guessing it's one of the xmls.

[leni536]

@dequis Interestingly the token I get with this workaround doesn't show up at https://myaccount.google.com/security#connectedapps. It looks like a security incident at Google's end, since it's impossible to revoke the token.

[dequis]

@leni536 "Recently used devices", shows up as iOS

[leni536]

@dequis Oh, I see! One can revoke access there. What's confusing that at https://myaccount.google.com/dashboard after unfolding "account" it shows up next to "Connected applications and sites" as "iOS Account Manager", but clicking on "Connected applications and sites" at the top doesn't list it at all (it still lists other apps like "Thunderbird" that supports OAuth2 too).

[t-animal]

Judging from a quick glance this method "steals" the oauth token of an iOs hangouts client? That is... kinda malicious. I strongly suggest you stop this or at the very least point out to users that this is actually not how it is supposed to work and how to revert it. NOBODY knows what permissions exactly are connected to this oauth token and it cannot be revoked using the usual methods. This undermines the whole oauth-system and "workarounds" like this familiarize users with similar shady methods which can be exploited by blackhats in the future.

[avaidyam]

@t-animal I suggest you find a replacement before you suggest to stop using this current method.

[t-animal]

@avaidyam It's a matter of priorities and I don't think you should blindly tell users who probably don't know what they're doing how to grant access to their google account with unknown risks. I guess you know why the oauth-system is superior to the username/password-system and this method undermines it completely. It's basicly the same as activating "allow less secure apps" in the google account settings and authorize via username/password -- except then the user at least has the ability to revoke access at any time using the designated methods.

[avaidyam]

except then the user at least has the ability to revoke access at any time using the designated methods.

Right, I'm not denying that. The issue is that the framework doesn't work unless you have a particular API token and there is no workaround. So if you'd like to use a third party Hangouts thing, you'll have to go with this.

[dequis]

I guess you know why the oauth-system is superior to the username/password-system and this method undermines it completely

No, there are two differences:

1. we never hear about the user's password (we don't want to)
2. we don't have to simulate a web browser clicking through forms to do the exact same thing you're doing with your web browser, which would be fragile since html changes are more common than api changes.

Funny enough, we're having this discussion in the repo of the hangups implementation, which does ask the user for the password and simulates a browser. Heh. They have it easy because it's python and you can just import fancy libraries to simulate a browser.

It's basicly the same as activating "allow less secure apps" in the google account settings

No, that also authorizes other password based login methods (POP3, SMTP, XMPP). SMTP is a common target for bruteforcing. It really is less secure.

[t-animal]

You do not know that, because you do not know what permissions are granted using this oauth token.

[dequis]

You do not know that

"That" being what? You can't retrieve a password having only a token. Google encrypts them like every service with at least a tiny bit of self-respect.

[t-animal]

You don't know what you can do or not do with this token or might be able to do in the future. It's certainly plausible that it allows to manage hangouts, alright. But it could authorize who-knows-what else. That is only one side of the coin, though. The bigger problem is that you actively teach users to undermine their security. Have you ever opened your browsers console on facebook? They do warn their users there to not paste anything, exactly because malicious people tell users to do so. And you legitimize this by what you're doing. The least you (and anyone using your library) should do is inform your users so that they know what they're doing, what consequences it has, how to undo it and why they should generally not trust someone trying to get access to their google account in such a manner.

[tdryer]

Giving hangups your password grants it unrestricted access to your Google Account. The documentation does explain how to revoke access, but I'll consider adding some kind of other warning.

[jusplainmike]

If anyone is having issues with where to put the token I solved my issues by replacing refresh_token = "xxxxxx" in the file auth.py
/usr/lib/python3.6/site-packages/hangups/auth.py line 130

[das7pad]

where to put the token

@jusplainmike It should not go into hangups.auth.RefreshTokenCache.set but into the file that it writes to, which is likely ~/.cache/hangups/refresh_token.txt.

The path may differ with your OS, to find the correct path, you can run:

from os.path import join
from appdirs import AppDirs
print(join(AppDirs('hangups', 'hangups').user_cache_dir, 'refresh_token.txt'))

Or provide your own path with $ hangups --token-path /my/path/to/refresh_token.txt

Note: everyone who has access to /usr/lib/python3.6/site-packages/hangups/auth.py on your host has control over your account now!