Thanks for the thoroughly considered response, Ryan! On May 27, 2015, at 10:24 PM, Ryan Kelly <[email protected]> wrote:
> On 27/05/2015 07:00, Kit Cambridge wrote: >> Over the past few weeks, we've talked about adding push notifications to >> other projects and services. We're also looking at implementing broadcast >> and multicast push. A lot of these need a way to map a user's account to all >> her "Foxes." To that end, we're thinking of building a device manager >> service that exposes the following: >> >> * Endpoints for a device to register and de-register itself (when a user >> signs in to, or out of, Firefox). >> * An endpoint for updating an existing device record, such as when its name >> (in Sync prefs) or push endpoint changes. >> * Endpoints for other services to list the devices attached to a user's >> account. This can be used for multicast push, as well as services like Find >> My Device and the content server app. >> * An endpoint for remote logout, in case a device is lost or stolen. >> * An endpoint for deleting a device, which logs the user out remotely and >> deletes the device record from the service. > > I'm not sure I get the distinction between the last two. > > Would a logged-out-but-not-deleted device still be visible to the user, > perhaps with some sort of "disconnected" indicator? Yep, that’s the idea. The use case I’m thinking of here is Find My Device…the device should retain its ID and push endpoint, but its session should be revoked. I guess it doesn’t matter from the perspective of the auth and OAuth servers; the device manager service just does additional cleanup for deletion. >> The first three can be handled by a separate service, but remote logout will >> require some changes to FxA. We'd like this to be equivalent to calling >> `fxAccounts.signOut(true)` on the client [1], where we destroy the session >> token and all OAuth tokens issued to that client. The difference is that >> this call will be made by the device manager service, instead of the client. >> So, to support remote logout, we'll likely need: >> >> * A call to destroy an FxA session token for an account, given an OAuth >> token. > > I think this makes a lot of sense, +1. > >> * Calls to destroy all OAuth tokens issued for a particular session. AIUI, >> the OAuth server currently doesn’t know anything about sessions, so this >> would be tricky. > > Correct. There's a layer of indirection between session tokens and > oauth tokens that would make this pretty close to impossible in the > current architecture. > > We have to be careful w.r.t the web authentication flow here. For the > web flow, we definitely want OAuth tokens to outlive the session token > that created them. Definitely. Revoking all OAuth tokens issued for a particular Firefox session is a weirdly specific use case. It makes sense that the current architecture wouldn’t support it. >> Danny mentioned pulling fxa-oauth-server into fxa-auth-server; would this >> help at all with that? > > Heh, this suggestion may come as a surprise to folks on this list. > > The context here is that to get an OAuth token, you must currently: > > 1) Get a sessionToken with the auth-server > 2) Use it to sign a BrowserID identity certificate > 3) Use that to generate a BrowserID identity assertion > 4) Give that to the oauth-server to get an OAuth token > > But we have no plans to use BrowserID assertions in any new work going > forward. We need them in sync for legacy reasons, but all new > FxA-attached services will be using OAuth and OAuth only. > > So it sure would be nice if you could go session token => OAuth token > directly and cut out the middleman... > > Hypothetically, it might mean that the auth-server could grow a /oauth > endpoint under which we expose the current oauth-server API, > authenticated with session tokens rather than assertions. > > Note that we've no plans to actually go ahead with this, it's just an > architectural musing. I'd be interested in everyone's high-level > reaction to the suggestion. > >> It looks like the only way to make remote logout work now is for the device >> manager server to persist the user's session token (and any issued OAuth >> tokens!) in its database. This sounds scary—and probably negates the >> benefits of the OAuth server only storing token hashes—but maybe it's not so >> bad. > > The device manager could also store the tokens by hash, rather than > storing the raw token directly. We could expose a delete-by-hash API on > the oauth server pretty easily. > > This is likely the fastest way to get you moving without blocking on > anything from core FxA. Sounds good. If you’re happy with device manager storing those token hashes, I’m happy. :-) >> Some general questions for discussion: >> >> * Does device manager make sense as a separate service, or should it be part >> of existing FxA services? > > I like your proposed architectural split - a small set of core > token-management APIs exposed by FxA, and a richer device-centric > experience built on top of it. > >> * What's the best way to handle remote logout? > > I suggest we start with: > > * devices register all their token ids with the device manager, > where "id" is some appropriate hash of the actual token > * auth server grows a "destroy session token by id" API > * oauth server grows a "destroy oauth token by id" API > * device manager destroys all the tokens on logout > * all authenticated with some new, privileged oauth scope > like "account". > > There's value in iterating towards stronger FxA-side linkage between > devices and tokens, but the above seems like the minimum necessary > coupling to get your project underway. Perfect. As you say, we can revisit this in the future, too, once we have a clearer idea of how device manager fits in with everything else. >> * Do we punt on remote logout for device manager entirely? Not a great user >> experience, and makes stale devices more of an issue (particularly for >> multicast push). But, if it's a pain to support currently, we can shave this >> yak another day. > > I'm happy for this to force resolution of a bunch of long-standing > session-management questions on our side. This yak is definitely ready > to be shaved! > > More broadly, we have an open question about "Login to Device" versus > "Login on the Web" and how we manage the difference between the two. I > think a distinct Device Manager service could be a really nice vehicle > for teasing the two apart. > > But I'll resist the urge to pile on and balloon the scope of your > project just yet… Let’s get our yak shears ready, then! https://www.youtube.com/watch?v=trXjZ70ab1Q - kit _______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
