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

[christiaangoossens]

Note

This discussion post is a copy from home-assistant/architecture#832 and https://community.home-assistant.io/t/open-letter-for-improving-home-assistants-authentication-system-oidc-sso to the new Feature Requests system as introduced in https://community.home-assistant.io/t/heads-up-feature-requests-are-moving/903057.

Please note that this open letter is really old (written in November 2022) and may be partially outdated.

Tip

While this feature request deals with the community request for integration of these features in the Home Assistant core, a working custom integration exists at https://github.com/christiaangoossens/hass-oidc-auth.

Neither the custom integration developer or the Home Assistant team provide any guarantees on the security and functioning of that custom integration within future updates of HA.

Additionally, note that the custom integration does not actually implement all proposed solutions from this post, as most are not possible within a custom integration.

This emphasizes the need for inclusion of this feature in the core Home Assistant code, such that these solutions can be implemented!

This is a meta-analysis and open letter for authentication in Home Assistant. I have been working with the OAuth2 and OpenID Connect specifications, both integrating them on the web and in Android apps for a few years now and I would like to give my input on its implementation within the project.

In release 0.77 the "new Authentication System" was activated. From this update onwards, both the web version and the mobile apps use OAuth2 to authorize the app or the web interface to access the Home Assistant API.

For authentication, a few providers were provided within Home Assistant:

• Home Assistant "Auth" Provider: username and password + TOTP
• Trusted Networks: authentication based on origin IP
• Command line: providing the entered username and password to a command line script (only possible in Home Assistant Core).
• Legacy API password: deprecated old way of authenticating

Current limitations

While this new Authentication system is a big step forward and enables nice features, such as building third-party external apps against the Home Assistant API by use of the OAuth2 authorization method to obtain a properly-scoped access token, it has a few issues. I will deal with them in their own subsections.

Additional providers within Home Assistant

There have been some PR's to include useful additional authentication providers within Home Assistant, such as:

• LDAP/Active Directory authentication provider core#37645: Added LDAP as a provider within Home Assistant, without the use of external scripts, such that it would also work within Home Assistant OS. However it got declined:
  LDAP/Active Directory authentication provider core#37645 (comment)
• Support openid connect like authentication providers core#32926: Added OpenID Connect to authenticate the user right in Home Assistant. This is the correct way to do OpenID Connect for apps, which only uses it for authentication and keeps your internal authorization system. This got declined due to: Support openid connect like authentication providers core#32926 (comment)

Update, after the initial publication of this post (home-assistant/architecture#832 and https://community.home-assistant.io/t/open-letter-for-improving-home-assistants-authentication-system-oidc-sso) more have been made, such as: home-assistant/frontend#23204

I remember also seeing some comments that maintaining these providers within the Home Assistant code would lead to possible security issues as it put a large burden on the maintainers to know the specifications, all their flaws and keep this secure.

Additional providers as plugins

With the new authentication system, it should have been easy to integrate new providers, such as LDAP and OIDC as plugins, possibly through HACS. I only know of one successful authentication plugin: https://github.com/BeryJu/hass-auth-header by BeryJu, the creator of Authentik, a project I have also followed from its Passbook early days. While the plugin itself works fine, if a header is passed, it updates the authentication screen to include a "Header auth" option which just has a button to detect the header and continue, the setup around it has problems.

Many users running Homelabs would like to tie Home Assistant into their existing SSO system, but as authentication proxies (using https://github.com/BeryJu/hass-auth-header) are the only option, proxy auth for apps using OAuth2 and/or using service workers is not the right idea.

Currently, you can find many issues and Reddit threads, such as home-assistant/android#1438, authelia/authelia#1842 (comment) and goauthentik/authentik#884 (comment), which include ideas to disable the service worker, exclude certain paths from the proxy auth or only enable proxy auth for /auth/*.

For apps implementing OAuth2 as their authorization layer, such as Home Assistant, one should have access to the login page and the static assets, as those are vital to allowing third-parties access to the API. Other applications should always be able to make an OAuth2 authorization request, without being stopped by the proxy auth first. They should however be stopped at the authentication phase right after, but as there are no OpenID Connect or LDAP plugins that integrate to that stage (like the PR's above), it is not possible to go that route right now for integrating Home Assistant with your current SSO, be it at home, or for a company.

Android Mobile app uses Webview instead of Custom Tabs

Currently, the Android Companion app uses Webview (https://github.com/home-assistant/android/blob/fa001ffc29fc1ff8bfd2f47f0628666edbe3f386/app/src/main/java/io/homeassistant/companion/android/onboarding/authentication/AuthenticationFragment.kt) for its Authentication Fragment.

The Android Webview implementation lags behind in its support of modern web standards, does not share a context with the main browser and is therefore not recommended for use with OAuth2 in the authorization-community. This also lead Google to disallow embedded webviews for OAuth2 (read this article to find out more why it's a bad idea).

Instead, you should use Custom Tabs. These tabs are part of the main browser (often Chrome) and share a session with this browser. If you are already logged in with the main browser, you will be logged into the Custom Tab as well. Additionally, as the tabs use modern Chrome, they have access to all modern web standards.

Doing this would also prevent issues like: goauthentik/authentik#3304 and BeryJu/hass-auth-header#124, where the webview does not render Authentik correctly and does not support FIDO2 Security Keys, which totally disables Authentik for some users.

Proposal

Having looked at some current identified issues, I would like to propose the following:

Home Assistant should welcome external authentication

The Home Assistant project is about connecting with many home devices and integrating as many different devices to one platform. It is not about creating the strongest authentication method. We should leave strong auth, or the option to use stronger auth, to other platforms, such as Authentik and Authelia at home, or Keycloak, Azure AD and Okta in the enterprise setting.

External SSO authentication providers allow for many benefits that will likely not be included within Home Assistant's native authentication provider, such as:

• Support for WebAuthN, FIDO2 security keys and other extra 2FA options, such as push-based mobile authentication
• Detection of strange logins, such as based on changing locations of user logins (for instance: you always login from Amsterdam, but suddenly you are in the Maldives) and blocking of such logins dynamically
• Requiring different or additional 2nd factors within or outside of a network.
• Native SSO, where you never enter any password within a trusted context

In conclusion, external SSO providers will always be better at authentication than your own solution. Embrace them, not extinguish.

Mobile Apps

The mobile apps should not assume anything about the authentication/authorization process, except that it is OAuth2, happens within a webbrowser and uses the Authorization Grant flow with PKCE (RFC 7636). This is the recommended OAuth2 flow for native clients as per RFC8252.

They should open this authorization endpoint URL (https://YOUR_INSTALL_URL:8123/auth/authorize?......) within a Android Custom Tab on Android, the native browser or the SFSafariViewController on iOS and should expose a return URL (homeassistant://auth-callback) to call back with the authorization code within the OAuth2 process. You should then use PKCE to ensure that the app returned to did start the request and check the state.

This:

• Follows all security recommendations within the authorization community, as well as RFC8252
• Does not assume anything about the actual authentication provider used, which might include Google Social Login, Authentik, Authelia, Keycloak etc, and because it uses a modern browser prevents rendering conflicts and enables FIDO2 keys (such as Yubikeys) to be used as well.
• Shows the user at all times which path they are entering their credentials into, while webviews hide this, such that they are less likely to be phished.
• Shows users that their credentials are entered using HTTPS (and allows for checking the certificate).

Authentication Providers

Home Assistant should encourage the creation of LDAP and OIDC plugins that add authentication providers that nicely integrate within the current flow, instead of the "brute force proxy" approach which destroys many of the benefits of the OAuth2 and service worker systems within Home Assistant.

home-assistant/core#37645 and home-assistant/core#32926 should either be revived as core parts of Home Assistant, or - and I think most likely - as well-maintained separate plugins that are easy to install through HACS.

Again, embrace external authentication, not extinguish to improve security for all users.

Consequences

I want to get back to the specific reason why the PRs got declined by balloob:

However, there is one big question mark… how do we want to deal with users that are no longer allowed to log in?

Credentials are only validated during login, which results in the creation of a refresh/access token pair. Once granted, all interactions are done with these tokens and no one will check back with the OpenID provider if the user is still valid.

Example how other platforms do this: if you log in to GitHub using Okta, you will need to re-login every 24ish hours (I think). That way they verify that you are still allowed to log in. If I remember correctly, Okta is actually smart enough in that if you are already logged in to it, it's just a few redirects and you're back at GitHub, no need to actually enter user/pass again.

When we added the command_line auth provider, we decided that it would be up to the implementer to disable users (custom integration) given that it was already a pretty manual process to wire it all together. With OpenID it is getting very easy to link external authentication. People will expect that users are blocked from logging in by changing the auth provider configuration or the user in the source system. However, they won't realize that it won't log out users that are already logged in.

You are right and it's very good that you realized this shortfall! OpenID Connect implementations in fact often have two common shortfalls (I will give the solutions later on):

1. Suppose that you add OIDC to an existing Home Assistant install, where all your users have 2FA, users with the same username or email from all providers are considered the same and you add a OIDC authentication provider that does not require 2FA (possibly bad config), you can circumvent the original 2FA! Well, this actually happend to CloudFlare, when they added "Signin with Apple". If you had an insecure Apple account matching the same email of a 2FA secured CloudFlare user, you could just login to their account using Apple, no questions asked.

2. User logout at the IdP (OIDC provider) are not propagated to the consuming app, especially if you are using refresh_tokens or long-lived access tokens. As balloob correctly identifies, the check (often) only happens on the authentication stage!

Solutions:

1st issue

When implementing OIDC/SAML in your app you do the following:

• If a user logs in through OIDC with a new username that you do not have yet, you give them no rights (or make new user rights a configurable field) and create a new account for them.
• If a user logs in through OIDC with a username that is also a local account, you should require them to login with the local account (including 2FA) once to "link their accounts".

Alternatively, you could always prefix usernames with the OIDC provider name (or similar) to prevent username "collisions" entirely and always create a unique account. This however disallows for migrating from local accounts to OIDC accounts, so I would recommend the approach above.

2nd issue

First off, sensitive apps should always use short expiry access tokens, for instance, 1 hour. Native/mobile apps can then use the refresh token to get a new token, and web apps can use the prompt=none silent refresh flow to try and get a token within an iframe.

Additionally, when changing a password or disabling a user, you should revoke all of their JWT's by keeping a list of revoked JTI's (RFC 7519) and checking these on every API request. For distributed apps, this could mean keeping this list in a shared cache, such as Redis, and checking it with all API microservices.

However, we have not solved the issue of users getting disabled at the SSO provider, just for local disabling.

We actually have three solutions here:

• There are specifications for logout with OpenID Connect: https://openid.net/specs/openid-connect-frontchannel-1_0.html and https://openid.net/specs/openid-connect-backchannel-1_0.html. The OpenID Connect Back-Channel logout specification solves this issue perfectly. It adds a sid field within the original id_token that can be saved by the RP (Home Assistant). Then, Home Assistant exposes an API route that allows for the OIDC provider to call it whenever the token should be revoked, including the sid within a signed JWT. After this, the exact same happens as with local disabling, we add the JTI of all issued tokens for that user onto the blacklist. Sadly, many providers do not implement this, as indicated by backchannel_logout_supported within their OpenID well-known discovery document.

• Alternatively, we could show external SSO users on the user list for admins and allow disabling the accounts from there, including revoking all tokens. While this does not disable them automatically from the OIDC provider and should be used in tandem with any of the two other solutions, this does make sure that they cannot login immediately, like with local accounts.

• Finally, we can use the UserInfo endpoint to do a basic check if the authentication is revoked, as detailed below:

Implementing OIDC

If you implement OIDC for authentication, you only get proof of user identity at that moment from the OIDC provider. Therefore, you can use the issued id_token to obtain identity data, such as name, email etc. You can also use the UserInfo Endpoint, which includes the same information.

You will also get an access_token and possibly a refresh_token. These should only be used for the UserInfo Endpoint.

Using the UserInfo Endpoint to check if a user is still valid

We can store these access_tokens and refresh_tokens on the backend (remember that they only have access to the openid, profile and email scopes and can thus do nothing else than UserInfo checks and are thus limited in security scope) to do a new user info request on every token refresh (refresh token / silent flow).

If a user is returned and it matches the saved OIDC user, we allow a new refresh or access token for our app to be issued and revoke the old refresh token or access tokens (as stated in the OAuth2 spec).

If the access token is expired and the refresh token cannot be used to obtain a new UserInfo Endpoint access token from the OIDC Provider, we MUST have the user re-authenticate.

Summary

This mostly solves the issue by:

• Allowing for long-lived sessions for local use, where you can revoke long lived access/refresh tokens within the app (as is currently possible on your User Profile screen within Home Assistant) because we check against the JTI on all API routes
• Allowing for long-lived sessions for OIDC use, for as long as the refresh/access token from the OIDC provider allows access to the UserInfo endpoint.
• Allowing for revocation of access rights at the OIDC Provider for Home Assistant as they will invalidate the saved access token and the next UserInfo endpoint check will fail (after at most the Home Assistant token lifetime, see above).
• Working with most OIDC implementations

However, it requires storing this IdP access/refresh token in the database.

Conclusion

While not all questions are answered with a perfect answer, as many parties do not fully implement all OIDC specs, we should not let perfect be the enemy of good. Yes, we should have warnings for users enabling SSO for Home Assistant, possibly even requiring them to install HACS, a custom OIDC plugin and then enable it within YAML. This will at least keep very novice users from doing something dangerous with badly configured OIDC providers.

However, the benefits of having external providers, with much stronger authentication than Home Assistant can ever implement within the bounds of the app (see above at Proposal), massively out way the downsides. Even SSO without proper logout is safer than users with bad passwords, leaky proxy auth configs and too extensive "trusted network" configs. With the solutions proposed and proper documentation, we can even eliminate most scenarios.

Home Assistant, a platform I trust daily to keep my home automated and controllable, deserves the option for strong SSO to be configured, such that I can rest assured that logging in is not possible without using my physical security key, while still allowing for me to quickly switch to other apps linked to my SSO config.

Definitions

If you already know these, skip this ;)

Authentication = the process of making sure the user on the other end is the user that you have in your system (confirming identity), for instance, through username & password, an external party (such as Google login) and/or through 2FA or other additional authentication methods

Authorization = the process of granting an already identified user, access rights, for instance, internally within Home Assistant to access the APIs. It can also be used the other way around, where Home Assistant requests access to data for Google Assistant, through using Googles Authorization APIs.

OAuth2 = an Authorization specification which makes it possible to give external parties (other apps) access to data from your app (in this case Home Assistant), or is implemented by other parties (such as Google) to give Home Assistant access

OpenID Connect (OIDC) = an Authentication extension to the OAuth2 specification which also gives external parties access to the "authentication"/"identity" part of the login, such that they can use

Why did I include this?

Even the Home Assistant documentation on the access token API's, uses these terms interchangeably and sometimes in the wrong context. For instance, the first sentence "This page will describe the steps required for your application to authorize against and integrate with Home Assistant instances." is correct, but the title "Authentication API" is not. However the page on "Authentication Providers" is correctly named and provides the correct definition "Authentication providers confirm the identity of users.".

In short, and throughout the open-source space, these terms are not easy. Especially since this is not the part of apps that most developers deal with a lot. We cannot blame developers or documentation writers for not being experts in authentication/authorization

Final notes

This discussion post is a port from home-assistant/architecture#832 and https://community.home-assistant.io/t/open-letter-for-improving-home-assistants-authentication-system-oidc-sso to the new Feature Requests system as introduced in https://community.home-assistant.io/t/heads-up-feature-requests-are-moving/903057. At the time of moving, it had 898 upvotes on the forum.

This letter is not a meant as a critique of the current system, just as a suggestion for improvements that might benefit the security and usability of Home Assistant in some scenario’s. I love the Home Assistant developers for their dedication to this great platform and the current apps that we already use daily. ❤️

I wrote this letter to convey my opinions and pointers on the subject of external authentication (SSO) within Home Assistant, for instance using OpenID Connect (OIDC), SAML or LDAP. If you agree that adding external authentication would be beneficial for HA, please leave an upvote and/or reply with your use-cases.

Thank you balloob for starting this project, and thanks for all maintainers and contributors for creating something that I interact with every day. This was just on my mind after trying to integrate Home Assistant with Authentik, after Immich succesfully integrated OpenID Connect as well. I was frustrated with the current tickets and the lost users, most of who do not know enough about the specification to write a full analysis and were just configuring proxy auth in many dangerous ways. Therefore, these are my 2 cents.

I would like to hear from everyone interested in this issue and I hope that we can all make Home Assistant better! I am also open to call about this or answering any comments you might have. Thank you for reading!

[christiaangoossens]

I have unsubscribed from notifications, if you want to reach me, please tag me in your comment. The link to this discussion has been cross-posted on the forum to inform others that the post has moved.

[benedikt-bartscher]

Thanks for porting this @christiaangoossens. And thanks for all your effort on this topic, I really appreciate it!

[ProfessorDey]

As someone who proactively relies on Oauth2 for quite a lot of my home and work services online, I'm very much in support of support for this at even the most basic level.

With more modern solutions like Authentik and Zitadel, it can be so much easier to manage to have a secure service that's still accessible over the net, and I for one am amongst those that immediately hesitated to set up remote home assistant access due to the lack of SSO/OAuth2 support.

OpenID Connect is a fairly straightforward but very capable standard that makes all of this a lot easier. If we need ideas on how exactly to integrate it, I'd suggest talking to the Audiobookshelf devs who added it themselves.

[thibaudmerlin]

Hey @christiaangoossens
Sounds good ! my 2 cents :

• I suggest to use SCIM to provision and manage user lifecycle instead of relying on user creation at first logon, this can be dangerous in many ways (e.g. Entra SSO with multi tenant app reg).
  Thanks for your work though !
  I've many customers that are starting to use HA in their company context and relying on OIDC/SCIM can be a game changer for them and the security in general
  e.g. One of my customer is an University and they use HA to monitor Datacenter Power Consumption and Carbon Footprint. It can be great to have a robust IAM system to grant many people in with different role and SSO

[red-lichtie]

Hi @christiaangoossens: Another way that a "long duration" token could be limited or ignored is also to look at the iat or nbf claims and enforce your own limit in the service.

[Zepmann]

@christiaangoossens

Thank you for putting this up for discussion for more than 2.5 years and counting.

Now to a wider audience:

OpenID Connect is the industry standard for deferring user identification and authentication to a third-party provider. It should be considered a de facto standard the same way username+password-based authentication is. Many efforts have been made over the last couple of years to make the implementation of OIDC in a home situation more viable. There are many choices for providers with different priorities for lean, mean, functionality and configuration options. More and more open source and selfhostable projects embrace OIDC as the way forward.

It surprises me that Home Assistant still does not support this. HA does not exist in a vacuum. I would like it if I do not have to maintain separate credentials for HA if it is not required for other services I host for myself. To be frank, the official list of supported authentication methods is a bit embarrassing. That last word I write with the highest respect for HA. HA is a very mature and popular project, which is why it surprises me so much that the available authentication methods are so limited. Where is (officially supported) header-based authentication? Where is OAuth 2.0/OpenID Connect support?

If security is an issue, give options with which users can secure their installations. Users can make mistakes with the proposed methods, but so can they with the currently supported authentication methods (especially trusted networks and command line). Ultimately, hardening can only happen if there are options to harden.

This is not a dig towards all the wonderful work that is put in HA. I understand if priorities were somewhere else in the past. If not, HA would not be one of the few bright beacons in an otherwise very bleak IoT landscape. However, I do believe that the time has come to focus effort on authentication methods that integrate better to enhance ecosystems. After all, is that not what Home Assistant is known for?

[Zepmann]

If considering other authentication options, I would like to point to graphs related to the usage of different external authentication methods used by Drupal. LDAP is on the decline overall. OIDC is getting more popular for newer/maintained installation.

If there are limited development resources available for additional external authentication methods, my vote would go to OIDC. LDAP can still be used indirectly by or through the OIDC provider, so there is less reason for Home Assistant to support it directly.

[edekeijzer]

While I do understand the reluctance of the HA team to add authentication methods because of the possible security implications, the reality is that a lot of homelab/power users (which I think are the backbone of community support) really want a single/seamless sign-on for their services, resulting in 'hacky' solutions like header auth or commandline auth scripts using wget to call ldap-auth, which might not directly be the responsibility of the HA team but definitely is a security incident waiting to happen.

[rekonnected]

^ This 100%. If enough people want to make an app work in a certain way, they will in spite of any restrictions or decisions otherwise by the maintaining party. Given the increasing prevalence and general acceptance of OIDC and similar authentication systems, official implementation should be fast-tracked, not rejected because of an unspecified "better plan" that hasn't materialized for half a year (home-assistant/frontend#23204 (comment)). Continued silence/rejection from the HA team isn't inspiring confidence. Continuing to leave this to "unsupported" third-party solutions that are necessarily hamstrung due to the design of the system is just inviting incidents, and "we don't support custom integrations" isn't an acceptable excuse for this either. It's the restrictiveness of the system that makes the use of custom integrations necessary.

E: Also, it's extremely worth noting that this specific feature request currently has at least 4-5x the number of votes of any other FR on the repo.

[wagneramichael]

OIDC support would let me use https://github.com/pocket-id/pocket-id for a dead simple sign in with a Passkey and be done with passwords.

[HeyITGuyFixIt]

Pocket ID v2 just released with support for being a SCIM provider. Would love to see SCIM support in HA as well for centralized user management.

[AntoineGlacet]

Hello Christian and others.
Just wanted to thank you for tackling this issue. I came back to home assistant after moving house a few years ago and I also deployed authentik for my home server. I was a bit surprised to realize oidc is not native in hass!
I think modern software should support OIDC and external authN providers as a core functionality nowadays and I am grateful to see an implementation well on the way toward a full release.

I hope home assistant can make it a core functionality of the project in the future and stay the reference software for home automation!

[CoreyJ87]

Yeah I now use passkeys and yubikeys via keycloak. I really would like to this feature be added. So It would be a welcomed addition to home assistant. Also along the lines of being locked out. I feel like thats on the person. I have multiple auth methods attached to my github/aws/gmails/etc for this very reason.

[Norrodar]

OIDC has become the clear industry standard for authentication — not only in enterprise environments but increasingly for home users as well. With projects like Pocket ID, strong and secure authentication is now accessible even to non-technical users.

In this context, it would make sense to also modernize the authorization and permission model. For instance, Home Assistant could introduce zones or user groups — a private/family area with full access, and a guest/local area available without login.

That way, guests could still control basic devices securely and independently.
Imagine the family already in bed while guests finish a board game — they should be able to turn off the lights themselves without needing full access or waking anyone up.

I genuinely believe this would elevate Home Assistant’s usability and security to a new level — and I’d even be happy to donate again to help push this feature forward.

[john-f-chamberlain]

I am also here due to setting up a Pocket ID server; I'd love to be able to integrate HA into my SSO.

[blobberbun]

+1 for someone wanting to integrate HA with my Pocket ID OIDC tenant.

I'm technically-apt, but other family members are not. A dead-simple auth would reduce user friction massively.

I'm also surprised that HA still doesn't offer a robust auth system that's in line with industry standards. In many ways HA has been at the forefront of home automation and network management but not here.

[yeyeoke]

What surprises me most is the lack of meaningful communication from the maintainers. This is by far the most upvoted feature request and all we get from the maintainers is silence. Why?

Is there a new emerging technology that will render OIDC obsolete? I'm not aware of any, and none in their right mind can honestly think that the current authentication system is good enough.

Is it too hard to implement OIDC? I'm not a developer, but I can only speculate that it is not since far far smaller projects implement this daily, and I do believe that Homeasssitant is far more complex to maintain than implementing OIDC.

All these open letters, PRs and all the people who've over the years tried to get this done, only to be ignored by the developers makes me sad for the HomeAssistant community as well as the OpenSource community at large.

[christiaangoossens]

I think the right thing to do right now is to centralize our efforts in developing a HA plugin that allows adding better authentication mechanism. There are several plugins for OIDC right now and tbh I don't really know what to use and will they be abandoned in the future :/

Yeah, I should have put a bit more time into marketing the initial OIDC plugin (christiaangoossens/hass-oidc-auth), because more projects popped up from wonderful maintainers that did not find mine first. That now leads to (at least) two plugins in HACS and the Authentik guide recommending one, but the Authelia guide recommending another. More info can be found in christiaangoossens/hass-oidc-auth#88.

I will make an attempt to standardize everyone, but I don't want to force other maintainers to fold their projects if they don't want to. My version, with lots of community support, will go stable soon with UI configuration. I have always been careful to denote everything as unstable, even if it was, until I can give guarantees, but this might come off as more unstable than the integration is. Hopefully having a 'stable v1.0 release' allows everyone to switch over, because some of the other integrations are less maintained.

So I wonder, would it be better if we have some kind of "official" (in a double quote ofc) plugin that several people with enough knowledge can work on it and provide some kind of guarantee for its future.

I would like to offer you that, but it will never be official. My best attempt was to name it at the top of this feature request.

Everyone is welcome to contribute to https://github.com/christiaangoossens/hass-oidc-auth, including maintainers who want to move all users over from their OIDC HA integration gracefully. I would be honored to work together and I already get a lot of amazing help from the community over at https://github.com/christiaangoossens/hass-oidc-auth/graphs/contributors.

[ModerNews]

To be fair to the HA dev team, it is a big ask to make authentication support common across applications. You're not going to install mTLS compliant certificates on your smart watch, it was a bloody pain to set it up on my iPhone, and even then, that only worked for Safari as opposed to any apps that uses web views

Maybe, but stuff like RBAC is not dependent on any external factors, and for a system that manages various devices across your network - from sensors providing only output, through light switches, to CCTV and security alarms, missing RBAC should be unacceptable in modern landscape. There have been people willing to implement it, there are plugins implementing it, and yet it's missing from core.

It's not all for nothing, You could implement RBAC, SSO support, and then add (or not) stuff like mTLS down the line. AAA is very lacking in HA, and refusing to acknowledge the fact that it's an issue, covering yourself with statements like "Oh, our target is home users, so there's no reason to implement enterprise-grade security tools" is not gonna solve it.

P.S. Especially given the fact that there have been PRs addressing those issues, as stated in the top level comment. So it's not like community only demands from HA maintainers, a lot of people would be happy to work on the missing features.

[edwardgalligan]

@Westie looking at the 3 links you provided to devs commenting on their (lack of) intent to implement this, the first two (GH issues) seem to be specifically talking about not implementing client certs & custom headers in favour of some other auth solution, so this gives me hope (I would prefer OIDC & no other custom/external support - keep things simple).

The community discussion also centres around mTLS. I use mTLS for a everything in work - it's cool & I'd love to see it in HA - but I wouldn't expect it as a basic feature for a consumer-focused app like HA. This seems very separate to OIDC in my mind.

Overall - I'm curious to search myself & read other comments from maintainers elsewhere but these 3 links don't strongly indicate a lack of intent to implement OIDC, rather they seem to show a pragmatic & considered approach to not implementing every possible auth feature.

[Westie]

@edwardgalligan

rather they seem to show a pragmatic & considered approach to not implementing every possible auth feature

It's 2025, soon to be 2026. The fact that OIDC isn't natively supported, or at the very least, proxy auth is frankly disappointing.

[edwardgalligan]

@Westie it's definitely beyond past time for HA to support OIDC (though I will mention I host a few open-source apps on my homeserver & HA is far from the only one lacking OIDC). However there's a big difference between late & never, & it doesn't seem to me like something the maintainers have explicitly ruled out.

[Westie]

@christiaangoossens I have made a plugin that acts as a wrapper for https://github.com/oauth2-proxy/oauth2-proxy

Instead of exposing the Home Assistant port to the open world, I expose the oauth2 proxy instead. I might publish it on github to see if anyone else wants to use it

[christiaangoossens]

That will work, but might break the mobile app. You are also welcome to try https://github.com/christiaangoossens/hass-oidc-auth ofcourse to directly integrate OIDC in a community way. HA is generally secure enough to expose with that integration and I have not had any reports of break-ins due to the integration.

[Westie]

@christiaangoossens Unfortunately that doesn't fit my requirements of having the HA interface essentially firewalled from the outside world unless authentication has been provided

[Gunni]

@Westie you can use mTLS via a reverse proxy in front of HA. The app even supports that.

[Westie]

@Gunni

The app even supports that

Not all of us use Android devices.

[ncolomer]

Instead of exposing the Home Assistant port to the open world, I expose the oauth2 proxy instead

@Westie +1 on this approach. I adopted it myself but finally rollbacked to standard password auth + MFA because of troubles with the iOS companion app.

[Westie]

For mobile, I ended up spinning up an instance of wireguard dedicated to HA, on one of my firewall appliances. It does the job, you just need to manually turn on the VPN if you want HA to work.

[Westie]

I've been tempted to put together a work around for HA and iPhone but it would be very messy and may ultimately need something like traefik in the way, running inside the container.

It's doable, however the thing I'm most concerned about is that you're essentially gatekeeping anything with an Authorization header - which isn't sent for requests to /lovelace

[Gunni]

@ncolomer you can use mTLS via a reverse proxy in front of HA. The app even supports that.

[orionshock]

I'd like to see Home Assistant be the OAuth/SSO Provider instead of using an online 3rd party service.

[ModerNews]

Definitely not. There's no reason for HA (outside of their cloud, maybe) to be an Identity Provider.

Multiple big services provide auth via their SSO (github, discord, google, meta, and many more), and if you don't trust them you can host your own on your infrastructure: Authentik, Keycloak, PocketID, Authelia are the ones that come to my mind, but there's dozen of options.

Having an unrelated project serve as a IdP is just asking for issues, look how big are the afromentioned selfhosted solutions, and now imagine adding that to HA's stack.

[edwardgalligan]

I'm really happy to find this comment with so many downvotes & this reply with so many upvotes.

I love Hass but already think it does far too many things I don't need it to do for me (that there are better independent solutions out there for) - I'd rather a slimmer & more focused HA. Good to see the sentiment shared in the community.

(that said, having an OIDC client natively IS something HA should absolutely do imo)

[themacadmin]

I'm glad to see this getting some discussion.

I believe that not only does Home Assistant need to support the use of common identity providers/standards, but almost more importantly, integrations need to do so as table stakes.

It is becoming common for manufacturers of devices and appliances to adopt identity provider sign in such as "Sign in with Apple" or Google/Microsoft/Facebook/etc to their products/services/accounts.

Therefore any integration with such a product/service/account ought to be able to handle the identity provider login process.

I am currently unable to set up the Toyota integration for just this reason. My only recourse would be to disassociate my vehicle from my current Toyota account, and create a new Toyota account with nonsecure simple name & password auth. As I'm sure any security expert would agree, simple auth is not significantly more secure than no auth at all.

[red-lichtie]

Let's be honest here, dedicated software like Authentik, Authelia and Keycloak are probably more scrutinized as any HASS internal authentication scheme ever will be.

If a user is revoked then their JWT won't help. If the user is deleted at the IdP and you have concerns then the user info endpoint can be used for validation (e.g. test it every n minutes?).

These tools are designed to authenticate users and not being able to use an Apple/Google/Amazon/Github/etc. account is nuts in 2026.

The number of web applications that attempt to implement their own authentication system is insane, it is another place where identities could be leaked or stolen from.

Also WebAuthN (FIDO2) and Passkeys are a thing too, why would I want to secure my HOME with anything but the best possible software security standards.

Unfathomable.

[itsCARLsanity]

What's more surprising to me is that when they moved feature request from the community forums, this was on the Top 5. Upon moving to github, this is the Top 1 with 1k upvotes, while the second place is only at the ~200 mark.

And yet, this still remains unanswered. No communication since 2024, I think. The developer's stance still remains the same. I mean, why bother asking people what features they want if it just doesn't get considered. I mean, I would get it if this was just a relatively new request but I've seen Github issues, discussions, even PRs from contributors opened since 2020-2021 that were just closed because "they weren't feeling it"

I'm not here to throw rocks at the developers, obviously. I love the work that they've done but the way their ignoring this is just disappointing to me

[rodgers86]

Think its crazy that SSO is not part of core yet.

I need to use a passkey to sign in to Jellyfin, immich and paperless on my server, but Home assistant still is not fully compatible with authetik authellia etc

This has to be one of the most requested items over the last few years

[Westie]

The lack of engagement here is pretty non-typical

No, it makes sense given previous attempts at implementing mTLS etc.

mTLS was rejected due to it being not within any proposed roadmap changes, and SSO rejected as it was deemed too "enterprisy" for use in the home.

Lack of comment on this topic is a message itself.

[Norrodar]

mTLS was rejected due to it being not within any proposed roadmap changes, and SSO rejected as it was deemed too "enterprisy" for use in the home.

I can see why OIDC might seem 'enterprisy' at first glance, but from a User Experience perspective, it’s actually a huge win for the average household.

Think about the 'family' dynamic: if you have children who are curious and might accidentally stumble into Admin settings, you need a simple but foolproof way to manage access. OIDC makes this seamless. Instead of teaching everyone a new set of credentials or managing local users one by one, we can use the same secure login (like a Passkey or a simple SSO prompt) that family members already know.

Regarding the roadmap, I believe OIDC shouldn't be seen as a 'niche feature' but as a foundation for better UX:

• Simplicity for the family: One-click login with biometrics instead of typing long passwords on a tablet or phone.
• Peace of mind for the admin: Easily ensuring that kids or guests only see the dashboards they need, without the risk of them breaking the backend configuration.
• Modernizing the experience: Even if it wasn't on the original roadmap, the massive community interest shows it's a missing piece for a polished, consumer-ready smart home.

OIDC isn't about making HA feel like an office; it's about making the smart home feel as intuitive and secure as any other modern app we use every day.

[Gunni]

This discussion is confuses me, I have been using mTLS for years, my entire family is actually... It works fine. To be fair we are all using Android or desktop...

[HeyITGuyFixIt]

@Gunni looks like that was a rejected iOS feature home-assistant/iOS#2144

It was already present in the Android app.

[dougmaitelli]

I agree with comments above saying that the community is willing to implement the feature but many are just not willing to do it with the high likelihood that it will just be shut-down by the maintainers.
I saw other examples before of good ideas / PRs that got shut-down due to "concerns" that didn't even make total sense. Sometimes even mentioning possible "exploits" that were not exclusive to the proposed idea and already possible with current core integrations. And when we pointed out that the core had those same bugs we just got ignored or dismissed.

I don't know why, and maybe I am wrong, I hope I am wrong. Because I love this project and I am grateful to everyone involved in this but I been feeling like there is a growing disconnect from HA maintainers to the community. Part of it seems to be stubbornness, another part a refusal to adapt and accept other opinions other than their own.

I honestly hope this changes, I honestly hope they would eventually reply and prove they are listening and prove I am wrong.

[avbor]

It seems to me that no one even wants to consider authorization in HA.
Here's an example of incorrect behavior of the existing command line authentication that has been unaddressed for years, since 2024 - home-assistant/core#130766
But all sorts of interface bells and whistles are being added very actively.
What kind of SSO are we talking about here?

[genebean]

I’m very interested in this as I’d like to tie Home Assistant into my Pocket ID instance as another OIDC client. Pocket ID utilizes passkeys exclusively so I don’t have to worry about family members using weak passwords and it would simplify things for them by using the same SSO as my other self hosted applications.

[Zepmann]

Recently I read this discussion:
home-assistant/architecture#1287

Here is some more information about this from a HA maintainer:
https://frenck.dev/renaming-home-assistant-add-ons-to-apps/

That is a healthy discussion about changing a label in HA, with many different opinions from community members, collaborators and maintainers. Sure, some might not agree with the change, but at least there is discussion and there is change.

Why can such a discussion not be held about a feature request that has the highest number of votes? Why are maintainers silent about this? Is there a taboo on this subject within those circles? Who or what is fueling that taboo, if it exists?

The radio silence is deafening. Tagging in some maintainers, because I have no idea whether they are actually aware of this discussion. I do this in the hope that they respond and that they can share some insights.

@balloob @frenck
Pardon me if I tagged the wrong maintainers to answer this question. I am unfamiliar with the organization structure and do not know who is who or who is specialized in what. If you know the right maintainer(s), can you please tag them into the discussion as well?

What are the major blockers for improving the authentication system yourselves or to have it done by contributors such as @christiaangoossens? Is it a lack of interest? Fear of the unknown? A gag order? Please share your views.

[langehm]

Just getting into HA and the lack of native support for this topic is highly frustrating.

In current times, OIDC simply means 'Sign in with Google / Apple / GitHub'. This is exactly what non-technical family members use every single day. Ironically, native OIDC would make the HA login experience significantly easier, which perfectly aligns with the 'Home Approval Factor'.

Currently, HA is practically the only major open-source platform that actively refuses to support this standard. The stance that identity providers are only for 'Enterprise IT' is a complete anomaly in the self-hosting space.

Please reconsider this isolated position. It's about providing a modern, secure, and simple login experience for everyone. Embracing this standard is inevitable for a modern platform – providing the opportunity sooner rather than later would be a massive win for the community.

[edekeijzer]

Totally agree, every silly little project has OIDC support these days. Mealie, which is a lot smaller project and by no means 'enterprise' has it and even some Wishlist app I'm running does it.
As long as they make it impossible to allow the whole gmail.com domain to log in to your HA, I'd consider a proper Oauth2/OIDC implementation safer than HA native login..

[rpuls]

I would love to be able to use my yubico passkey for 2FA instead of these rotating authentication codes.

[inadicis]

you mean with an pin-protected yubikey right? right?
(which is still 2FA)

[edekeijzer]

I would love to be able to use my yubico passkey for 2FA instead of these rotating authentication codes.

That would be nice too, but Webauthn is quite a different topic from OIDC and not an SSO solution. (an interesting talk on do's and dont's for implementing Webauthn can be found here)

There are OpenID/Oauth2 providers available (using Authentik myself, but I think you could even use Nextcloud for this) that support Webauthn, which would effectively allow you to use passwordless login when Home Assistant has OIDC support.

you mean with an pin-protected yubikey right? right? (which is still 2FA)

Password + Yubikey OTP could be an option too ;-)

[Gunni]

No you don't 😉

Passkey is not supposed to be replacing 2FA methods but to replace the entire need of having 2FA at all. Going Passwordless by Passkeys also means to get rid of 2FA because it becomes pointless 🙃

I know that A LOT of implementations are doing this very wrong (and do not follow the defined RFC), which is why I mention it here.

This is a policy choice via WebAuthn options (e.g., userVerification, allowed authenticators, discoverable credentials), not a hard property of passkeys vs 2FA.

1. Case A — Password + WebAuthn

   • Factor 1: something you know → password
   • Factor 2: something you have → YubiKey (WebAuthn assertion)

2. Case B — Passwordless with YubiKey (WebAuthn / passkey)

   1. Passwordless + PIN

      • Factor 1: possession + User Verification
      • Factor 2: possession + User Presence

   2. Passwordless + touch-only

      • Factor 1: possession + User Presence

So, it depends on how it is deployed. Websites can’t detect your PIN setting directly, but they can require and observe whether user verification (UV) occurred.

[red-lichtie]

No you don't 😉

Passkey is not supposed to be replacing 2FA methods but to replace the entire need of having 2FA at all. Going passwordless by Passkeys also means to get rid of 2FA because it becomes pointless 🙃

I know that A LOT of implementations are doing this very wrong (and do not follow the defined RFC), which is why I mention it here.

I find this answer to be irrelevant regarding HASS supporting OIDC. This derails the actual subject in hand and really contributes nothing.

If someone decides to use https://pocket-id.org/, https://kanidm.com/, Authelia, Authentik, Github, Keycloak, Okta, Apple, Google or anything else as their "Identity Provider" (IdP), how authentication is carried out by the provider (with or without MFA TOTP, HOTP, WebAuthN, Retinal Scan or Finger print scan, etc.) is not the concern of Home Assistant.

The requested is simple, allow the identity of the users to be carried out by a separate IdP, how that is done is irrelevant.

[rpuls]

you mean with an pin-protected yubikey right? right? (which is still 2FA)

Of course it’s PIN-protected 🙂

No you don't 😉

Right. All I really want to avoid is:

Open my phone.... getting distracted by some notifications... What were I doing??? Oh right... logging in to HA..

Open authenticator → type the code → look at the screen.
…realize the input field isn't auto focused, I just typed the code into nothing.

Now there's 3 seconds left of this code, so I wait…

New code → type it → session expired -_-

Back to login → username/password again →

(This time prepared 💪)
Grab code → type → success 🎉

(some time passes)
…page refreshes → logged out again

Ah. Forgot to check "keep me logged in".

Cool. Let's do this one more time. 😵‍💫😂

[davux]

It's not clear to me, when reading this discussion, which of the 3 following topics it is about, and I think a good first step is to be careful about not mixing them, as they are completely different beasts:

1. Authorization management in HA. This would refer to HA API being an OAuth 2.0 resource server and allowing any arbitrary "HA client app" to obtain from the user a number of permissions to do things in their HA. So permission granularity and this kind of things.
2. HA as an OpenID Connect Identity Provider (IdP). This would refer to HA enabling users to use their instance as a means of authentication in external tools. A "Log in with my HA" button kind of thing (unrelated to home management, only to self-hosted identity).
3. Authorization delegation from HA. This would refer to HA showing a "Login with XXX" set of buttons on its own login page, so users can use their favorite OIDC IdP, self-hosted or not, to log in to HA.

Those are obviously completely distinct and there is no dependency between one and another.

I believe the discussion is point 3, but whichever it is, a confirmation from @christiaangoossens would be useful so we could safely ignore any unrelated comment and focus on that one. At any rate, I think all 3 points deserve their own issue in principle, so the missing 2 should be created, even if some might be closed sooner than others (I'll refrain from giving my personal opinion here and will wait until after each has its own issue).

[dougmaitelli]

It is my understanding that this is about point 3

[davux]

I think so too. However parts of the proposal talks about the mobile app getting a token from HA. That would refer to point 2 with a pinch of point 1.

I think mobile app authentication can stay as it is at first, since delegation happens inside HA login window, so the internal auth logic doesn't impact the app. This is an attempt at splitting the problem into smaller ones.

[PseudoResonance]

I'm not really sure where you're talking about, but my guess is it's about HA's own API? OIDC is great for users, but ultimately HA still does need a way to do its own access control because a lot of things that interact with HA cannot interact with OIDC and just expect a permanent token to communicate back.

It's pretty common among apps to still do their own auth, but allow OIDC or LDAP as a method to manage the actual user accounts.