Mirroring the conversation on GiHub:
(at)Jermolene Thanks, and I was really impressed with your work on TiddlyWiki-on-Fission, there was just a few things in the user experience of the Fission suite of code (WNFS) at that time that prevented me from adopting TW-on-Fission as my Go To knowledge management app.
I would like to focus on Auth in this thread. I think that there are a lot of recent technology changes, especially around Basic Authentication being widely deprecated that may point us to a way forward. I found this a really useful take on the perils of managing a set of user credentials: Explaining Modern Authentication Like I'm Five | Making Loops
OpenID Connect is the one of the latest evolutions, so it’s most likely what you should use.
He never got to those later articles on each protocol. But we can find references…
OpenID Connect: This is a popular authentication protocol that uses OAuth 2.0 and JWTs to provide authentication and authorization for microservices. OpenID Connect provides a standardized authentication approach widely used in modern microservices architectures.
Token-based Authentication: Uses JSON Web Tokens (JWTs) to authenticate users and grant access to microservices. JWTs are self-contained tokens that contain user information and an expiration time, and can be used to verify a user’s identity without the need for additional database queries.
The user must use your ID provider’s MFA apps, etc. Handy, if they already have a Google Account + GoogeAuth app, or MS Account + MSAuthenticator app, etc. Not great if they prefer one service, and you don’t offer that option. You, admin, also need to do special things to allow your APP to pass authentication requests to the ID provider (usually establishing an app client_id and client_secret key).
At the same time, I am keenly aware of the “lock-in” of relying on 3rd Party OAuth2.0/OpenID Connect providers. Even if you (a dev) have a clean local copy of all your wikis data in clear text, any technical problem between the wiki server and the OAuth server may block the admin/user somehow. If/when the server is deployed and no longer local, that can become more of a blocker.
This makes me lean towards the Fission model for login authentication and resource authorization (ignoring the WNFS/serverless side of things for a moment). I’m going to start researching this more with that in mind.