1630365 - Open-in-container for SSO breaks Zoom for Windows login integration

Status: RESOLVED MOVED

(Core :: Security, defect)

Description

[Beth Rennie [:beth] (she/her)]

If you se auth.mozilla.auth0.com to open inside a container, the login to the Zoom windows app workflow breaks.

STR:

1. Install Zoom for Windows
2. Add a container that is set to open auth.mozilla.auth0.com
3. Click "Log In with SSO" in Zoom and enter "mozilla" as the domain

AR:

1. A tab opens auth.mozilla.auth0.com outside of a container
2. That tab closes immediately and a new tab opens with the same URL inside a container
3. Login happens
4. Redirection to a Zoom account page. No "Open URL in ..." popup appears.

ER: (What happens if you do not have auth.mozilla.auth0.com set to open in a container):

1. A tab opens auth.mozilla.auth0.com
2. Login happens
3. Redirection to a zoom:// URL that triggers a "Open URL in ..." dialog. Opening that URL in Zoom completes the login in the Zoom app.

Comment 1

[:Gijs (he/him)]

OK, so I finally got round to poking at this. If you open the browser toolbox on the network pane before using the zoom auth thing, you can see that:

(In reply to Barret Rennie [:barret] (he/him) from comment #0)

1. A tab opens auth.mozilla.auth0.com outside of a container

is actually not the first step. The initial request is to

https://mozilla.zoom.us/saml/login?from=desktop&zm-cid=<stuff>

And that returns with a bunch of Set-Cookie headers, which will run outside of the container, and a location header that redirects to auth.mozilla.auth0.com .

The redirect then takes us into the container, in a new browsing context, and we stay in that container when completing sign-in. After which we go back to zoom, still in the container for mozilla.auth0.com, where there are no cookies and zoom goes "uh wat", having no access to the cookies that started the auth routine, and nothing happens.

To work around, assign mozilla.zoom.us to also open in the auth0 container. That makes things work for me.

I don't know what we should do differently here. In theory, the redirect back out of the SSO domain could try and return to the "original" container if we kept track of that... I don't know if that logic lives in core code or in the add-on, and it still feels kind of weird because it effectively enables automatic information transfer from outside container A into the container and back out again, which could also be used to defeat precisely the kind of thing containers are supposed to stop (or at least detect that you're using containers).

Johann, thoughts? Who works on this stuff, and/or is this already on file in some form?

Comment 2

[Johann Hofmann [:johannh]]

Yeah, I'm really not sure what to do about this, as Gijs said, this is sort of how containers are supposed to work and usability issues like that (the fact that you have to go debugging site-specific code to make things work) is part of why containers wasn't shipped to a larger audience yet.

So from my side this is probably WORKSFORME?

Tanvi, are you still interested in containers issues? Is anyone else? Do you agree that we can close this?

Comment 3

[Tanvi Vyas[:tanvi]]

In order to do the full auth flow, you need to be in a single container. The fact that it breaks across the flow is kind of good from a pure privacy standpoint - if the container is a privacy boundary, then we shouldn't leak information across it. In Facebook Container, we solve this by moving all sites that the user "logs in with facebook" with to the Facebook Container. I understand this is an issue from a usability standpoint. Its hard to draw the line perfectly here.

The assignment code that assigns a particular site to a Container is done by the extension (multi-account containers and Facebook Container). It doesn't live in the platform. The issue should be filed here https://github.com/mozilla/multi-account-containers/issues instead. Though, again, I'm not sure there is anything we would do about this right now.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:dveditz, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 5

[Daniel Veditz [:dveditz]]

It might also work if Zoom were also tied to a specific container, so that the auth0 callback to zoom is then reopened in a new tab with the original zoom cookies. As Tanvi said, it might "work", but it's already destroyed the privacy goals of having separate containers (the Zoom and auth0 containers now both know you're using each other because of the callback URLs). You'd also then have 3 tabs open which isn't ideal.

I've had much better luck putting my auth0-using apps in specific containers and not worrying about auth0 itself -- it follows along. In theory I could have two different auth0 logins for different sites and this approach would let me keep them separate. In practice I don't, but I've used this same approach for segregating sites where I use different Google identities (e.g. mozilla GMail vs. personal stuff).

If you want us to do more brainstorming you can file a github issue against the extension as in comment 3, but I think this is essentially a "wontfix" for now.