Bug: When oauth is enabled, make sure we don't try and get or use a keyFetchToken
Status: RESOLVED
Priority: P1
Resolution: WORKSFORME
Created: 2024-09-04 20:01:52+00:00
Resolved: 2024-11-27 19:01:45+00:00

In the existing flows, we get the "keybundle" by first getting a keyfetchtoken from the server, and making a http request with that token to get the key bundle. We then use that keybundle to derive our own keys etc.

However, the oauth flow changes this - the fxa content server does most of that work and hands us our "scoped keys" (ie, the sync keys) [as part of the oauth_login webchannel message](https://searchfox.org/mozilla-central/rev/5959ec6b84d66592a77a3e5e2d2aedc1b3e7d4c5/services/fxaccounts/FxAccountsWebChannel.sys.mjs#538).

However, there are still many references to the keyfetchtoken, most of which are still hit during account setup.

For example, [this code](https://searchfox.org/mozilla-central/rev/5959ec6b84d66592a77a3e5e2d2aedc1b3e7d4c5/services/fxaccounts/FxAccountsKeys.sys.mjs#97-100) says that if we don't currently have the keys but do have a keyFetchToken, we can obtain the keys - but I believe this is not actually true. Further, it seems like we might actually have a `keyFetchToken` at some point - the logs below say we do, and that only is logged if the value is non-null.

eg, some logs showing this confusion:
```
1725464603835   FirefoxAccounts DEBUG   writing secure storage: ["keyFetchToken","unwrapBKey"]
1725464603835   FirefoxAccounts TRACE   starting write of user data to the login manager
1725464603836   FirefoxAccounts TRACE   finished write of user data to the login manager
1725464603855   Services.Common.RESTRequest     DEBUG   GET https://api.accounts.firefox.com/v1/account/keys 401
1725464603855   Hawk    DEBUG   (Response) /account/keys: code: 401 - Status text: 
```
(ie, we tried to fetch keys but got a 401
```
1725464603855   Hawk    DEBUG   Clock offset vs https://api.accounts.firefox.com/v1: -855
1725464603855   FirefoxAccounts ERROR   error GETing /account/keys: {"code":401,"errno":110,"error":"Unauthorized","message":"The authentication token could not be found","info":"https://mozilla.github.io/ecosystem-platform/api#section/Response-format"}
1725464603855   FirefoxAccounts WARN    handling invalid token error: {"code":401,"errno":110,"error":"Unauthorized","message":"The authentication token could not be found","info":"https://mozilla.github.io/ecosystem-platform/api#section/Response-format"}
1725464603855   FirefoxAccounts INFO    checking account status...
```
That 401 causes us to think maybe the account is in a bad state
```
1725464603855   FirefoxAccounts WARN    handling invalid token error: {"code":401,"errno":110,"error":"Unauthorized","message":"The authentication token could not be found","info":"https://mozilla.github.io/ecosystem-platform/api#section/Response-format"}
1725464603855   FirefoxAccounts INFO    checking account status...
1725464603856   Services.Common.RESTRequest     DEBUG   GET request to https://api.accounts.firefox.com/v1/session/status
1725464603857   Services.Common.RESTRequest     DEBUG   GET request to https://api.accounts.firefox.com/v1/session/status
1725464603911   Services.Common.RESTRequest     DEBUG   GET https://profile.accounts.firefox.com/v1/profile 200
1725464603911   FirefoxAccounts DEBUG   _updateAccountData with items: ["profileCache"]
1725464603912   FirefoxAccounts DEBUG   writing plain storage: ["email","sessionToken","uid","verified","device","oauthTokens","profileCache"]
1725464603912   FirefoxAccounts TRACE   starting write of json user data: ["email","sessionToken","uid","verified","device","oauthTokens","profileCache"]
<snip>
1725464603932   FirefoxAccounts INFO    account status: ok
1725464603932   FirefoxAccounts WARN    invalid token error, but account state appears ok?
1725464603932   FirefoxAccounts WARN    Failed to fetch keys, so unable to determine command keys: {"code":401,"errno":110,"error":"Unauthorized","message":"The authentication token could not be found","info":"https://mozilla.github.io/ecosystem-platform/api#section/Response-format"}
```
So we ended up deciding the account state is OK, but we failed to setup the command keys.

There's a good chance that even with all this noise things end up working out in the end, but it's still bad.

Sorry this is so vague, but I think the thing we need to do here is, roughly, make sure that it's "impossible" for us to fetch or even check our keyFetchToken, let alone the keys themselves, if the oauth pref is enabled.