MWS: Auth^2 (Authentication/Authorization)

[joshuafontany]

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

[joshuafontany]

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 Itentity + 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 flexible ways if we can rely on self-signed "I have XYZ access" documents to go along with Identity.

And these data structures can be kept as tiddlers without as much worry about that data "leaking" - due to the "self-signed self-destructs-if-you-edit-it" design.

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:

https://www.troyhunt.com/how-spoutibles-leaky-api-spurted-out-a-deluge-of-personal-data/

[CrossEye]

I'm glad there's someone here with more experience. I've done various Auth work in Node, but I am (very) far from being an expert.

This was the first I've seen of fission.codes; I'm very excited to see work moving in this direction. But I've got a lot of reading ahead of me!

And these data structures can be kept as tiddlers without as much worry about that data "leaking" - due to the "self-signed self-destructs-if-you-edit-it" design.

Does that depend on their being no man-in-the-middle vulnerabilities? If I get hold of your self-signed tiddler, can I used it to gain access to the same wiki? Or is there device-level information embedded? (And if the latter, what does this mean for ad-blocker technologies trying to shield sites from access to such information? Or am I just confused?)

[joshuafontany]

Yes, on the Distrubuted Identity Document side, they are generated using decive-specific keys (non exportable).

[Jermolene]

Thanks @joshuafontany @CrossEye

I did some work on integrating with fission.codes a few years ago. We got a basic server working nicely, but never got as far as anything more sophisticated like syncing individual tiddlers.

While I admire the technology, I worry that it is conceptually quite tricky for end users who have spent 20 years managing passwords in the ordinary way.

I would like to think that we could provide non-technical users with a viable alternative to Facebook groups for secure communication between a small group of users. Being able to hook into existing authentication providers seems very helpful here.

[joshuafontany]

@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: https://makingloops.com/explaining-modern-authentication-like-im-five/

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.

[pmario]

I think, we should make a clear differentiation between Authentication and Authorisation. IMO this are 2 completely different things and should be covered in separated threads.

[Jermolene]

Hi @pmario I appreciate the concern, but this thread is for people who are comfortable with the distinction, and I do think it is necessary to discuss these two topics together because they are intimately linked.

[joshuafontany]

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

https://salt.security/blog/traveling-with-oauth-account-takeover-on-booking-com

https://salt.security/blog/a-new-oauth-vulnerability-that-may-impact-hundreds-of-online-services

https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts

[Jermolene]

Yes this worries me because TW will require admins to set up exactly the bits of the OAuth flow that are error prone...

OAuth still seems the best way for TW to offer a viable alternative to Facebook groups for small, loose communities of non-technical users.

[joshuafontany]

Still researching this. I think the best approach I have seen so far is from the Subconscious crew:
https://subconscious.substack.com/p/cheating-zookos-triangle
https://github.com/cwebber/rebooting-the-web-of-trust-spring2018/blob/petnames/draft-documents/petnames.md

Going to read through those, and see if I can come up with a model that retain tiddlywiki's decentralized own-your-own-data focus.

[Jermolene]

Thanks @joshuafontany – Zooko was an early proponent of TiddlyWiki, and we worked together to get TiddlyWiki working on Tahoe, the Least Authority Filing System that was a precursor to some of the distributed systems we use today. My observation about that work was that the critical characteristic of TiddlyWiki for that application was that it was self-contained, meaning that the decryption scheme only needed to work on a single blob, and didn't need to support addressable subresources.

Perhaps the mapping of "petnames" to a TiddlyWiki way of thinking would be to standardise on a tiddler that represents a user, with fields for the human readable name, any underlying cryptogobbledegook that is needed to authenticate the user.