Open letter for improving Home Assistant's Authentication system (OIDC, SSO)

Quick progress update, I worked on it for a bit here: christiaangoossens/hass-oidc-auth: OpenID Connect authentication provider for Home Assistant (github.com). Implementing OAuth/OpenID is not the problem, I can do that and it’s very well possible (@elupus already made a basic version in the past), even as a plugin.

The problem is that the login screen has no way to redirect to some external URL properly (in a native browser view, instead of the normal HA view) and get back the callback code. The only - hacky - option is to use a popup, but I really don’t like that. In Android and iOS, the apps will also have to support opening either the native browser, a Android Custom Tab or SFSafariViewController with proper TLS support, hostname visibility and all CSS features (so Authentik also renders correctly).

However, I don’t know enough about the mobile and core code of HA to make this work and I sadly don’t have the time to find out. If anyone wants to pick that up, and make it possible to call a function for external redirect (I made a start in Allow DataEntryFlowStepExternal on the login screen by christiaangoossens · Pull Request #14471 · home-assistant/frontend (github.com), I am happy to assist you with the OIDC part.

11 Likes

+1 on this as well.

HA’s issue with local vs remote - those of us that are asking for this are hosting our own SSO solutions. How is it more secure to have the same password on 20 different applications at home? How convenient is it to have 20 different passwords on 20 different apps? How convenient is it to have one spot to change passwords for myself or others in my household? This is not a local vs remote issue, nor is this an enterprise use case as Authelia and Authentik are specifically written for home power users to SECURE and SIMPLIFY the locally hosted applications that we rely on every day.

The types of users that are asking for this are the users that are truly using the potential of this HA - because we understand technology and are trying to integrate it as seamlessly as possible into our lives.

I find it ironic frenck’s complaint about trying to implement webauthn in home assistant and how that failed when this PR would eliminate HA from having to deal with any auth. Just because one or a few users don’t have a need for this feature doesn’t mean there aren’t a ton more that do. This post alone, without much if any marketing is already engaging 150 users of the platform.

5 Likes

+1 here. While I am a little late to the party and I see some work being done on PR #14471, I felt I wanted to share another use case. HA authentication and authorization out of the box are very basic and an island. They do cover the needs of a lot of people. But there are many, many use cases uncovered.

My real life inspired example. Consider a small office where HA manages some lights, A/C units, a printer and so on. Everything else is integrated with OIDC: WiFi access, the local private wiki, the Nextcloud, the Wordpress for the public web, the local NAS… Everything. The only system that requires separate user management is HA.

In other words, I feel small offices are a very reasonable target for HA and that they require HA to be seamlessly integrable into the organization’s SSO flows.

Just my 2 cents.

2 Likes

I’d really like to see Passkey support added as that can be entirely self contained with zero reliance on third party infrastructure being available.

This would also be useful to facilitate signin on the various clients on mobile devices.

Passkeys have 2FA/MFA builtin as they require something you have (your device) and either something you know (your device pin/password) or something you are (biometrics).

Implimenting full WebAuthN would also add support for yubikeys.

All of this, I believe, fits into something a home user can set up once support is present.

5 Likes

I’m also eager to see this feature implemented.

Home Assistant is currently the only island I have as everything else is integrated into AAD - even ZoneMinder; which I had to do some header magic with :wink:

Either way, my parents don’t like to deal with username and passwords so their phones are registered with AAD and do SSO; would be nice to see HASS also join the SSO party so that I don’t have to manually handle that for them. I also think it’s more secure - I have conditional access and 2FA enforced and no self-built system can provide the vast amount of security features well established industry solutions can.

Passkey/WebAuthN support would probably be more logical to implement anyway, since it would target a larger audience especially that Passkey is a new standard backed by Apple, Google, Microsoft…

2 Likes

+1 from me too.

Even if it is just to limit the amount of passwords and user accounts floating around.

1 Like

The attitude of the HA developer(s) keeping this feature out is the same reason I canceled my Nabu Casa subscription.

5 Likes

I will say this is the kind of feature I would be completely willing to pay a premium for. My HA server has too much access to my entire house for security to be anything less than enterprise grade.

9 Likes

Terrific write-up.
Please allow me to add to this; authentication, while it should include SAML, OAUTH2, OIDC, such protocols are dependant on an external Idp (Identity Provider). I don’t disagree that HA should have support for these protocols, nor do I disagree that external Idp’s should be supported. Azure, Okta, PingFederate, AD, etc. are all suitable and stable Idp platforms.

Authentication, as you very clearly state is just on part of the equation.
Permissions are in large need of addressing.

There must be support for limiting access to various components. From as little as individual entities (if the admin wants to go that far), to the difference between an owner (this should be setable, not just through on-boarding), admin, user, guest, AND dashboard access (perhaps this could be without any id or password and be able to set a specific dashboard usable by tablet interfaces for basic controls to avoid managing yet another user.

Password management is also desperately needed in the authentication system. Enforce some minimum password standards and add (with end-user provided API key), password validation against service like HIBP to enforce stronger passwords. Better yet, move this towards token based, and hardware key based access, and eliminate passwords altogether.

This is truly a LOT of work, so no argument that this will not be done overnight. However, since Security and Privacy are big drivers for HA, I respectfully ask that these be given some attention and priority. Building these things out, will also support further building integrations, including those with Azure, AWS, GCP, etc.

4 Likes

This is a complex issue, I think. I can see where a lot of the users that have commented here are coming from, but at the same time I think I understand the reluctance of the core developers to add support for more advanced authentication systems. I don’t want to have to set up my own authentication system just for Home Assistant, nor do I want to be dependent on one that is web based should my internet connection fail. I don’t trust 2FA or any system that requires specific hardware or software that if lost could allow someone else to gain access to my system.

1 Like

Just to be sure: this is not a question of one or the other. It is the native authentication (nothing wrong with it) PLUS an external authentication. It will always be optional. If you don’t want to use external auth: fine, don’t.

Taking an example from stackoverflow login - green is external authentication, red is native authentication. The login screen for HA could look exactly like that.

And whether you would want Facebook, Google or self hosted solutions to authenticate would totally be up to you. Don’t configure it? Use native auth.

2 Likes

With the announcement of this remote vulnerability in Home Assistant (Authentication bypass Supervisor API · Advisory · home-assistant/core · GitHub) I think it only further strengthens the requirements for supporting industry standard authentication and authorization options in HA.

7 Likes

I’m not aware of the internals of the problematic code. But having an additional method of authentication (which is what this topic is about) would probably have not had any effect regarding the recent vulnerability. The SSO implementation would only provide convenience by not having to log in if implemented parallel to the existing mechanisms (which would make sense, as otherwise you couldn’t login if your IdP was offline). It’s not adding any security if the other login-mechnisms are still available.

1 Like

You are correct, a proper SSO implementation doesn’t permit alternate methods when configured. At a minimum you would need to be able to limit legacy auth usage, perhaps to local network or trusted hosts only.

2fa that requires specific hardware (i.e. a hardware token) is very secure my nature of the fact that if the token is lost, just the token isn’t going to give someone access. A setup with a hardware based token, or MFA function, is designed to handle when the token or validation device is lost/stolen.
Having said that, it is insecure NOT to use 2FA/MFA.
There are many different ways to setup MFA on a given system. They do not all require internet access in order to function. The auth system is not something that you, the user, should have to setup independently of HA, it should be part of the system.
There are a lot of different ways to do this, any number of which might be suitable for some users, but not all. That’s why flexibility is important.

For example, is SAML Auth was added allowing me to use my Google account to access HA, that doesn’t mean that it is or would be the only way to access it. Even Google has mechanisms setup to enable device auth when there is not internet connectivity. These type of things are designed in the solution.

1 Like

I’d also like to add a +1 to having the ability to use an external IdP

I wish I could use Azure AD to handle authentication so I can use things like Conditional Access policies to restrict who is even allowed to attempt to sign in with things like device compliance, location blocks, etc

3 Likes

If this feature was added my first question would be “how do I turn it off?”

Google authentication for my Home Assistant? Right. Someone gets my Google account owned and they have direct access to my home.

And this is anthing but local. Another cloud dependency. Think. I am home and I cannot login because my ISP has an outage. Or do you want to also use local authentication? Oh yes. Multiple access ways a d multiple passwords to keep safe. No thank you!

I hate it. This type of feature is HACS material.

Someone mensions this in context of the recent vulnerability. It would have helped zero. The issue was API that was exposed without needing any authentication. By mistake naturally. Additional 3rd party authentication schemes would not have done anything to that! Nothing at all

2 Likes

That is some strong opinion here.

I think you misunderstand what OAUTH is about. First of: it is always optional, so there most likely would be nothing you would need to turn off, rather you would need to turn it on.

Secondly you would always need to specify what oauth service you would allow (such as Google). Many here mentioned something like Authelia or Keycloak - both self-hosted versions, so you don’t need to rely on Google if that’s against what you believe in.

Additionaly the main point is that I personally do NOT want to rely on some authentication by HA, because I believe it is better relying on a service which all it does is authentication than a service that is just one feature of many.

I don’t want to refute your claim that if someone were to own your Google account and you would have specified Google as an oauth provider, you would open the doors to your HA install - but honestly, don’t you think it would be worse if your Google account were compromised (if you use Google)? Also don’t you think it would be a lot harder to breach Google compared to breaching HA?

8 Likes

+1 to this. I just setup a local Authelia server, and now all my local apps have a unified username/password via SSO. For HomeAssistant I made it with work via commandline auth, but it’s not great. HA doesn’t know my username, and it only works for a single-user HA system.

4 Likes

If someone is getting into your google account, then I suggest asking yourself why?
Not to be obnoxious or anything, but think about that.

Google requires 2FA for all accounts. This is a good thing, because just username and password is not secure. In fact, your google account is by definition more secure than your HA login.
First, there is no such thing as totally secure. We could all use MFA, and hardware keys, and certs, and encrypt everything. Someone who wants access to your data, is eventually going to get it if they put in enough time, money, and effort.
With that out of the way, unless you are in the headlines, or a very popular well known figure, you are not likely to be a specific target. Maybe a target of opportunity, but that’s all.
Take away the opportunity. When you leave your house, do you lock your desktop (you should, I do).
Does your password managerr lock, after a certain amount of time and after you have been away for a little while? (mine does).

I only say all of this, as many breaches can be avoided. I don’t believe the suggestion is to strictly use Google Auth, but give people a choice. At a minimum use 2FA with OTP by default. That is already an option, simply make it required. Then offer the option to extend authentication to another Idp. Azure, Google, PingFederate, and Okta all do a much better job of protecting accounts in general than any one person can typically do on their own.

5 Likes