investigate PKCE use with oauth2 library

[cjslep]

I don't know if the oauth2 server library is using PKCE under the hood, per the Oauth 2.1 recommendations.

[cjslep]

Looks like github.com/go-oauth2/oauth2 does not support PKCE, see this outstanding issue: go-oauth2/oauth2#161

As such I've begun a fork to include support: https://github.com/go-fed/oauth2

Based on the OAuth 2.1 & Dynamic Scopes presentation by Aaron Parecki in ActivityPub Conf 2020 (OAuth 2.1), it would be nice to just shed the no-longer-recommended flows (ex: password grant, implicit grant), but while that is tempting, I'll stick to PKCE and any other missing features needed by apcore (if any). Hopefully it can then be merged upstream and I can drop the fork.

Since it seems first-party support (aka "browser is the client") in OAuth2 is "do auth grant flow + PKCE like a third party", but still without the benefit of the "peer" non-browser server-side storage for the associated refresh and access tokens, it looks like a modern first-party browser approach could be:

• Store a cookie in the browser
• Associate the cookie with a "proxy peer server" in our own framework, asking for all scopes (TBD on how dynamic scopes will work)
• Have our "proxy peer server" map the cookie to the associated data to go through the OAuth2 flow as if it were a third party
• Success

Therefore, the end-state is that any app using apcore will "feel" like a first-party password flow plus "naturally" support other OAuth2 third party scopes, but the underlying framework infrastructure will mostly be shared (minus this "proxy" layer).

There is really only one chance to set a good example with the example app, so what's another few months improving the oauth2 server. Line up the yaks.

[cjslep]

There was a pending PR with PKCE support so I merged it into the fork.

The proxy work remains though, which will require a new table plus models and services integration.

[cjslep]

I broke out the proxy work into #50.