[tado] Add oauth2 authentication work flow

[andrewfg]

Resolves #18340

Signed-off-by: Andrew Fiddian-Green [email protected]

[jlaur]

@andrewfg - I didn't look closely into the code, but is there anything that speaks against using the OAuth2 core classes?

[jlaur]

is there anything that speaks against using the OAuth2 core classes?

Sorry, didn't check the issue until now. I guess ideally RFC-8628 should be implemented as well in core. But I understand a short-term solution is needed. I'm wondering though if the core classes could still be partially used, i.e. having the responsibility of refreshing the token? See for example https://community.openhab.org/t/oauth2-0-device-authorization-grant-device-code/127070. Perhaps other bindings are already doing something similar?

[andrewfg]

I looked at the core classes and I think it would be a very steep learning curve for me to implement the new workflow. I would prefer either a) someone else do that, or b) use my current solution for the time being, and eventually port it back to core.

[andrewfg]

See for example https://community.openhab.org/t/oauth2-0-device-authorization-grant-device-code/127070.

PS that does not offer any solution. Especially not to OH core. I am fairly sure that my Tado solution could eventually be taken over into core. But it needs a huge amount of study on the differences between a one binding solution and a possibly generic RFC compliant general solution.

Also this PR is a migration from a legacy to a newer authentication model, and we don’t have the freedom to start from scratch.

[jlaur]

But it needs a huge amount of study on the differences between a one binding solution and a possibly generic RFC compliant general solution.

I fully understand. But did you consider this:

I'm wondering though if the core classes could still be partially used, i.e. having the responsibility of refreshing the token?

What I meant by this would be to simply use the store for persisting tokens through OAuthClientService. So you would implement your custom flow in the binding (which you already did), but you could then save the access token response, probably by calling importAccessTokenResponse.

The benefits would be:

• Token refresh will be handled by core implementation which is already quite reliable.
• Since the standard store is used, tokens will be included in backups (and there won't be issues with file-based Thing configuration).
• When later (potentially) implementing RFC-8628, this wouldn't be a breaking change for users, since the same store is used.

What is currently missing in core is the method of doing the initial authentication, but everything after that should be supported already.

If you want to go down this path, I can offer my assistance.

Btw, I did something similar in the Bosch Indego binding. I could not use any standard grant flow, so I had to provide a hacky way for obtaining the code. After that I was then able to use the core implementation for storing and maintaining tokens.

[mherwege]

Btw, I did something similar in the Bosch Indego binding. I could not use any standard grant flow, so I had to provide a hacky way for obtaining the code. After that I was then able to use the core implementation for storing and maintaining tokens.

Another binding I recently changed to take that approach is the BMW binding. It just uses the store and the token refresh mechanism, not the initial grant flow.

[andrewfg]

Ok. I will give that a try today.

[andrewfg]

Ok.

I refactored the code in order to prepare for an easier migration of the "device code grant flow" into OH core. The prior code is split into two parts -- namely the tado specific part that stays in the binding and the generic part that could eventually be migrated into OH Core.

I won't yet move it into core, since I want to test it well.

I was not able to use the oAuth store for persisting the "device code grant flow" results, so for the time being I am persisting that in the thing handler configuration instead.

[andrewfg]

Migrated the oAuth workflow into openhab/openhab-core#4632