Oauth support for web ui login?

They have said there are plans to make a self-hosted variant of TrueNAS Connect, but I guess we’ll see.

You can still use your own domain and cert without using Connect, can you not?

What do you use for oauth with the applications or appliances you have now?

Even that is a completely unnecessary layer of complication for what ought to be straightforward to integrate into the web UI. It’s at least as bad as their response of “just use TrueCommand” in response to my feature request to actually used the config backups that are stored on your pool daily–these things should be part of the product itself, not part of some additional product.

I’ve been doing it for several years, so I’d have to say yes. The built-in UX for getting a cert from Let’s Encrypt is inexcusably Byzantine, but it still works reasonably well (even if it has an idiotic default to wait until 10 days before expiration to try to renew the cert). And some brilliant (and totally humble) member of the community has written a tool[1] to automate deploying a cert to TrueNAS if your DNS is with a different provider.

I use Authentik, FWIW.


  1. GitHub - danb35/deploy-freenas: Python script to automate deploying TLS certificates to TrueNAS servers; as an alternative see GitHub - jrushford/tnascert-deploy: TrueNAS certificate deployment tool ↩︎

2 Likes

If Connect will be self hostable then it will be more assuring, can you please show the source where they said that?

Yes, but without OIDC.

There are plenty of them, authentik, authelia, pocketID, keycloak etc.

1 Like

https://www.reddit.com/r/truenas/comments/1o366gc/comment/niubiab/

It’s going to appear as a service just like SMB/NFS and will be enabled the same way. You pick datasets to expose and then there will appear a web interface where you can login and interface with that data. Means you can use it as an administrator, as well as give access to your non-trusted users.

Separation of concerns, we will avoid having users being able to access the administrative middleware functions and API, just like you wouldn’t necessarily want your SMB/NFS users having admin UI access.

I agree, the use case for me is using EntraID (azure active directory) via OIDC - its simple and just works, this definitely feels like a promise rescinded - we now have to use a service provided by ixsystems - are they going to get that certified to the same level as Entra - doubt it….

To be honest for me this is the signal to migrate from TrueNAS ASAP. This is a trivial feature that is a must have in 2026. Almost all our services support SSO, either OIDC or at least something like SAML. Vendor-locking Restic wrapper should have been the first sign :frowning:

1 Like

I actually think right now they still believe themselves and aren’t intentionally forcing their SaaS offering on self-hosters, but that is a very slippery slope. It only takes a bit of internal management or strategy change to push a situation like this over the edge into outright hostility towards open-source/self-hosting focused users, and yes into forcing their SaaS product and telling you to like it or go elsewhere.

I think it’s more likely that they have tunnel vision because they’re working on TrueNAS Connect a lot, and maybe didn’t want to implement it both there and also implement custom OIDC support in TrueNAS standalone. Their priorities are different and so they land on different solutions than self-hosters find ideal.

It’s a very uncomfortable spot for users to be in because we recognize this rightfully as a step on a well-traveled “open-source+SaaS” slippery slope to enshittification, but it’s also not yet certain and so iX employees probably rightfully feel defensive when we complain about it.