+1 from me too. I have a dozen services I run for my family to retain privacy and control over our data and home assistant is the only one that has a “different” login method.
+1
Sidenode: I have installed oauth2proxy with keycloak as access security service, which works fine. Unfortunately, HA’s in-app browser does not allow WebAuthn (Passkeys). To the extent that HA does not integrate SSO, it would be a good start if at least the in-app browser in iOS would allow WebAuthn requests.
1 Like
+1 count me in reg. OIDC SSO SAML2
+1 SAML authentication and better RBAC would be great
Before sharing my thoughts, I am a technical pre-sales (principal Solutions Engineer) for Okta and have worked on numerous OAuth2.0, OIDC and SAML project in the past 8 years I have been at the company. I work closely with some of the people that author the RFC’s around those specs.
I agree with @christiaangoossens and are willing to share some of my thoughts as well, as I have been looking to integrate my HA with Okta/Auth0 for a while now.
First of all: Yes HA should allow external IdP’s to integrate for authentication, and potentially even for authorization (allowing external AuthZ servers for OAuth2.0 on API’s). This will allow for a range of functionality:
- Self-Service or approval based registration of new accounts
- Integrate with much stronger authentication like passkeys, biometrics, etc to open use cases like passwordless authentication (boosting security)
- Access Recertification campaigns so that admins are prompted to review and revoke access regularly
- Advanced features around brute force and credential stuffing attacks
- etc
Happy to further detail the benefits, but I will not bore you’ll with the sales pitch.
Now to the two “problems” at hand, let me respond to the decline message first:
“Credentials are only validated during login” and “no one will check back with the OpenID provider if the user is still valid” are not entirely true (anymore) - This is a decision to be made by how the thing is deployed. RFC’s like introspection (RFC7662) and token revocation (RFC7009) allow for token validation at the IdP, rather than local. But to Christiaans point, sensitive tokens should have a short lifetime, which means that the app should hit the IdP to get a new access token more often. When the account is blocked, the token will not be issued.
“Okta is actually smart enough in that if you are already logged in to it” - This is correct and incorrect at the same time. What happens it that when the app redirects to the IdP for authentication, the IdP may still have an active session cookie, due to recent login. This means no username and password (or passkey!!) is required. When a user is blocked, suspended or deleted, the session cookie will be invalidated and it WILL prompt for credentials.
To Christiaans point “where all your users have 2FA” and “you can circumvent the original 2FA”, this would indicate a bad deployment. This is called automatic matching and is considered bad practice. If a user exists locally and tries to authenticate with social, SIWApple or any other external identity, HA should always prompt for the local credentials before linking the two together. We documented this risk in the link below: “Insecurely linking accounts can allow malicious actors to access legitimate user accounts. Please remain aware of the following: For both manual and automatic account links, your tenant should request authentication for both accounts before linking occurs. In addition, every manual account link should prompt the user to enter credentials.”
Secondly “User logout at the IdP (OIDC provider) are not propagated to the consuming app” - This used to be true, as @christiaangoossens mentions in the 2nd issue solution part, meaning that when you logout from the Idp, it sends a signal to the apps to destroy any session, cookie, token it uses to keep the user logged in.
I agree with the solutions @christiaangoossens points out, however on this point “Alternatively, you could always prefix usernames with the OIDC provider name” I disagree. Much account linking (disclaimer above) is done on a user identifier. This ways you can easily allow a user to hook up their social accounts like facelook for login. If you mod the username, you will need to do a load of mapping magic and you will end up with duplicate accounts.
Please consider this my offer to help …
Thanks @balloob and @christiaangoossens for your thoughts … all of the above is not to criticise in any way, you seem very well aware of what we can and should do for SSO … Just trying to add to what you already mentioned in my own way.
Resources:
23 Likes
+1000 for RBAC & SSO from me.
These features are certainly not Enterprise-only. A “trust everyone all the time” policy is a tricky sell, potentially inhibiting larger adoption. I know I would absolutely not entrust all family members or guests to handle my Home Assistant installation responsibly; there’s simply too much available to each user by default, something RBAC alone would resolve.
1 Like
Hello!
Is it possible to disable showing user profiles on log in page for local network in HA 2023.12 ?
I use external server as virtual hosting via SSH-tunnel because I have no external static IP.
So when I log in from outside my home network my HA detects it as local and uses Local Auth Provider.
There’s a long thread about this on the 2023.12 release notes topic. You should post over there.
+1 for this, Just setting up authentik and was shocked to find HA cannot to Oauth2 etc. Quite bizarre for a platform that’s vision is a single integrated platform across multiple provider platforms - that’s exactly what SSO is from a login perspective.
To all those saying that it moves away from the “everything as local as possible” I have no idea why Oauth2 cannot be local (mine is) and who says that is everyone’s goal? For some yes, but for others not so much. HA is just as valid linking cloud platforms from disparate providers together.
1 Like
I came here to get my vote. I want to use my Azure AD tenant with my conditional access policies and mfa with HA
Yes please i want to add my azure ad to ha
My vote added so I can use Keycloak or Authentik.
Now Entra ID Supports Global Secure Access, which means I can keep my Home Assistant secure without needing VPN.
Can we please make this priority?
1 Like
+1
I would love to use my zitadel as oidc provider
+1 on this. Homeassistant is the only selfhosted application out of 34 in my network that doesn’t use oauth. Embarassing for such a large project
3 Likes
Hello first of all I would like to thanks all contributors on this such great project !
I did not took time to read the whole thread as it is definitely too long, all my apologies if I missed important information.
I am also interested in plugging an external identity provider via OIDC
If I check the current login flow on my HA freshly upgraded, I see it is already using Oauth mechanism with HA as a resource provider and as an IDP too:
https://[my-ha-domain]/auth/authorize?response_type=code&redirect_uri=https%3A%2F%2F[my-ha-domain]%2F%3Fauth_callback%3D1&client_id=https%3A%2F%2F[my-ha-domain]%2F&state=…
Checking the page “Authentication - Home Assistant” I also see
“* Configure integrations and other settings (coming soon).”
So technically the step to move forward seems relatively easy and seems already planned for that purpose, did I missed any comment in this part or any thread relative to this point ?
King regards
There is a button to summarise a thread below the first post.
That’s why you should read the thread. Why should someone else make an effort if you won’t?
2 Likes
Hello I did read the thread, with all my optimism I still hope it will be accepted in the future
1 Like
just chiming in to say that the devs can make their lives way easier if they implement something like https://next-auth.js.org/
NextAuth has support for pretty much every SSO method you can thing of (google, github) along with self hosted options like Authentik/keycloak etc.
If NextAuth was implemented, devs would not need to worry about constantly adding some new protocol as that would happen automatically via nextauth.
I think this would seriously make a lot of users happy and also make the devs lives easier as they don’t have to maintain a large number of authentication protocols.
2 Likes
My vote goes to Keycloak ! HA definitely needs to support the concept of SSO…
1 Like