Don't Merge! Proof of Concept: Using the Boost Site as an OAuth Provider

[williln]

Ticket: #887. CCC @frankwiles @sdarwin

Do not merge -- that would add a "log in with Boost!" button that would be confusing.

Task: Demonstrate how to use Boost as an OAuth provider by creating an OAuth app in the staging site, then adding Boost Staging as a social provider (like Google and GitHub) in my local site.

These resources were helpful in setting up Boost Staging as an OAuth provider in my local environment:

• https://petersimpson.dev/blog/django-allauth-custom-provider/
• https://raphaelyancey.fr/en/2018/05/28/setting-up-django-oauth2-server-client.html
• https://stackoverflow.com/questions/72176662/problem-authorizing-client-with-django-oauth-toolkit-authorization-code-flow
• https://github.com/pennersr/django-allauth/pull/1410/files -- Example of adding the Slack provider to allauth

Note: I know we won't have a "Log in with Boost!" button on the sign up page -- that would be odd. It was the best way to test, though.

Instructions

1. In the consuming project (the mailman project, for example), add a providers app
2. Subclass OAuth2Provider in providers/provider.py to create the custom Boost provider
3. Subclass OAuth2Adapter in providers/views.py to create the custom Boost provider login flow
4. Hook up the URLs
5. (demo only) Add the Boost provider to the login options
6. Create a fresh user in Staging
7. Start your local server
8. Use your staging user and the Boost provider to log into your localhost site

Outstanding problems

The oauth toolkit default is now to use PCKE: https://django-oauth-toolkit.readthedocs.io/en/latest/getting_started.html#authorization-code, which I am having trouble implementing. There is a setting we can add to turn it off, but PCKE is the new standard. Update: After talking with Frank, it seems we'd probably disable PCKE via a setting.

Video:

boost_oauth_provider_progress.mov