Investigate why 3rd party cookie blocking disables auth. #339

dwhly opened this Issue Mar 22, 2013 · 11 comments

4 participants

Hypothesis member

No description provided.


I'm still very much in favor of moving to a popup flow like Persona. If we do that, then the cookie would be set in a first-party interaction. In that case, we could close this as "wontfix". What do you think?

Hypothesis member

How do we design this?

Someone implements #126. Someone digests shane-tomlinson/ and groks how to be an IdP for BrowserID. Someone implements the IdP side of the flow against our account database. Once its understood which pages need to be designed, they get designed.

What would be the immediate implications?

No third party cookie issues. More visually inspectable transport security and host authenticity for the end user (less phish-able, one hopes).

Does it mean a change to how we allow registration/reservation now?


Are there any corner cases when a popup flow breaks?

Maybe. I haven't trolled through all the material from BrowserID nor of mozilla's dev-identity list, though I've been watching it for some time. Things look good. I think postMessage is required, but it is for our frame communications anyway.

Who does it well? What sites or organizations represent the ideal?

I don't understand the question. Mozilla?

How can we generalize a new flow that lets us enable third party authentication with many others?

We don't. Third party authentication stays the same as is state of the art. You present various options. There are other things that might play into this eventually, the lastest of which that I've seen is barnabywalters/web-action-hero-toolbelt but I'm not sure it has a story for a login action. Meebo's xauth (never) happened. So you get nascar login or decide which ones you support. The point is that the details of securing an API token are opaque to the browser annotator application and happen in first-party interactions, whether that's a web popup we construct or it's a native implementation with a hardware security device.

More specifically, velruse integration in horus, browserid integration in the app (used as polyfill, in absence of native implementation, as persona does, or simply persona if the default build is smart about discovering identity providers, which might mean implementing some /.well-known views if memory serves), and an identity provider backend over our horus db.

I think there are pieces I'm missing or don't fully grok yet, but that's my brain dump.

What are the implications overall to h.?

Ability to safely obtain authentication tokens for multiple services from one browser application through first-party interactions. I would consider this doing #343 the right way.

What is the upside? How does it help us?

Hopefully clear by now.


Ah, to the question, "How can we generalize a new flow that lets us enable third party authentication with many others?" I think the anwer is actually "I understand this to be one of the goals of BrowserID".


Here's how it's done:

So, someone must read the spec and figure out exactly what should be on the authentication and provisioning pages and how they signal success on the client.

That would close this issue and #348.

Then we can do social login from within our authentication page with velruse integration in horus and any of #125, #126, #112, etc.


And this blocks #343 IMO if that's not already clear.


@tilgovi ping. I've got some spare cycles. Still interested in adopting Persona? I can help get a prototype together and/or answer questions about the protocol.

I have a standing meeting Thursdays at 930, but I bet we can get rolling async. I'll fork and start getting a local dev environment configured.

If there are questions you or @dwhly would like to discuss before I work on coding it up, I'm happy to address them here.


If you want to give it a go, be my guest! The only consideration is that our app runs as a third party widget in an iframe. Maybe if the persona login flow communicates back to window.opener everything will "just work". I did prototype an OAuth2 flow for logging in via where I had to do the pop-up and postMessage token passback myself. You can see it in the last few commits on the appnet-hackathon-06-08 branch.

IIRC Persona should take care of all of that, though.

h/js/ has an "Authentication" service. You can override its '$get' method to return any object you want. That might be the place to contain the bleed if we start to change to Persona. One issue with doing that is that object returned currently has both the login data (.username, .password) and methods (.$login, .$logout).


@tilgovi cool, I'll have a look tonight. The third-party context shouldn't be an issue; the Persona snippet runs inside the RP DOM, not in a separate iframe, so listening for login/logout events is as easy as setting callbacks inside a call on page load. Persona will manage all the popup/iframe communication. I assume you guys require third-party cookies/storage be enabled, so we should be all set.

I'm not a coffeescripter so might be a bit slow getting started. I'll see what I can get done in a week, and will ping on IRC if I get stuck between now and then.

Still interested in building an IdP? If so, feel free to ping me with questions, whether in a bug here, on the dev-identity mailing list, or #identity on moz IRC.


The reason the third-party setting disables authentication is that our domain is not able to set cookies on requests made from our iframe. When the host page is not from our domain, our iframe is considered third party. Right now, authentication relies on cookies for cross site request forgery prevention and for session management. I've thought about various ways we might avoid this requirement, but the best is definitely to do authentication in a pop-up and start passing our credentials as a token header just as we already do for calls to the storage API.

As we develop our identity provider work we can move the annotator token system over to an OAuth2 token system and do our login either using Persona or a Persona-like flow.

In the chrome extension version of our application we can whitelist ourselves when the app is installed, and that would be a quick fix for #634, but I will have a chance to wrap up my pdf.js and auth refactoring work in the next days.

Since the topic of this issue was only to explain why we see this behavior, I'm going to close it in favor of a combination of #126, #348, #634, etc.

@tilgovi tilgovi closed this Aug 15, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment