Google add-ons use deprecated OAuth out-of-band (flow)

[wborn]

Some add-ons using Google APIs still use the deprecated OOB flow. It is no longer possible to create new Google OAuth tokens using the OOB flow since February 28th.

See: https://developers.googleblog.com/2022/02/making-oauth-flows-safer.html#disallowed-oob

As a result it is no longer possible to setup the following add-ons:

• Google Cloud Text-to-Speech
• Google Cloud Speech-To-Text
• Nest Binding

These need to be changed to use one of the other flows.

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/google-tts-can-not-authorize/133906/4

[Jelle28]

Is there any redirect_uri that can currently be used as an alternative for Nest Binding?

[wborn]

I had a look at this today and got Google TTS working by changing the redirect_uri to https://www.google.com .
When creating the Google OAuth client ID credentials in "Create OAuth client ID" you should now choose "Web application" as "Application type" (instead of "TVs and Limited Input devices"). Then make sure to add https://www.google.com to the "Authorized redirect URIs".

Then after opening the OAuth URL in your browser it will redirect and you'll then need to copy/paste the "code" URL parameter value to the Authorization Code configuration parameter in openHAB. It would ofcourse be nicer if it would redirect to openHAB itself which could then automatically use it. But at least it is a good start to get it working again. 🙂

It also works for the other add-ons like this, so I've created a few JARs using https://www.google.com as redirect_uri for now:

• org.openhab.binding.nest-3.3.0-SNAPSHOT.jar
• org.openhab.voice.googlestt-3.3.0-SNAPSHOT.jar
• org.openhab.voice.googletts-3.3.0-SNAPSHOT.jar

Use the following URLs for getting an authorization code:

Google STT/TTS

https://accounts.google.com/o/oauth2/v2/auth?scope=https://www.googleapis.com/auth/cloud-platform&access_type=offline&prompt=consent&include_granted_scopes=true&response_type=code&redirect_uri=https://www.google.com&client_id={{ClientID}}

• Replace {{ClientID}} with your OAuth client ID

Nest Binding

SDM

https://nestservices.google.com/partnerconnections/{{ProjectID}}/auth?scope=https://www.googleapis.com/auth/sdm.service&access_type=offline&prompt=consent&include_granted_scopes=true&response_type=code&redirect_uri=https://www.google.com&client_id={{ClientID}}

• Replace {{ProjectID}} with your Device Access project ID
• Replace {{ClientID}} with your OAuth client ID

Pub/Sub

https://accounts.google.com/o/oauth2/v2/auth?scope=https://www.googleapis.com/auth/pubsub&access_type=offline&prompt=consent&include_granted_scopes=true&response_type=code&redirect_uri=https://www.google.com&client_id={{ClientID}}

• Replace {{ClientID}} with your OAuth client ID

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/google-tts-can-not-authorize/133906/8

[Jagohu]

I have a few Nest Protects, which don't link up even with this method - I keep getting this after inserting the link(https://nestservices.google.com/partnerconnections/{{ProjectID}}/auth?redirect_uri=urn:ietf:wg:oauth:2.0:oob&access_type=offline&prompt=consent&client_id={{ClientID}}&response_type=code&scope=https://www.googleapis.com/auth/sdm.service) and selecting my Google account:

Can't find devices to link to NestProtectNew
If your home has multiple members, the person who first set up the home must migrate their Nest Account to a Google Account before you can link to NestProtectNew

The Nest account is migrated and works fine with logon via Google.

If I replace the link in the end of the authentication link to https://www.google.com (like this https://nestservices.google.com/partnerconnections/{{ProjectID}}/auth?redirect_uri=urn:ietf:wg:oauth:2.0:oob&access_type=offline&prompt=consent&client_id={{ClientID}}&response_type=code&scope=https://www.google.com) then I also get an error message (NestProtectNew being my project name):

Can’t link to NestProtectNew
Please contact NestProtectNew if the issue persists

It also seems like that there are no traits listed in the Device Access Console for Nest Protect - can it be the reason why?
Traits Available to Nest Devices
Doorbell
Structure
Room
Thermostat
Camera
Display

[wborn]

Hi @Jagohu, you should also use different URLs for getting an authorization code. I've added them to my initial comment. I ran out of time yesterday to document this and also did not have time to test all add-ons. But I now did and they all seem to work this way. 🙂

It also seems like that there are no traits listed in the Device Access Console for Nest Protect - can it be the reason why?

The SDM API does not support the Nest Protect, that is also clearly mentioned in the add-on docs:

The SDM API currently does not support Nest Protect devices. There are no structure Things when using the SDM API, because the SDM API does not support setting the Home/Away status like the WWN API does.

[Jagohu]

Thanks - shoot, it's a pity that it doesn't support them - I thought from the OH documentation that it does - I missed the detail between the SDM and WWN. Well, maybe someday.. Thanks a lot!

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/nest-configuration-broken-google-throwing-an-error/135395/2

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/google-tts-authentication-error-400-redirect-uri-mismatch/136695/3

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/openhab-3-3-release-discussion/136925/63

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/google-nest-device-access-console-now-available/105404/347

[resetpointer]

Was there a fix for OH-2.5.x?

[wborn]

Not by me. Maybe it's time to upgrade? 😉

[resetpointer]

@wborn,

I upgraded to version 3.3.0 and found that NEST OAUTH2 authentication is not reliable. I got it to work a few times but couldn't re-authenticate using the typical work-flow has described here. Below is the error, please let me know if it is possible to enable debug trace of the actual URI that OH3 uses.

14:57:58.470 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model 'nest_sdm.things'
14:57:58.507 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'nest:sdm_account:my_nest_sdm_p' changed from UNINITIALIZED to INITIALIZING
14:57:58.509 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'nest:sdm_account:my_nest_sdm_p' changed from INITIALIZING to UNKNOWN
14:57:58.645 [ERROR] [.oauth2client.internal.OAuthConnector] - grant type authorization_code to URL https://accounts.google.com/o/oauth2/token failed with error code invalid_grant, description Bad Request
14:57:58.646 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'nest:sdm_account:my_nest_sdm_p' changed from UNKNOWN to OFFLINE (CONFIGURATION_ERROR): Failed to authorize SDM client. Check the authorization code or generate a new one.
14:57:59.533 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model 'nest_sdm.things'

FYI, I am able to exchange the authentication token that was copied from browser URL for an access token with this command

curl -L -X POST -H "Content-Length: 0" 'https://www.googleapis.com/oauth2/v4/token?client_id=${NEST_CLIENT_ID}&client_secret=${NEST_CLIENT_SECRET}&code=${NEST_AUTHORIZATION_CODE}&grant_type=authorization_code&redirect_uri=https://www.google.com'

I am not sure why OH3 is giving me that invalid grant error. Is it possible that this is the same bug that was addressed in OH-3.4 as described here: #12711

thank you,

[resetpointer]

@wborn

I can confirm that it was the bug related to the fix that was patched in version 3.4 (PR 12711).
Authorization only worked for a newly created credential, it wont work if auth_code is updated on an existing credential.

I also want to let you know that if nest sdm & pubsub credentials are defined in a static thing file, how does OH3 or nest_sdm plugin know not to exchange authorization_code for access_token again every-time the thing file is updated? I am curious, because I do not know how PR-12711 handled that scenario.

[resetpointer]

@wborn

I just realized that I am using the latest version with the said patch (PR 12711), version 3.3.0.1

As the result, at least when configuring the nest things file for the first time, SDM authorization code and pubsub authorization codes have to be provided only for the first time, after that if modification is made, user must blank out these two fields for nest sdm and pubsub to work:

sdmAuthorizationCode=""
pubsubAuthorizationCode=""

Although I have not tested via web-UI, I have a feeling that it would only work with this same work-flow.

I think this is a bug, we should address in the documentation website, oauth2 registration code, web UI or some sort of verbose log.

PS: there is a separate issue I found with Oauth2 reading the access token response; perhaps you can look at it.

thanks and sorry for the noise here!

[wborn]

I don't think binding code can be made aware of which means are used for configuring Things (files/UI). So perhaps it is best to add some docs for this.