On 7/06/2015 22:21, Shane Tomlinson wrote:
> On Thu, May 28, 2015 at 6:24 AM, Ryan Kelly <[email protected]
> <mailto:[email protected]>> wrote:
>
>
> 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...
>
>
> As I was reading through the sequence of token bearing, I asked myself
> the same thing I've asked many times "why are BrowserID assertions even
> a part of this process?" What is the legacy reason that Sync needs them?
It's how Firefox authenticates itself to the sync server infrastructure.
Getting away from them entirely would involve:
* updating the sync servers to accept oauth tokens for authentication.
* updating the sync client code in Firefox to use oauth tokens.
* waiting for sufficiently low usage from older versions of Firefox
that we can disable the old endpoints on the servers.
I'd like to work towards to first two because it's the Right Thing, but
I'm not sure the third would ever come to pass.
> 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.
>
> Remove the steps that aren't strictly necessary. If BrowserID assertions
> are only needed for Sync, why not only generate them for Sync? For users
> not signing in to Sync, we would be able to remove several steps/XHR
> requests, possibly giving the user a marginally quicker experience once
> they click "Sign in".
Agreed. The extra latency is at least several hundred milliseconds for
me, and that's not even measuring the extra crypto blah-blah we need to
do in the client to generate the signed identity assertions.
If we went this route, I think we could entirely remove the BrowserID
stuff from fxa-content-server. Sync does its own handling of those
formats in native Gecko code.
Cheers,
Ryan
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
