The attitude of the HA developer(s) keeping this feature out is the same reason I canceled my Nabu Casa subscription.
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.
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.
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.
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.
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.
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.
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.
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
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
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?
+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.
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.
Google is not safe.
You rarely need to use the 2FA. Your Chrome browser is normally authenticated by a cookie. All it takes is a phishing email at the wrong time where it fit something you expected and an attacker has your account. He can even change password without 2FA or using 2FA from an app in the browser. It is so incredibly unsafe.
Just watch this guy Watch Hackers Breach My 2FA Like It's NOTHING - YouTube
Or even more touching this one I Got Hacked & Lost EVERYTHING! - YouTube
Sure some will say he is an idiot and that would never happen to them. BS! It will happen to any of you. I work in a place where we all get trained and tested in avoiding fishing. Noone has 100% perfect score. We all get caught and win some extra online training. We get hardended by the initiave but not 100% perfect. I do not want any cloud based SSO as an extra way into my HA. WHEN I get attacked I want the damage limited.
And the whole principle of HA being as much local only as possible does not match well starting to implement and maintain a lot of new 3rd party authentication schemes.
And finally if you are among the 0.01% users that implement enterprise like SSO schemes in your private homes, then you should also be able to implement it with a couple of fellow geek friends and make a custom component. I would hate to see Nabucasa staff spending time and my subscription money on maintaining this instead of implementing things for the common good. This really belongs in HACS realm
I have the feeling that you are thinking that the SSO service can only be hosted by some cloud service. I’d like to remind you, in that case, that you can have a SSO solution at home like Keycloak. It would totally be just local and it would integrate Home Assistant into a bunch of other services exposed to the family forcing the members of said family to remember only one account.
What’s so wrong about wanting Nabu Casa to focus on things that really matter and let the community provide the option for those that want SSO?
There is nothing wrong with that, in fact that’s what is being advocated for. However a change needs to be made to the front end to allow redirecting to other auth providers, and the folks at nabu casa won’t approve the change.
My comment was on the technical issues (that are actually not there) to allow such a feature, not the development of that by Nabu Casa or other developers. In that case the real problem could stem in the refusal of accepting such a PR, in case an independent developer wanted to give this gift to the community.
So my question gets to be the following. Let’s assume Nabu Casa doesn’t want to use their money and time to develop this feature. Will they accept a perfectly written PR that would implement the feature without breaking any current local user/password use case? If not, why?
I hope the most recent vulnerability was a serious wakeup call and has made the core team re-evaluate their stance here. This was truly the worst case scenario. I no longer feel comfortable exposing homeassistant to the internet without being behind a reverse proxy + tunnel. This sadly breaks seamless mobile app access and support for alexa/google home integrations. Has there been any update on support for external auth providers?