Comment on Single Sign in for Home Assistant now possible with OpenID
Flipper@feddit.org 2 days agoBy default, the Credentials provider does not persist data in the database. However, you can still create and save any data in your database, you just have to provide the necessary logic, eg. to encrypt passwords, add rate-limiting, add password reset functionality, etc.
That is exactly the complexity I wouldn’t want. With just SSO it is enough to send a redirect URL to the browser and on the callback set a cookie. No js needed. If your service gets compromised and someone leeks the credentials, just log everyone out.
irotsoma@piefed.blahaj.zone 2 days ago
Problem is requiring a browser if it’s not primarily a web interface. Even if initial setup is web-based, a lot of times background processes exist that don’t traverse the internet, especially in higher security situations, so exposing those components to the internet just to get external credentials is not worth it, so then an additional proxying component is required. Anyway, the idea is that it can add a significant amount of complexity if it’s something more complex than a simple, single component web application.
femtek@lemmy.blahaj.zone 22 hours ago
You can self host the authentication outside of the Internet.
irotsoma@piefed.blahaj.zone 17 hours ago
Problem is that the user has to be presented that webpage anf the results have to make their way back to teach component. If you have a bunch of microservices that aren’t user facing (whether internet or private network) then how do those services get the user data to do their things. Monolithic server applications are bad practice outside of extremely simple web apps if you want something scalable. So you still need a database of local users that the services can share privately. That means a built-in user database that is just linked to the SSO user by the service that is user facing. Otherwise, all micro-services have to authenticate separately with the user once every time the token expires. Which means lots of browser sessions somehow getting from a micro-service with no web front end to the user.
Anyway, just an example, but when a local user database is required anyway, then SSO is always addition development work and exerts possibly significant limitations on the application architecture. This is why it’s not commonly implemented at first. There needs to be better protocols that are open source and well tested. OIDC is my current favorite in many cases, but it has limitations like logging out or switching between users on the same browser is a pain. Most proprietary apps use proprietary solutions because of the limitations and they feel (often incorrectly) like it’s obfuscated enough to not be susceptible to attacks despite the simplicity. Doing SSO right is hard, so having to implement something from scratch isn’t feasible and when done is usually vulnerable.