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 ...