On Sun, Jun 7, 2015 at 3:38 PM, Ryan Kelly <[email protected]> wrote:
> 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. > > It might be easier than you think. ESR is the tough case, but most of our active users are on recent versions of Firefox. > 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. BiD assertions make the decoupling of Auth and OAuth servers easier to deal with. If we go for the "giant smushâ of a combined Auth/OAuth/Device manager (which makes a lot of sense), we can probably simplify there. -chris > > Cheers, > > Ryan > _______________________________________________ > Dev-fxacct mailing list > [email protected] > https://mail.mozilla.org/listinfo/dev-fxacct >
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
