Bug 189580 – Intelligent Tracking Prevention 2 for Single sign-on

• Status: NEW
• Component: New Bugs

[Andrey Polischuk]

I work on identity provider that gives single sign-on to some products/services. We provide for our users:
- api that products/services use
- sign in and some other forms that are embedding in iframe or working by redirect
- js library to request current user data from our api

Some products/services use our forms, others create own forms that interact with our api by cross-origin requests with credentials. In any cases our tld is different than products/services domains, and our domain keeps session cookies.

Now each user sign in with our iframe form or with own product/services form once. After this, products/services use our js library to get user info on their domains (library makes cors requests to api without opening any iframe).

ITP doesn't allow cross-origin requests to api with session cookie and brakes our single sign-on. We can introduce requesting the storage access api in iframe forms, but this doesn't allow to products/services make cross-origin requests to our api with credentials.

Do I correctly understand that my case is impossible with ITP? And what can we do with it?

[John Wilander]

Thanks for the report, Andrey!

Please correct me if I'm wrong, but I believe you're asking for this:
A successful call to the Storage Access API should grant cookie access to all third-party requests to the requesting eTLD+1 for the current page, and not only for the iframe in which the API call was made.

We will take this into consideration and also follow Mozilla's design decisions around their functionality of the Storage Access API.

[Andrey Polischuk]

You're right. But it will help us only if services will use our forms in iframe with request the storage access. Second case I'm interested when services will use their forms to sign-in user with cors calls to our api. What we could do to allow xhr/fetch to use third-party cookies?

[Ed]

Do I understand correctly that CORS requests with credentials (which seems to be a part of standard - https://www.w3.org/TR/cors/ ) from example.com to another-example.com will NEVER work?

[John Wilander]

(In reply to Ed from comment #3)
> Do I understand correctly that CORS requests with credentials (which seems
> to be a part of standard - https://www.w3.org/TR/cors/ ) from example.com to
> another-example.com will NEVER work?

If another-example.com is third-party and has been classified as having tracking abilities, then no, cookies will be blocked. To be able to call the Storage Access API, you need your own execution context, i.e. an iframe from another-example.com. If the user grants access, it opens up for that iframe.

However, the word never is too strong. We are working with Mozilla to get the Storage Access API standardized. As part of that, access rules may change. That’s in part why feedback like this bug is important.

[Ed]

> We are working with Mozilla to get the Storage Access API standardized.
is there any way to see the progress? or even to participate?

I can describe what we want and our current data (and cookies) flow
1) we have following domains: main-example.com and example.com. They belong to the same company.
2) user logs in at main-example.com  (this sets session_cookie on main-example.com)
3) (after some time) user goes to example.com 
4) example.com makes CORS request w/credential to main-example.com gets user's info and displays it (for example it shows user's avatar). 
As you can see there are no interactions with user so we cannot use storage access api and it seems like there is no way for example.com to get user's information (except maybe for HTTP redirect which is really bad for UX and may not be possible with some sites due to architecture limits)

this way we "share" one session between all our site (we have more than 2) which achieves following
1) makes user's life easier (no need to login multiple times + you always logged in with the same user profile and therefore there is no need to always keep in mind where and how you are logged in)
2) keeps user's sessions secure: only main-example.com has access to HTTP-only session_cookie and therefore there are less places the this cookie can be compromised (compared to every site setting it's own cookies). Plus we can implement required security policies in one place.

[John Wilander]

(In reply to Ed from comment #5)
> > We are working with Mozilla to get the Storage Access API standardized.
> is there any way to see the progress? or even to participate?
> 
> I can describe what we want and our current data (and cookies) flow
> 1) we have following domains: main-example.com and example.com. They belong
> to the same company.
> 2) user logs in at main-example.com  (this sets session_cookie on
> main-example.com)
> 3) (after some time) user goes to example.com 
> 4) example.com makes CORS request w/credential to main-example.com gets
> user's info and displays it (for example it shows user's avatar). 
> As you can see there are no interactions with user so we cannot use storage
> access api and it seems like there is no way for example.com to get user's
> information (except maybe for HTTP redirect which is really bad for UX and
> may not be possible with some sites due to architecture limits)
> 
> this way we "share" one session between all our site (we have more than 2)
> which achieves following
> 1) makes user's life easier (no need to login multiple times + you always
> logged in with the same user profile and therefore there is no need to
> always keep in mind where and how you are logged in)
> 2) keeps user's sessions secure: only main-example.com has access to
> HTTP-only session_cookie and therefore there are less places the this cookie
> can be compromised (compared to every site setting it's own cookies). Plus
> we can implement required security policies in one place.

Understood. And we hear others that have similar setups. But what you’re describing is the exact same technology that’s used for cross-site tracking. Any solution we come up with has to keep the user protected in the presence of adversaries. Thus, passively allowing main-example.com access to its cookies under example.com does not work if main-example.com shows up as a third-part under multiple websites.