Dev notes on remote "magic" auth and Zot as identity provider

There's the beginnings of a library here: https://gitlab.com/zot/ZDK

Mike says:

In a nutshell, we redirect the browser back to the site given in the zid parameter, which creates a token, then redirects back to the desired site with some crypto applied to that token. The desired site then does some back door communications with your home site to ensure that the session you're attached to is logged in and is the same session as a logged in session on your home site and if so create a visitor login session and send you on your way to where you were gojng on this site originally.

The hard part of libzot is that as we've discussed before - we're pretty tightly coupled to the DB. I've already started a branch to sort some of that out. But the other issue may be even bigger. That is that every link on your site going to a zot-enabled site needs to have a zid attached to it. Not just system urls but also content urls. Else there's no way to pass this identity around.

Eventually we want to do this with browser HTTP headers, but that means you've got to plug into all the browsers. That simply ain't gonna' happen. There are some initiatives for browser identity headrers, but it's unclear if we'll ever be able to use those as the entire subject is dominated by big corporate providers who want to control identity on the internet. I'm pretty sure they'll find ways to lock out independent identity providers because that's how the game is played.

More notes from Mike:

The basic flow is outlined in Zotlabs/Zot/Auth.php at the bottom (after the code).

1. You've got a cookie on site A.
2. You redirect to a URL on site B by going through /magic on your site (A). This sets up a few parameters and then redirects you to site B to a special endpoint.
3. If site B does not have your channel info "on file" it will fetch it through a webfinger-like process before continuing. Site B verifies the parameters provided (at this stage it's a lot like an openid exchange) and then calls site A through a back channel to see if the person requesting auth with the specified token is actually logged in there. If everything checks out and both sites can solve a crypto puzzle, a new cookie is generated on site B and then you are redirected to your original destination. If anything goes wrong in the process you still get directed to the destination, but without the cookie.

Reverse magic auth uses the same flow except you start off on site B with only a "zid" and it sends you back to /magic on site A to start the process described previously.

Andrew says:

I personally stepped through the code several months ago and took some notes that I added to the Readme of this repo I started when I was trying to form a "ZDK" for web app developers to use for Zot authentication. I didn't get very far on that, partially because I was persuaded that creating web apps as plugins was perhaps the best path forward.

Simpler implementation?

There appears to be an implementation of "magic auth" client with zot here: https://github.com/redmatrix/hubzilla/blob/master/util/zotsh/zotsh.py