Open to PR for Joplin Server SSO support?

glmdev · 2021-12-08T19:58:25.504Z

(I posted this to Features, but I think it might've gotten buried.)

I guess this is kind of a feature question as well, I suppose. I want to self-host Joplin Server for my own use, but I use single sign-on for all my self-hosted apps.

Would maintainers be open to a PR adding OpenID Connect support to Joplin Server? The idea would be to have a "Or log in with single sign-on" link on the login page, then an "App Passwords" section of the user form/profile page. SSO users would then use the app passwords for authentication in the Joplin clients.

Just tinkering, I've got OIDC login working, but don't want to code up the app password hashing/storage/UI/&c. unless there's interest in a PR.

(As an aside, this came about bc I couldn't find an acceptable way to sync Joplin notes with the sync targets when using SSO. I use Seafile, which doesn't support SSO for WebDAV; there's no Android client that actively syncs filesystem to Seafile with SSO credentials, so I can't use filesystem sync; and Joplin Server doesn't yet support SSO.)

glmdev · 2021-12-12T17:11:42.445Z

Bump? I'm willing to write this feature, just wanted to get feedback before sinking the time.

laurent · 2021-12-12T17:26:22.755Z

Hmm, I'm not sure. I guess that's a lot of work on client and server side? And I'm not sure we have the resources to review and maintain this code.

glmdev · 2021-12-12T17:34:55.299Z

I'm using openid-client, so the actual SSO implementation is fairly minimal. The main part would be the app password handling, which I think would just need to link into the initial token endpoint for the API.

Really the only client-side change is in the profile page in the server portal, where users will be able to add/delete app passwords.

laurent · 2021-12-12T19:26:39.610Z

How widespread OpenID actually is? I remember creating an account a decade ago, but I've never used it much (in StackExchange only I think). Because any fearure we add is something that needs to be maintained forever afterwards, so if it's only for one or two users it doesn't make much sense.

It would also need to be optional since supporting this for example in Joplin Cloud would not be easy (since account creation is via Stripe).

Finally remember that it needs to work in mobile too. Many npm packages assume a Node environment which is not present in React Native.

lknite · 2022-10-01T21:05:17.360Z

oidc is incredibly prevalent out in the world at this time in history, as i look into joplin to see if i might onboard it into my environment, as with all web apps i first check if it is oidc compatible ... and have ended up here, this post is 6 months old so i'm hoping it has already been integrated

Everything web-related is pretty much expected to have oidc support. Allow me to give a use case. In a modern kubernetes setup, kubernetes being a container management system, along with a gitops setup (using either argocd or flux), you confgure the appliction deployment using a yaml file. In that yaml file you specify the container image to use, in this case joplin-server, and some configuration such as the oidc configuration to use in my case keycloak (the upstream redhat sso solution), or azure, or any identity provider really as they all support oidc ... then, after the app comes up instead of logging in with a username and password there will be a button to do the oidc login, it redirects to keycloak for credentials as it can see no one is logged in, you log in via the identity provider, it redirects back to the app and you are logged in. The login comes along with "claims", such as "username" and a list of "groups" the user is a member of. The app uses these to know the username, and can use the groups for permissions, such as an admin group, to grant admin privileges.

If an app doesn't support oidc you can use something like oauth2-proxy to wrap the website in a way to gather credentials. You don't want to do local accounts though, when you have active directory with a few users you don't want to manage the credentials in every app. In my environment for example I have 16 apps that all use oidc so if a user changes their password its changed in all apps, also once you are logged in all the websites just work for awhile ... till the configured timeout then the user has to log in.

I invite you to look into oidc, for my team its a prerequisite for any app to be used at work, at home of course its different and sometimes you have to make an exception if something is great but lacks the oidc support. The protocol is pretty basic really, so simple that as you look into it you might want to implement it by hand, but its always better to just use a library so you don't have to maintain anything. Nextcloud has an oidc config but its overly complex, so I ended up just configuring that one with ldap, but that's the old way to do things. These days, always oidc ... google 'harbor' and 'oidc' to see their gui config, it's a really great gui config example, but anyone using oidc would just expect to use a config file with a few values.

Another project I like heimdall doesn't have oidc, and yet I love it. I browse to it and use it, I can protect it w/ oauth2-proxy, but that only password protects it, I want other people to be able to use it also... turns out they use a php library for their account system which is laravel, laravel has a plugin system, and people have made plugins. As long as you haven't reinvented the wheel, whatever accounting library you are using might already have a plugin. If you haven't already implemented this, maybe let this guy do it ...

lknite · 2022-10-01T21:09:39.704Z

stripe /docs/connect/oauth-reference ?

maybe we already get this via stripe & just need a help file

lknite · 2022-10-01T21:55:37.983Z

dang, i some how accidentally deleted my post, i hope you got a copy in an email laurent, if so please repost here ... let's revisit this topic

I'll try to recreate a bit of my email here. OIDC is super prevalent at this time in history. Whenever I go to deploy a new app into my environment I look for how to configure OIDC.

Right off the bat, the app gets deployed via a container and OIDC is configured, along with generally a group which represents admin access. Then, upon first viewing the website I can log in and get admin access, other users login and just get the user experience. The user accounts in my home lab are in active directory and I use keycloak as my identity server while at work they are in azure and azure identity server is used.

By using OIDC you get the SSO experience, so upon opening up a laptop and logging into an app access is also granted to all other apps till the token expires at which point whatever webapp you are using it'll catch the expiration and redirect you over to the IDP to log in again. Logging into OIDC gives you claims so your app will get the username to use and typically also groups which can be used for RBAC (role based access control, aka an active directory group which grants admin access to the app, while non-members just get user access.

At home and especially at work of course, you wouldn't want everyone to get admin access to a webapp by default. ... and you don't want to manage users in the app, the username/password maintenance occurs elsewhere, freeing the app from having to deal with that.

By letting an IDP take care of your users management you also get other benefits, such as if you forgot your password the IDP takes care of emailing the users and getting the password reset. With keycloak, the users can be anything behind the scene such as active directory or github... or with OIDC you can just configure github as your IDP directly and not use keycloak.

At work we tend to see apps which support OIDC as mature, as all apps that have been around support OIDC. It's modern standard replacing SAML due to its simplicity. SAML still supports more use cases than OIDC, but the world has settled on OIDC, libraries will be available for whatever language you use.

Maybe setup an app such as harbor and configure OIDC within it to point to github or whatever IDP you have available so you can have the experience. I suspect you'll want to configure all your apps with OIDC once you have ...

Let me know if you've already got this setup before I type too much please, I've helped a few project get OIDC setup but in general, if you are already using a library to handle you user accounts it may already have plugins supporting OIDC.

ctr · 2023-04-27T16:24:23.775Z

I'd love to see enterprise federation capabilities. OIDC/OAuth2 is definitely the best choice here, but I would mind SAML either.

PaoloC68 · 2023-05-19T01:02:37.941Z

I think that currently any modern application should offer SSO out of the box, it is really important to allow users not to have to create Yet Another Password!
I was honestly expecting that OIDC was already available in Joplin. I want to answer to laurent to the question he made:

How widespread OpenID actually is?

Well, you should know that you are using OIDC hundreds of times a day under a "stolen" name, Google has rebranded it as "Google Auth" and anytime you switch from Gmail to Youtube for example you are using it. Of course the general public thinks that "Google Auth" is a gift from Google but in reality they have stolen it. The prove is the fact is that most people think that is a "niche" technology when in the reality is becoming the most common authentication-authorisation technology on the web. The implementation is in reality quite simple because there are libraries for almost any imaginable programming language and environment. For who wants to have its own "OIDC and SSO" server and familiarize with the technology i recommend Authentik .

isdnfan · 2023-06-07T19:39:41.369Z

I definitely support any kind of SSO authentication..

my setup would work with OpenIdConnect (preferred), SAML of even "forward auth" using X-Forwarded-User http header.. I would really appreciate SSO integrated with Joplin Server

@laurent - I will be happy to share my knowledge and testing efforts for forward-auth or OpenID Connect integration if required (I run Keycloak IdP)

jlecount · 2024-02-03T21:45:34.918Z

Is anybody still considering this? I was hoping to use authelia to do auth, integrated with nginx and not have yet another login behind it.

Anyway since there has been no discussion on this for more than half a year, wondering if those others who wanted the feature have in some other way scratched their itch.

Jason

florider · 2024-10-28T14:04:54.211Z

I'd definitely love to see OpenIDConnect or Forward-Auth support! It would make tying in Joplin to the rest of my services so much easier.