On 19/06/2015 04:14, Christopher Karlof wrote:
> On Sun, Jun 7, 2015 at 3:38 PM, Ryan Kelly <[email protected]
> <mailto:[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]>
> >
> > 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.
My instinct is to be incredibly conservative when breaking behaviour
that old Firefoxen depend on, but I've never really had to quantify it.
What should our definition of "sufficiently low usage" be that would
let us consider disabling the assertion endpoints entirely?
> > 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.
Based on this discussion, I actually *do* have concrete plans to
actually go ahead with this, and will be working on a prototype API at
Whistler.
> 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.
True, but IIRC this was more of a happy accident that a deliberate
reason for adding BiD functionality in the auth server. (I could easily
not recall correctly though)
> If we go for the "giant smushâ of a combined
We could start the next hot trend: Giant Smush Service Architecture...
Cheers,
Ryan
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
