Allow OAuth access to the "devices" API

[rfk]

See also accompanying mailing-list discussion at https://groups.google.com/a/mozilla.com/forum/#!topic/app-services-internal/ePyK3SFT4Dg

We're trying to more to a world where different apps can have different levels of access to your account, managed via OAuth tokens and scopes. One big thing that OAuth clients can't do right now is access the "devices" API to:

• Customize their display-name
• Register for push notifications about account status change
• Use the new "device commands" feature for things like send-tab

As noted in the above mailing-list thread, the devices API is pretty Firefox-centric - it assumes a world of similar-looking peers that all have full access to the user's Firefox Account. I expect we'll probably need a few iterations of refactoring to move from where we are today, to a model that "fits" in an OAuth-style world. But let's see if we can make the first such step.

Can we allow holders of OAuth tokens with the "https://identity.mozilla.com/apps/oldsync" scope to access the devices API in a similar manner to their sessionToken-holding peers?

The access-control is the easy part - we already know how to accept either a sessionToken or an OAuth token with specific scopes, from e.g. the /account/profile API. But we'll have to figure out the following questions:

• How can we have a device record without a corresponding sessionToken? There's some initial discussion of this in Pull sessionToken out of the devices table fxa-auth-db-mysql#378, but it'll also require some changes in this repo to deal with the redis sessionToken cache, last-access time tracking, and user-agent info tracking.

• How do we figure out what is the "current device" for a given request, a concept needed in /account/device/commands and probably some other places as well. Currently we use the 1:1 mapping from sessionTokens to devices records to determine this. The current suggestion is that we create a mapping from OAuth refresh tokens to device records and look it up via that, but maybe there are other options?

• What happens when you /account/device/destroy a device record for an OAuth client? I think the expected behaviour would be that all of its OAuth tokens get destroyed, but that means we've got to reach over into fxa-oauth-server as part of destroying a device record.

• Do we need some notion of "placeholder" OAuth devices. I'm hopeful that this won't be necessary, because OAuth tokens already show up properly in the "devices and apps" view.

• Will existing sync clients get confused? If an OAuth app shows up in the list of devices on your account, will existing Firefox installs think it's another Firefox and offer to e.g. send tabs to it, despite the fact that it probably can't receive them yet?

@philbooth given your experience with the current devices API, I'd be really interested in your take on all this.

[rfk]

My strawman of a minimal set of necessary changes, including some issues already linked above:

• Change oauth-server to track what refresh token was used to create a given access token, and to report that in the response when verifying a token.
• Create some sort of backchannel whereby the auth-server can instruct the oauth-server to revoke a refresh token (or a set of tokens?).
• Remove the 1:1 mapping between device records and sessions; instead create two auxilliary mappings so that a device record can have either an associated sessionToken, or an associated refresh token (or set of tokens?). This will probably be pretty hairy...
• Add oauth as an optional auth strategy for the device routes, requiring the "oldsync" scope.
• Change the logic for "what is the current device?" to work with OAuth tokens, by learing the corresponding refresh token from oauth verification, then looking up the device record for that refresh token.
• Change device destruction to also revoke the refresh token(s) associated with the device record.

That's...well, it's a lot of complexity, and it really smudges away the distinction between auth-server and oauth-server by introducing a pretty fundamental coupling between their data models. But I think we're going to need to navigate this issue somehow, sooner or later, so maybe this is as good a place as any to start.

Pushback is definitely welcome though! :-)

[philbooth]

@philbooth given your experience with the current devices API, I'd be really interested in your take on all this.

At a high level I think it all makes sense fwiw. (I did read @eoger's email about it too, should have replied there sorry)

Thinking specifically about the db change, I was wondering whether you could get to the same end result with less upheaval by just defining a new oauthDevices table and then reading from both of them when fetching a user's device list. That means an extra query for fetching of course but at least they can run concurrently. But maybe I haven't thought this through properly because I'm not clear how it would work with the "current device" logic.

Anyway, whatever, there's nothing you or @eoger have written that I'm against in principle!

...it really smudges away the distinction between auth-server and oauth-server...

Yeah, I know you're a long-time advocate of bringing those two servers together. That definitely makes more sense to me reading this thread!

[vladikoff]

from mtg: new approach in the works by getting a sessionToken out of the OAuth flow instead

[shane-tomlinson]

See https://docs.google.com/document/d/1cbz3pZHGTjJwLoDqZyjNTyzyE1IvEeDE_-uEWrH-g9g/