On Thu, May 28, 2015 at 6:24 AM, Ryan Kelly <[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? > 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". Shane
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
