single sign out with Firefox Accounts

Lloyd Hilaiel lhilaiel at mozilla.com
Tue Nov 12 01:38:19 PST 2013


tl;dr; - I believe we’re arguing priority of optimal FxA behavior for Mozilla run services vs. Externally run services.  I also believe that even if we disagree on the relative priority of the two, there’s a path forward that lets us defer the logout feature until we’ve got a way to login. 

On Nov 12, 2013, at 1:44 AM, Chris Karlof <ckarlof at mozilla.com> wrote:
> 
> On Nov 11, 2013, at 11:28 AM, Lloyd Hilaiel <lhilaiel at mozilla.com> wrote:
> 
>> On Nov 9, 2013, at 3:39 AM, Chris Karlof <ckarlof at mozilla.com> wrote:
>>> But we *are* building a SSO system. I argue we need .onlogout() or something similar to it to notify relying Mozilla services when the user has logged out.
>> 
>> Concrete use cases?
>> 
> 
> To be clear, I'm not arguing specifically for .onlogout(). I'm arguing for a high level behavior (SSO) that has a "as loosely coupled as possible"  implementation.
> 
> Here are some logout "use cases", maybe not all of them MVP:
> 
> Terms:
> 
> MP: Firefox Marketplace
> WMF: Where's My Fox
> 
> 1) A user has MP and WMF open in different tabs. The clicks "logout from my FxA" in MP. Ideal behavior: the logged in state on the WMF tab should switch to "logged out" and be signaled in the UI. 

> 2) A user logs into her FxA from MP, interacts with MP, closes the tab. The user opens WMF, interacts with it, logs out of her FxA. She then opens MP. Ideal behavior: MP should be in the logged out state.

This makes things clearer, thank you.

With what priority shall we address logout behaviors across sites?  This is clearly beyond the 1.3 horizon and to me it is unclear if the defined ideal behavior is actually ideal on all environments.

This makes me believe we should take it off the table for now (without shooting ourselves in the foot later), and queue it up for jgruen and rfreely to explore (maybe get some feedback from Adam Rogers along the way)?

>>> If there are issues with .onlogout() not working well, we should address those issues, but I think we "want" it.
>> 
> 
> Again, I misspoke. We need a way to signal to relying Mozilla services that the user has logged in and logged out of her FxA. This may or may not be via .onlogout() on the Watch API.

Agree we don’t have to do this via the onlogout() API.

>> We want it in persona too, but it can’t be reliably implemented - this was the conclusion we (dan, sean, shane, myself, etc) came to.  It would be useful to challenge this belief with a holistic review of client storage mechanisms and their behavior under default and user configurable privacy properties.  We have so much of this knowledge spread across our teams and in issues, a blog post or article gelling it all together would be really fantastic.  
>> 
>> If such an endeavor were timeboxed and quick, this could contribute meaningfully to others in similar positions.
>> 
> 
> Note that we have more flexibility than Persona because we are running the services relying on this state management. For example, all our services could run on the same second level domain (e.g., *.firefox.com). Or not (webmaker.org). 

I believe the or "not case" is going to be the rule.  It is too soon to tell, but everyone external I’ve talked to about firefox accounts is really excited to participate.  Success here probably looks like we have orders of magnitude more external services than internal.

I know before you’ve said we should focus on the real problems we have and not on an uncertain future - and I agree.  I’m arguing at this point to not overly optimize for predominately mozilla services, nor predominately external services.

>>> An alternative I've heard is "session cookie assassination", where FxA kills the session cookies of relying Mozilla services on logout. IMO, this is more fragile approach and is insufficient.
>> 
>> Where precisely do you perceive fragility?
>> 
> 
> IMO, it's too tightly coupled. E.g., It makes it difficult for services to change how they manage sessions without breaking legacy clients.

That’s fair, and this concern came up in initial design 3 years ago.  The thinking was that cookies are ubiquitous and are a great starting point, but we could add new mechanisms for the UA to inform sites of a user’s intent to log out as it becomes clear they are necessary.  

We could even re-add an document or javascript based way that the UA could indicate to a service the user’s intent to log out.  (onlogout is dead, long live onlogout!)

> Plus it doesn't work on all browsers.

Yeah, this is important.  We’ve failed to find a simple and robust way to convey logout events to RPs in persona - which is optimized for the “external services” case.  We could add in something custom for firefox accounts that perhaps sacrifices simplicity in order to re-gain the feature (you mention this below “[google’s solutions are not] terribly elegant”).  I think by tabling the feature now, though, we reduce short term complexity and do not prevent re-introduction of this feature in the future.

>>> I'm not sure how to accomplish this across multiple domains without UA support, and FxA has to work everywhere (i.e., non-Firefox browsers).
>> 
>> Our approach with persona was to implement the maximum set of features we could reliably implement everywhere (goldilocks), and then gracefully upgrade when UA support exists.
> 
> This doesn't seem acceptable as a cross-browser strategy for FxA SSO. If Google can have SSO for its properties without user agent support, so can we. If a JS ambassador API isn't the right approach, we should find another one. 
> 
> Google's approach doesn't seem to be terribly elegant or loosely coupled (mostly on *.google.com, uses domain cookies on google.com, uses redirects and explicit state creation on login to transfer session to youtube.com). I hope we can do better, but maybe not or maybe we shouldn't try to do better. I'm still digging in, and suggestions for a simple cross-browser solutions are welcome.

First, we’re not google.  Google has a two tiered auth system that works *awesome* for google properties, and serves up oauth2 to everyone else - works ok.  This seems appropriate in a world where google has a service for absolutely everything and likes to cross-promote its own services.

Our parameters are different.  We aren’t going to build every service - we’re only going to build the important ones that either deliver features that are important to users that no-one else will actually build, or that really level the playing field and let external developers do really interesting stuff.  For instance, services that complete WebRTC and turn it into a viable platform that app developers can innovate on seems extremely high value.  Building our own photo archiving solution would be silly.  

This general intent and focus is the path that I find where Firefox Accounts really resonates with our mission.

>> There are extensive threads around goldilocks in dev-identity (I actually was *really* reluctant to give up on onlogout, it took some conversation and convincing, and now I’m a convert).
>> 
> 
> I'll try to dig in to those. 

I’ll try to help tomorrow by putting down what I personally (think) I know about browser behaviors and how they constrain our ability to send a user to a remote domain and back with input and output parameters - and how browser behaviors constrain us.  (Sean’s also been doing some working and thinking in this area).

lloyd

> -chris
> 
> 
> 
>> lloyd
>> 
>>> Thoughts? 
>>> 
>>> -chris
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/dev-fxacct/attachments/20131112/5dcf370a/attachment.html>


More information about the Dev-fxacct mailing list