The plan for the great OAuth Migration

So I think we can make the switch to Boruta much easier based on what WildWolf has done, I’ve been experimenting with it locally and my proposal is to:

  1. Add Boruta and use it directly for all new oauth apps.
  2. Create a Boruta client for each existing oauth app, set the Boruta secret to the existing oauth secret. Port all scopes, redirect urls, etc over
  3. Add a field to Boruta clients table to specify the old oauth client_id (the sha256 based one)
  4. Add a request modifier (plug, action, or similar) to detect a sha256 based client_id, and use that to lookup & modify the request to actually use the Boruta id.
  5. Migrate all existing valid access tokens & refresh tokens over to Boruta so they continue to work & refresh as expected.

This proposal would allow us to switch to Boruta for handling oauth, without forcing any migration for any of our users or their apps.

Points 1-4 is already programmed.
Point 3 is done a bit differently where it’s not on the Boruta client but as the old system on the Application.
Point 4 is not fully tested as I have nuked my database but should work as I based it of the old code and added in Boruta authentication methods.
All of these are available on Glimesh/glimesh.tv at oauth2_lib_removal (github.com)

1 Like

Got the initial PR up here:

But going to give it a couple of hours / days to simmer before creating a rollout plan.

THESE CHANGES ARE NOT LIVE YET, THIS IS A DRAFT POST FOR WHAT WE WILL BE ANNOUNCING!

!!!DRAFT POST!!! Glimesh Oauth Migration !!!DRAFT POST!!!

Hello folks! We’re migrating our API over to using a new internal provider for our OAuth 2.0 requests.

There should be no change required on your end to continue accessing the API. To see if you need to make any changes, we’ve identified some key changes below you should be aware of.

Key Changes

(ordered by potentially required impact)

  1. Access & Refresh Token Length Changes
    Previously the access & refresh tokens were alpha numeric based lowercase values 64 characters in length. Newly issued access & refresh tokens will still be alpha numeric based but now mixed with uppercase values and up to 255 characters in length.

    Examples:
    Old Token: b765e84e8699e797c7a0b5ceb170cfb3af490da5218207f79f4c59e346c659ec
    New Token: RO8mcRW74RSAyUr91y4GXYAqkx1AX4Bz28Y2D0zPw6r0DkVoi1Nc6PjBgaMZem6JmeEeKVCx3pLEkqj7BA2xjf

  2. New Client ID’s are now UUID-based
    Previously the Client ID’s where alpha numeric based lowercase values 64 characters in length. The new Client IDs are UUID’s instead. We generated a new Client ID for each application, but have implemented backwards compatibility for your old Client ID. You can visit your applications page to find out your new Client ID.

    Examples:
    Old Client ID: 692f5f308a0984ea31597764dcabade6a82350b746162339c2c8f0110d083983
    New Client ID: 01c12535-e124-4f4a-9c3d-e780a73cf2a1

  3. Client Secret Length Changes
    Previously the Client Secret’s where alpha numeric based lowercase values 64 characters in length. Newly generated Client Secret’s are still alpha numeric based but now mixed with uppercase values and up to 255 characters in length.

    Examples:
    Old Client Secret: c1a380075e3a75014a20075eda0352b3cdf5142d4a0c35dd7e66ba78e4f79be2
    New Client Secret: ahGUJIyuk8KnRKmYXNDVONInw7OTexhtTaJWJDxdv8UCECB8e3OoaCGIwdjscPJZnxIqLP2CT20C0ToxZ2SQ7V

Recommendations

If you want to future proof your app now, we recommend rotating your keys in your applications page. This will generate your a new secret to add to your app. You can use your newly generated UUID based Client ID as well. There is no need to refresh any of your tokens outside of their normal cycle, as they will be automatically refreshed into the new format as they expire.

Got the post published at OAuth Migration - #2

Tenative plan is to announce it via email to all active devs, along with the new GraphQL API migration guide @Mytho is writing on Friday.

Making some final changes on the PR & doing some more migration testing this week. Super hyped to roll this out Friday so we can start testing the mobile app against the production site.

Deployed, had two issues:

But now everyone is on Boruta! Success!