OIDC authentication

[winston0410]

It would be great if solidtime can support SSO, and a modern implementation for that would be OIDC.

[Onatcer]

We decided to move feature requests into github discussions, to separate feature requests from bugs and allow for better prioritization. If this feature is important to you, you can upvote it to let us know.

[Onatcer]

@GeekCornerGH i think my colleague already started working on SSO Support in an extension, but i'm not sure what the current status and plan is. He is on vacation this week. I'll check with him next week.

[GeekCornerGH]

Understood, feel free to hit me up if I can help!

[GeekCornerGH]

@Onatcer any updates?

[Mattchewone]

Is there a branch or PR? I’m sure like many others id be happy to beta and help with this also as its popular and I’d be looking to use this also

[Eiernase]

@GeekCornerGH is he back from vacation yet?

[markus-ruderman]

It would be great if solidtime can support SSO, and a modern implementation for that would be OIDC.

I agree with that point. Many persons in the selfhost/homelab community already use ID Providers like Keycloak, Authelia and Authentik for SSO, and want therefore to integrate additional applications with OIDC. I personally use Authentik and they have a dedicated documentation section how to integrate different applications: https://docs.goauthentik.io/integrations/services/.

I think it is a must-have feature for Enterprise Environments.

[enieuwy]

Another Authentik user here, and OIDC is essential!

[enieuwy]

Can solidtime accept forward authorisation (via headers from Authentik)? If so, how should the headers be specified?

[ibramir]

I'd love to have this feature as well.
I'm willing to contribute in the project and I know others are too. Maybe it's time to open the project for contributions?

[edrzns]

As somebody who started to use Pocket ID everywhere and basically rely on passkeys in my selfhosted apps, would be nice to see OIDC implemented

[Eiernase]

Any updates on this?

[GeekCornerGH]

Right here

[Chanceium]

@GeekCornerGH Where is the branch for this?

[lmm-git]

We would also be interested in accessing the API via OIDC access tokens (see RFC).

This in combination with OIDC SSO would allow us to integrate solidtime in desktops like Gnome.

[Laecherlich]

Bit of a status question before anything else: @Onatcer, back in August you mentioned a colleague had started on SSO support in an extension, and #1131 looks like the groundwork for pluggable auth. Is that still the direction? Asking because we implemented Google SSO in a fork a while back and I'd rather find out now if it conflicts with your plans than after rebasing it.

What we have, for reference:

• Google-only, not generic OIDC — Socialite provider, sign-in button on the login and register pages
• Optional domain allowlist (GOOGLE_SSO_ALLOWED_DOMAINS) so a self-hoster can restrict sign-in to their own workspace
• Auto-provisioning behind a flag, plus a google_id column on users so an existing email-password account links up on first Google login
• Off by default via GOOGLE_SSO_ENABLED, so nothing changes for existing installs

It touches FortifyServiceProvider, UserService and Login.vue, which is the same surface #1131 is reworking, so as-is it would conflict. If you'd rather have this built on top of the extendable-auth core once that lands, that works for us too and we're happy to wait and adapt. And if SSO is meant to be a paid extension, say so and we'll keep ours in the fork, no hard feelings.

Either way, if there's anything useful in what we've got, it's yours.

[wolflu05]

These are some great news.
Have you considered e.g. limiting the amount of users for SSO? E.g. allowing only 5 users to authenticate via an SSO provider would allow individuals to still use SSO, but require bigger companies to pay for it?

[Onatcer]

I think that is something we could explore in the future. It is not really something that we have discussed internally, but here are my thoughts on it:

I'm personally not a fan of putting arbitrary usage limits in our open source version because

1. i think the open source version should be a complete software on its own, and putting limits in it would go against that open source principle, and
2. it would be trivially easy to patch out, fork and potentially even sell.

It might work for some open source software f.e. I've seen open source macOS apps where they offer a restricted built version for free with limits and sell the ones without limits. imo thats a reasonable monetization path for open source standalone desktop apps, but it also primarily works because desktop distribution (especially macos) is such a pita.

There might be some reasonable path to split the SSO featureset alongside the security/organization requirement line, but I have not seen anyone actually split it that way, so I'm not confident doing that, especially because I don't ever wanna be in the position where we would have to pull out something like SSO out of the open source version for business reasons, i think that would be way worse than it not being there in the first place.

However, I did look a lot at what others are doing, and I know some open source projects (Rocket.Chat, Mattermost...) offer free plans with premium features and usage limits for small teams and evaluation. I think something like this could potentially work for us too, but i don't wanna make any promises. We'd have to set up and maintain another distribution channel for this, and also figure out licensing and enforcement. So I don't really see anything like it happening until we are financially in a stable position and also have implemented some of the frequently requested features we are still missing.

[Trickfilm400]

IMHO, maybe a compromise could be to enable the authentication part in the community-version and add a authorization part into the business version. I am the only user of my solidtime instance, so usage limits are debateable here. Therefore I think adding the feature to assign users to specific projects depending on a group membership of the SSO provider would benefit all business and everybody else would have to assign permissions to users manually like today. I always have the https://sso.tax/ https://ssotax.org/ website in mind if SSO is behind a license.
Another idea could be to have SSO for free in the self-hosted version but only in the paid cloud version?

[Onatcer]

This is pretty much the "security/organization requirement line" I described in my previous comment. SSO will likely only be released for On-Premise at first because the cloud multi-org structure has quite a few different requirements.

It's obviously reasonable to want SSO to be free, but I also think it is disingenuous to compare SaaS offerings that charge multiples of their regular (already paid) plans just to have SSO included simply because they can, with open source projects that provide everything free, but offer SSO support at reasonable costs, to fund the development. The original site https://sso.tax/ does, imo, a much better job explaining the actual problem (and also does not include free plans/offerings as a base).

The site you linked is a marketing page for a proprietary YC startup. I'm biased here, but I think it is a little scammy that they push open source projects to the top like that (by setting the base price to $0,01) to blame them prominently while promoting their own paid SSO product. For whatever reason they also do it only to open source projects and not to proprietary services with free plans. There are much worse offenders than Passbolt with a 49€/month plan that includes 10 users, which is almost at the top of their list.

[lewispurver-lgtm]

We are self hosted pay for it and have moved from harvest. I think people will subscribe anyway, if it is a good product and is developing it.

SSO with 365 integration would be great for us and would welcome the feature.