From what I"ve read, improved authentication wouldn’t have helped, since the vulnerability was one that didn’t require a login to exploit.
Support for other providers per this thread would allow you to seamlessly put hass behind a secure reverse proxy (eg Cloudflare Zero trust + cloudflare tunnel) such that no unauthorized traffic ever gets to the hass front end, which avoids the vulnerability. You can do this today (and it did prevent the vulnerability), but you end up with “double login” issues and no way to use the mobile apps seamlessly. Similarly Alexa/google assistant integration can’t work well without providing a bypass for the proxy.
1 Like
Seriously would appreciate some development work here. I’m currently trying to implement the Auth Header workaround to enable SSO via Authentik and it is hurting my brain. A nice streamlined and integrated solution would be much appreciated!
4 Likes
Personally I’d like to see OpenID Connect (bonus for having SCIM) with the ability to disable local username/password auth and the login prompt entirely.
There is many use cases for HA and those use cases continue to grow as the platform matures. There is always going to be people that don’t want / need SSO and will continue to use local authentication which is completely fine if that is what they would like. Though there is the power users like myself that has an IDP that would like to have a fully integrated experience. I think having OpenID Connect opens the door for the most integrations as most if not all of the major identity providers, cloud and self hosted support OIDC these days. Working in the enterprise world and working in software development I’ve seen many ways SSO is implemented.
I’ve seen some people mention that having SSO still has it where the local account still exists, essentially making two passwords to get into the system. While this is true for many applications I’ve used, we consider these to be break glass accounts. These accounts are secured to the highest degree possible and only used in case of SSO failure. To applications that have appliance type installs and HASS OS could be considered as such whether it’s running on a PI or in a VM, one could essentially disable local auth entirely when SSO is configured and if SSO breaks local access to the console could have a command to reset auth and re-enable a local administrator account to regain access to the system. Cause let’s face it, having direct local access to the system console usually means you have bigger problems to worry about.
I’ve also seen comments in other threads where people talked about the potential of having a disabled user in the IDP still have access to HA in the event they have the web ui open or the mobile app still logged in and their account isn’t disabled in HA but is disabled in the IDP. This kind of situation can be remedied by implementing SCIM. In the enterprise world we consider SSO with SCIM provisioning to be the gold standard. This allows the best of both worlds, a full SSO experience for the end user usually including just-in-time provisioning to allow users to access the system before the provisioning process has kicked off, and using SCIM this allows near real time (depending on how the IDP handles it) provisioning and de-provisioning of user accounts. This would essentially allow HA to continue handling session lengths like it does today where users can stay logged into dashboard or mobile apps indefinitely (if the admin chooses to allow that) but in the event a user gets disabled, the IDP can reach out to HA and disable the account which can immediately cause HA to revoke session tokens, long lived tokens, etc.
If HA supported these features, the way that I would set it up is like this. Users get onboarded into Authentik, through groups and polices Authentik determines that a user should have access into HA. Either through JIT provisioning or the SCIM process, a user account is created. HA’s local authentication system is essentially disabled so that when you access HA it immediately starts the OAUTH flow. The user is then free to login to HA using their existing credentials in Authentik and 2FA if it determines it’s needed. If SSO breaks for some reason a command in the console of HASS OS could restore a local admin and disable the redirection to SSO. However assuming systems don’t break that may never be needed, though it’s an option if it does. If a user gets deactivated or deleted from Authentik, it would then reach out to HA using the SCIM process and deactivate the account. HA would then revoke all sessions belonging to the user causing them to be logged out immediately.
One last thought around trusted IPs, I currently use this for my wall mounted PIs that I have for dashboards around the house. Depending on the IDP, I think in Authentik I could craft an authentication flow that looks at the source IP of the device and if it determines it’s a dashboard it might be able to bypass the login prompt and return a service account to HA to have that device auto logged in. Though I would not be opposed to having that function still natively in HA where it just doesn’t redirect to the OAUTH when it determines the IP is trusted.
HA is an amazing project that I couldn’t imagine my smart home without. It has the potential to teach people so many things about data analysis, integrations, importance of privacy, and not relying too much on the cloud, that I’d love to see identity management become part of that. Whether an admin wants to use cloud identity management or something local should be entirely up to them, HA should just have the options open for anyone that wants to use it.
13 Likes
+1 for having OIDC + the option to disable local authentication.
OIDC is the de-facto standard for modern authentication, so the 3rd party auth provider can then implement things like WebAuthn (Passkeys etc.). Also, there are already a lot of different options for 3rd party OIDC providers for different scales and use cases (also open source ones), so there is no point in trying to write a custom implementation.
We should keep local accounts/authentication for anyone who doesn’t want to setup a 3rd party IDP, or wants to keep it as break glass account, but once OIDC has been enabled there should be an option to turn off local auth for anyone relying entirely on the external auth.
8 Likes
Another +1 for OIDC as an option for those that want or can set it up.
In a landscape where unRAID/FreeNAS/etc make self hosting as easy as pick docker, config proxy, enjoy we need to think larger than individual applications and understand that many services such as HA will be part of a larger ecosystem. It may sound a bit like “enterprise at home” but in reality most, if not all, of the security products/protocols we use at home once came from enterprise.
The awesome folks that built Authelia, Authentik, CrowdSec, Opnsense, etc have laid the groundwork for self hosting to be relatively easy and secure to near enterprise levels. What we need now is the application vendors to start enabling those security features.
5 Likes
SSO integration would be great. Authentik became very useful for my homelab.
5 Likes
+1
Out of the dozen or so services I run on my home network, HA is the only one that doesn’t support SSO. I even use SSO to stream movies from my file server to my TV.
Historically SSO has been more of an enterprise thing, but it’s changing now. It’s not difficult to set up as long as the application supports it, so it’s not out of the question that home users would be using it.
SSO is a big improvement to the end user experience.
4 Likes
I think the key here is whether or not Alexa, Google Assistant, and Siri can be configured easily to work with SSO. If they can’t, that might be one reason HA doesn’t have that support.
I don’t see how the two things are linked. It’s not like any of those Voice assistants are authenticating against Home Assistant with user accounts.
4 Likes
Hey everyone,
It’s nice to see that this FR still gets a lot of support, even though I wrote it half a year ago! Maybe this will give some indication to the developers that external authentication sources (based on OIDC) are something that Home Assistant enthousiasts want (in their homelabs).
Some clarifications from all the messages above:
- The current blocker for this issue is developer maintenance burden and it not being on the roadmap due to perceived lack of support. There is no technical reason this could not work. Actually, Home Assistant already uses OAuth2 for its login, just with internal accounts, so external integrations will likely be fine (including voice assistants or Google/Alexa).
- The use of SSO should and will always be optional. If you are wanting to use your Google (Workspace) tenant for it, be my guest, but that’s up to you to configure the OIDC parameters. Most people will use this likely for Authentik, Authelia or similar within their home ecosystem. Nobody is being forced to open their home to login through the Google ecosystem here.
- You are still welcome to contribute to https://github.com/christiaangoossens/hass-oidc-auth or https://github.com/home-assistant/frontend/pull/14471. While I don’t have the time (or more specifically time to get knowledge of the relevant Home Assistant codebase) to integrate these first steps, creating a way to redirect externally during the login process allows me to create a HACS plugin for OIDC. I am still open to working on that when the frontend/app options are available. If you would like to help, or have a question, you can also send me a personal message or tag me here.
Regardless, thank you everyone for your comments and engagement.
Kind regards,
Christiaan
17 Likes
I would also very much appreciate the ability to use an OIDC add on for SSO
4 Likes
As others have mentioned, OIDC/SSO integration would awesome feature. My homelab is using an IdP to authenticate to many other services. Making tools more accessible leads to a higher adoption rate.
I understand the initial hesitation from considering this feature years ago. The landscape has shifted and self hosting IdentityProviders is becoming a norm. At this point, its unclear what the current holdup considering this feature. Home-Assistant is filled with hobbyists exploring and the perfect community for early adoption and championing modern authentication protocols.
There are many skilled individuals willing to contribute. christiaangoossens work showcases this! Could the project maintainers provide a set of goals that the community can build towards?
4 Likes
@frenk - lots of interest here in getting this feature working, where are the HA devs on approving the changes necessary to allow for other auth options?
2 Likes
I would love to see this implemented. I use an IDP in my homelab and it would be nice to authenticate against it for HomeAssistant. This would reduce the number of accounts required for those in my home to access my services.
2 Likes
Chiming in just to add another voice to the crowd. I’ve been following this post since it was made.
I’ve configured just about all of my applications to authenticate with Authentik. Home Assistant is my last holdout. Improved support for external authentication would be a huge deal for me.
1 Like
Same for my setup, have almost all applications now integrated via openid into my keycloak IDP. Would be amazing to add home assistant to that list of applications 
2 Likes
+1
Looking forward for this feature
Home Assistant Passkey support when?
1 Like
+1 for OIDC please.