Revisit rules for OAuth usage in config flow (for Google) #692
Replies: 6 comments 31 replies
-
I'm not sure how much more easy it'll be if we allow client id and secret in the config flow. The hard part is the cloud application setup, not pasting the client credentials in configuration.yaml or in the config flow. I think it's a good idea to move to installed app auth flow for Google. It's working well in my WIP branch for Google calendar. |
Beta Was this translation helpful? Give feedback.
-
I think this is a good idea. I wonder if we should adjust the exception to be for cases where the client ID/secret are bound to a single user account? (which is the case here for Nest) |
Beta Was this translation helpful? Give feedback.
-
I would opt for a separate page/panel to add developer accounts (or name it something similar) to register OAuth implementation and NOT make it part of the configuration flow. What we can do in the config flow, is detect there are no implementations -> redirect the user to the flow to add/register an implementation/developer account. After adding such an account, we can restart the integration setup. The idea would be similar to blueprints. Register developer accounts/connections to use with integration instances. It keeps them decoupled, re-useable, and manageable. |
Beta Was this translation helpful? Give feedback.
-
One reason I did the survey of top integrations is to see what kind of usage something like this would get. Looking at the top 100 integrations I believe these 4 are eligible:
Has there been discussion with Tuya or Home Connect about cloud linking? Basically, this is why I propose just using the config flow is that i'm not sure there would be sufficient use for a central user interface for this. How I interpret this variation on the proposal is that we actually do not have a problem with users entering client id and secret into text boxes when setting up integrations. Perhaps we could take a step back away from implementation approach and discuss the principles with respect to OAuth? I think i'm trying to reverse engineer these a bit, without understanding the user problem we're trying to solve. |
Beta Was this translation helpful? Give feedback.
-
Starting a side thread to go into a detailed overview of a global feature for developer credentials as a path forward to solving the Nest use case which has no options for any streamlined paths today. (Other integrations already have a streamlined path for cloud link, but have a broader need for infrastructure simplicity in order to support much more complex configuration use cases that cannot be supported with yaml) Developer CredentialsA new component will be added for managing Developer Credentials. A Developer Credential is:
The credentials component can support these operations (e.g. websocket/storage) similar to blueprints:
Users have an expectation that a deleting a credential means it is completely gone (all copies are gone, all access tokens or refresh tokens are gone, etc). Edit is not a supported operation. Example user flow end to endAs an example user journey for illustration:
An integrations config flow remains unchanged, and relies on the oauth config flow to pick/manage/show auth implementations and create config entries on its behalf. The integration config flow doesn't need to know about details of credentials. Authorization Server and Authentication ImplYou can think of this effort like splitting up the responsibilities of a LocalOAuthImplementation, and changing up the registration mechanism. Integrations are still responsible for declaring the Authorization Server to use: an authorize url, and token url. We consider these degrees of freedom between Developer Credentials, Authorization Server, and Config Entries to inform how registration works:
The number of combinations implies to me we may want a pretty flat representation of these things, but we can get into this in detailed design next. Integration setup will register an Authorization server, and Developer Credentials for any accounts currently in yaml. Integration setup for a config entry is similar to today (e.g. asks for an auth implementation for a given config entry). The config entry has a pointer/reference to a developer credential, which is also used for delete protection above. When considering the user experience, integrations may need to customize Developer Credentials setup with extra instructions/markdown or links -- though many integrations with trivial authentication setup may not even need this. A handful of integrations will operate on Developer Credentials at a lower level, similar to how yaml compatibility works, or how oauth config flows are customized today. This keeps integration specific complexity within the integrations, allowing for more integrated user experience while keeping the developer credentials APIs simple e.g. (screenshot #1, screenshot #2) shows an example config flow that constructs inputs that appear in the Authorization Server URL, with an integrated setup to minimize bounding back and forth between consoles decreasing likelihood of mismatched credentials. Or put another way, custom config flows must use the developer credentials infrastructure and wiring. I would like feedback on this high level direction before getting into the next level of implementation details. |
Beta Was this translation helpful? Give feedback.
-
Closing this architectural topic, as we have covered this now. ../Frenck |
Beta Was this translation helpful? Give feedback.
-
Summary
I'd like to make setup/onboarding easier for Nest and Google integrations by revisiting our design standards for OAuth
Current State
Our current stance for integrations that expose devices is that config flows should be used instead of configuration yaml. However there is some nuance for OAuth which I interpret as something like:
Proposal
Change our policy to be:
In the last year since proposing home-assistant/core#44529 I've worked with Nabu Casa and Google on assessing feasibility of an account linking process for
nest
. The current state is that there is not a workable solution.I am proposing we allow for Google and other integrations what we currently allow for Tuya.
Specifically for Google integrations, the work involved is:
Additional Notes
My 2021 review of Home Assistant + Google Authentication that i've been using to revamp nest authentication and config flow. Has notes from a discussion with @balloob where we sketched out this proposal.
I surveyed the top ~50 integrations that involve auth, and figured it was worth sharing this summary:
My prior 2020 review of Home Assistant Nest Config Flow
We could have a shared place in the UI in home assistant to enter client ID and secret could be possible (e.g. somewhere else in settings), but does not change what the user has to do (enter a client id and secret). However, it seems simplest is to just let users share the client/id secret between the two projects. We could alternatively have a shared authentication library somewhere for Google creds if helpful, but not sure it is worth the complexity.
Beta Was this translation helpful? Give feedback.
All reactions