work.txt

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
<after user consent is provided, the access token is printed>

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.

The device, refresh and authorization code flows are supported.
However, the authorization code flow is not enabled by default as
it requires a plan9port plumber to be imported in factotum's namespace
(add flow=auth to your key to enable it). There is an implementation
of the authorization code flow for plan9port (tested on macOS) here:
https://github.com/Mitsos101/plan9port/pull/1. Start src/cmd/oauth/httpd.py
on your p9p machine before running either implementation of the
authorization code flow.

Refresh tokens are not saved to persistent storage when factotum
exits. The user must provide consent every time factotum is restarted.