Quoth Demetrius Iatrakis : > This is a preview of OAuth2 support in factotum, as part of this year's GSoC: > https://github.com/Mitsos101/plan9front/pull/1 > > Installation, on 9front: > > git/clone https://github.com/Mitsos101/plan9front plan9front-oauth > cd plan9front-oauth > git/branch oauth > bind sys/include /sys/include > @{cd sys/src/libauth && mk install} > @{cd sys/src/cmd/auth && mk install} > @{cd sys/src/cmd/webfs && mk install} > > This will replace your factotum. > > Usage: > > You need to obtain OAuth credentials from your issuer first. See, for > example, Google's guide: > https://developers.google.com/identity/protocols/oauth2. > > % echo 'key proto=oauth issuer=https://accounts.google.com scope=email > client_id=1234 !client_secret=5678' > /mnt/factotum/ctl > % auth/oauth 'client_id=1234' > go to https://google.com/device > your code is ABCD-EFGH > > > auth_oauth is also available in libauth. Webfs uses it to implement > the preoauth command. > > Bugs: > > This code is specific to 9front, as libjson is required and Plan 9's > webfs doesn't support preoauth. > > factotum uses the needkey RPC to display the verification URL and code > to the user. This means that, for now, the needkey file must not be > open so that fgui doesn't intercept it. > > The module imports lots of code to support HTTP/1.0 so that the > refresh token doesn't leave factotum's address space. > > Only the device and refresh flows are supported. There is an > implementation of the authorization code flow (tested on macOS) here: > https://github.com/Mitsos101/plan9port/pull/1. However, it is not > included in the module as there is no good browser to plumb the URL > to. > > Refresh tokens are not saved to persistent storage when factotum > exits. The user must provide consent every time factotum is restarted. > And, now that we have something working, I wrote some code to use it. I wrote a patch to add oauth support to upas/fs -- see attached: To use the patch, I followed this kind of clunky process: https://developers.google.com/identity/protocols/oauth2 I went to the 'credentials' section on the sidebar and I created a key for a 'desktop application'; Then I went to the 'oauth consent screen' and added my work email account as a 'test user'. I grabbed the keys, and on my unix box, went to the patched oauth: % cd $HOME/src/plan9port/src/cmd/oauth and generated a key using the full, browser based auth flow: % python httpd.py % ./oauth https://accounts.google.com https://mail.google.com/ $clientkey $clientsecret key proto=oauth issuer=https://accounts.google.com client_id=72... then edited the resulting output to include the appropriate attributes, adding the attributes in >>...<< for upas/fs: key proto=oauth >>service=imap server=imap.gmail.com user=ori@pingthings.io<< issuer=https://accounts.google.com client_id= token_type=Bearer exptime=1629662303 scope=... and then added that to factotum: echo key=... >/mnt/factotum/ctl With that, upas/fs just worked with my work email: upas/fs -f /imaps/imap.gmail.com/ori@pingthings.io Bugs: there are way too many steps. Unfortunately, the most annoying one is generating and adding an oauth client key/secret, and short of shipping a pregenerated one (is that a good idea?), I don't think there's a solution. Beyond that, 2 small bits of polish which I think we can do: - Adding a '-t' flag to oauth (the way auth/rsa does) to add type information to auth/oauth login would make it more convenient to use: the output could be stored directly rather than needing editing. - Adding a script that allows spawning a browser and http listener on unix (or redirecting thigns through to plan 9) would make it easier to drive the auth process from plan 9. Thanks for doing this work, Demetrius!