single sign out with Firefox Accounts
ckarlof at mozilla.com
Mon Nov 11 15:44:38 PST 2013
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:
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.
>> 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.
> 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).
>> 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. Plus it doesn't work on all browsers.
>> 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.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dev-fxacct