Multi Wiki Server: Authentication and Authorization

, ,
#1

A discussion thread to dig into the topics of Authentication (“who you are”) and Authorization (“what you can do”) in context of the new Multi Wiki Server efforts.

In the parent GitHub thread, @jeremyruston suggested that I terested stakeholders grab some of the technical topics related to the new Multi Wiki Server efforts.

This thread will focus on Auth^2, and I and copying it here and as a seoerate GitHub thread. I know that many suoer-users here do not lurk in the github shadows, and I wanted a good community discussion around these concepts that didn’t have to focus on specific code.

My next post will be the same initial post as my GitHub thread:

1 Like
Change the template of new tiddler (managing access for other users of intranet TW)
#2

I will start by saying I am fairly well versed in the tech powering most Web2 Auth (day job), and also learning new “Web3” models of Auth^2 - primarily the decentralized and local-first approach taken by the Fission.codes crew.

Something @Jermolene wrote in the parent-thread made me think of my struggles building web2 style Auth into a websocket-server-plugin architecture based on Jed’s “Bob Server”:

As I understand it, best practices seem to be trending away from passwords altogether. This option – which I’m guessing a large number of users would want – is probably the most difficult to set up.

Yes indeed. I remember in the old days that it wasn’t that hard. One hashed the password into a text file (with a salt), and then matched the hashes to authenticate. I liked the way that the hashed passwords didn’t need to be kept secret, and I’d rather like that in MWS: every users password should be visible as a tiddler containing a hash of the password. I won’t put up much resistance if others want to argue me out of that position, but I do think it would be elegant.

Of course, TW is a robust data store, why not just hold everything as tiddlers? It is following the TW philosophy. I took that approach. It was stable enough… that I then got lost in conflict resolution on synchronous changes, and also the realization that the “tiddler revision count” resets upon Server restart (making any disconnected client still in memory instantly have syncing bugs).

At this time I would argue following the Fission.codes “Distributed Identity + UCAN” id+capabilities model. (Or similar.)

This could be as simple as putting an Auth flow into the rendered HTML page “before the wiki boots”. This would check if the current user+browser(device) or “agent” is already authed AND AS WHO without checking the internet. If anon, it could redirect to the Fission Auth lobby to bind an email address you own to a username and this device. After that one internet flow, Authentication is always a local check against a DID’s self-reporting hash (did this identity document get changed or is it genuine?).

Similarly, now we can manage permissions for our “group” in more flixible ways if we can rely on self-signed “I have XYZ access” documents to go along with Identity.

Finally, I saw this blog post from an MS Engineer doing an autopsy on the WORST AUTH DESIGN EVER TO MAKE IT TO PRODUCTION, and it frankly gave me the void-shivers as to how much Account/Auth data you could get for other users by changing one query parameter:

2 Likes
#3

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.

#4

Here are some resources that clearly explain the current OIDC model, and also how misconfiguring your Auth opens vulnerabilities. Good pictures too!