Sign-in with Google

[stadust]

Add the ability to sign in with Google. The end goal is that the current registration and username/password system will be completely replaced (with the option to use the current username/password login only for accounts created before the new system was put in place).

• Phase 1: Add ability to link google accounts to current pointercrate accounts. If I understand the high level overview that google gives on https://developers.google.com/identity/gsi/web/guides/integrate, it actually sounds quite simple

  1. Add a google_account_id column to the members table

  2. Add a "Sign-In With Google" button to the account landing page (https://pointercrate.com/account)

  3. Most of the complicated oauth stuff is handled by google. We can use the HTML API. The flow here is

     1. The user clicks the button, and goes through whatever Google does to log you in
     2. Google calls a JavaScript function in the pointercrate frontend, and passes it a JWT for the Google Account that just logged in (let's refer to it as GJWT, and to pointercrate's JWT that identifies the pointercrate account currently signed in as PJWT)
     3. Our JS handler does a POST to a new pointercrate API (say /api/v1/auth/google/link) containing the GJWT and authorizing with the PJWT.
     4. The backend verifies the GJWT. If it is valid, get the currently logged in pointercrate account from the PJWT, and update this account's entry in the members table by setting the google_account_id to the sub field of the GJWT.

• Phase 2: Add ability to actually log in with google

  1. We add a "Sign In With Google" button to the login page (https://pointercrate.com/login)
  2. The flow will be very similar to above, however the pointercrate endpoint (say /api/v1/auth/google/login) handling log-ins with Google will query the members table for the account that has the received Google JWT's sub field (after validating, ofc!), and return a PJWT for that account on success (still, a lot of code can probably be shared with step 1. - let's cross that bridge when we get to it though)

• Phase 3: Add ability to create new accounts through Google Sign Up - This one might actually be the trickiest one, funnily enough

  1. We deprecate the existing registration endpoint (/api/v1/auth/register). I think it's fine to just have it start returning some error unconditionally.

  2. When creating a new account through google sign-in, we'll need to deal with two problems (after doing the same OAuth dance as above):

     1. How to fill in the new account's user name?
     2. dealing with the fact that no passwords exist for these accounts.

     The latter is a problem because the JWT pointercrate creates are signed using a combination of the server's secret and the random salt used when hashing the account's password (which, yeah, no idea what 16 y/o me was thinking here). So that'll have to get fixed up. I guess just depending on the server's secret will be enough, but we need to make sure that we only change this for accounts that were created through the google sign-up option, old accounts should continue doing whatever we are doing right now.

     The former, we can fix by simply dropping the entire username concept. Accounts created through Google Sign-Up with have the username field set to null, and their display_name field set to the name of the google account (we get this information from the GJWT). Reason for this being that this is easier than providing some bizarre "username initially set to name of google account, but you can change it once in case you don't want to have the google name public" functionality. Currently pointercrate only uses the username for "legacy" login (which wont be possible for these accounts anyway), and when rendering the account as part of the claim verification system, and when you're a List Mod. For the latter reasons, we should make display name mandatory for these accounts (they can stay optional for legacy accounts).

  3. We'll also need to take passwordless-ness into account when rendering the UI (e.g. there should be no "change password button"), and when doing various PATCH requests (e.g. no programmatic password changes via PATCH /api/v1/auth/me)

We won't support changing the google account associated with a pointercrate account (at least for now, although I guess a lot of the code from Phase 1 could be reused to implement this should it ever be needed).

• Phase 4: Automatic Claim Verification via YouTube API. This is the most open-ended one yet. I think we can either request a GJWT that allows us read-only access to that google account's public YouTube videos (in which case we need to store not just the Google Account Id, but the entire GJWT, and also implement some refresh functionality, which sounds nasty), or we simply implement a second OAuth flow during player verification (probably simpler). Here, some research probably needs to be done. Either way though, what we want to have is the following system:
  1. If a pointercrate account initiates a claim on a player, cross-reference the YouTube videos of records of the claimed player with the YouTube Channel of the Google Account associated with the Pointercrate Account.
  2. If all record videos are from the YouTube channel of the account initiating the claim, auto-approve the claim (maybe we can have some sort of threshold based system here, and we'll have to think about very old records without videos/deleted videos, but I'd hope those are edge-cases that can be manually reviewed using the current system).

[stadust]

Oh, and there's also some code scattered around the repository about "email verification". That was an old attempt to instead associated email addresses to pointercrate accounts for password reset reasons. It failed because I couldn't be bothered to set up an email server. So that code should probably just be deleted as part of this.

[stadust]

In the beginning, the interesting code for this project lives almost completely in the pointercrate-user packages.

• User models and authentication code are in pointercrate-user, specifically https://github.com/stadust/pointercrate/blob/master/pointercrate-user/src/auth/mod.rs
• The new API endpoints should live in https://github.com/stadust/pointercrate/blob/master/pointercrate-user-api/src/endpoints/auth.rs, while https://github.com/stadust/pointercrate/blob/master/pointercrate-user-api/src/auth.rs is the code that handles PJWT validation on receiving requests
• The frontend code for the main account and login pages is https://github.com/stadust/pointercrate/blob/master/pointercrate-user-pages/src/account/profile.rs and https://github.com/stadust/pointercrate/blob/master/pointercrate-user-pages/src/login.rs

For the last phase, some work with the demonlist packages will be needed, but we can get to that later

[stadust]

Little update: A bunch of preparation has been done for Phase 3 of the above:

• Refactor authentication to more easily support oauth #171 and More refactors to prepare for oauth login #172 moved the current registration system behind a cargo feature flag
• Overhaul authentication module #185 fixed up various dependencies on account having passwords
  • Do not require users to re-enter password, unless they want to change password, so that operations like changing display name and invalidating access tokens are possible for password-less accounts
  • hide change password option for non-password based accounts
  • stop doing the weird signing logic and just rely on the server secret

[stadust]

With #229 merged and deployed, the first two items are done!

[stadust]

Alright, with a8cf19f we now have support for oauth-based registration as well 🎉