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?
> 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.
> 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.
> 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.
> * 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...
> Sorry for the long missive.
I enjoy long missives, both the reading and writing thereof :-)
Cheers,
Ryan
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
