Allow forward-declaration of storage access need

[hpsin]

Problem:

A common pattern in authentication is visiting the IDP in a first party context (authentication) and then being redirected to the relying party. The relying party then embeds iframes of the IDP to finish authentication (in the scenario where it requires multiple access tokens). It uses those iframes over the lifetime of the application running, potentially days, refreshing tokens every time they expire (usually every one hour). Example applications that are used all day: Outlook Online, Teams. This is known as the implicit flow problem, a general pattern broken by 3p cookie removal.

Applications can update to support bespoke, per-IDP protocols that trigger the storage access API, in order to fix this iframe-based auth. This introduces additional friction for the user and the developer - the user must finish signing in, be sent to the relying party, and then find and click another button within the application to "really finish" signing in.

Existing similar behaviors:

Firefox has a heuristic today that unblocks (temporarily -15 minutes) storage access if the embedded frame received interaction immediately prior to redirecting to the relying party. This heuristic allows an application to successfully complete authentication using iframes, but the app will break if they require tokens after 15 minutes. This creates an unfortunate experience for the user - their application navigates to the IDP every hour when tokens expire, disturbing their ability to use the app.

Proposal:

The IDP, today, knows if the relying party requires 3p cookie access to the IDP, and knows the redirect URI for the application. The IDP should be allowed to trigger a storage access prompt, indicating that it will need storage access while embedded on the domain of the application being signed into. As part of triggering this prompt, the IDP provides the redirect URI that it will navigate to next. After the user accepts the prompt, the IDP must navigate to the promised redirect URL. If it does not, the browser does not grant the storage access.

Note: it would be additional work and ossification to have the storage access prompt trigger the redirect. The redirect can be done via POST, JS, or 302. State tracking and redirect detection may be easier than providing an API that specifies exactly how that redirect occurs.

This allows identity ecosystems to self-repair after 3p cookie disappearance without updates to applications.

Example:
ComplexApp.example uses multiple iframes, and embeds apps that also use iframes, to authenticate with idp.example. When a user visits complexApp for the first time, they are unauthenticated. The app redirects the user to idp.example, with the following query string: ?client_id=abcd&redirect_uri=https://complexapp.example/oauth2.

The IDP authenticates the user, and immediately prior to redirecting the user to complexApp, checks the app registration for app abcd. Because abcd is registered to use the implicit flow, the IDP knows to prompt for storage access.

The IDP makes a JS call to the Storage access API: requestStorageAccessForRelyingParty("https://complexapp.example/oauth2");

The browser prompts the user, potentially using the scenario as a hint to inform the user that this is for login: Are you ok with idp.example tracking your visit to complexapp.example?

The browser does not immediately grant the storage access, but waits to see if the IDP redirects the user to the provided URL. If the IDP does, then storage access is granted. If not, then the Storage Access grant is not provided.

[johnwilander]

Thanks for filing! We must consider misuse cases that are not login flows. Could social.example make all its outgoing links request cross-site storage access under the destination site and if the user doesn't grant access, deny navigation? That would be a case of forced cross-site tracking. Could this also enable a new form of bounce tracking where protections focused on URL parameters won't work?

A minimum level of protection would be to force the flow to start on the IDP website and have them explicitly opt-in to the subsequent storage access request. At that point, couldn't the third-party request storage access there and then instead? There might be remaining challenges around per-page storage access but that's a very different challenge than allowing requests for storage access under other websites than the current one.

[hpsin]

Thanks John! That's great point about misuse, as it allows social.example to single-handedly, without coordination, create forced tracking. It'd be fairly obvious what they were doing, and I believe we use court of public opinion as a tempering vector here. Social.example would have headlines about forced tracking, presumably...
That said - perhaps shielding the result of the promise from social.example could be possible? They get to know that the user closed the prompt but not what the result was.

I don't follow the bounce tracking concern - this would seem to negate certain bounce tracking techniques - it would either

1. Allow storage access on an intermediate bounce tracker
   1. Useless, as it will not be a top level domain
   2. Very obvious (click a link to news.example, see a prompt asking if social.example can track you on tracker1.example)
2. Require immediate navigation to news.example, bypassing bounce trackers.

In your minimum requirement, did you mean that the flow would need to start at the RP website with opt-in, before redirection to the IDP? This would be acceptable I believe- minimal updates required, that an SDK could do inline, rather than novel protocols. The requirement to build new auth protocols centered around Storage Access API that require UX and timing considerations is driving the issue here.

Would you consider a Firefox-esque automatic check, that the RP initiated the redirect to the IDP, as opt-in? __

[jasonnutter]

Could social.example make all its outgoing links request cross-site storage access under the destination site and if the user doesn't grant access, deny navigation?

I'm not sure how this is different than what is possible today. In theory, a top-level application (first-party.com) could embed an experience (third-party.com) that requires storage access (e.g. 3p cookies), and the two could use frame messaging to communicate, such that first-party.com doesn't let the user proceed until they have granted storage access to third-party.com using the existing Storage Access API mechanics (document.requestStorageAccess being invoked from third-party.com iframe inside first-party.com).

[hpsin]

@jasonnutter that would require coordination between the two parties. The concern here is that social.example could block navigation through the web ecosystem on their own, without consent from news.example. Considering the number of sites very publicly opting out of FLoC, I expect the same desire to be present here.

[jasonnutter]

@hpsin Sure, but would we consider that O(n+1) or O(n^2), in terms of complexity? Needing those two parties to coordinate is not difficult, especially considering scenarios where an SDK from third-party.com is being used on first-party.com.

[johnwilander]

Thanks John! That's great point about misuse, as it allows social.example to single-handedly, without coordination, create forced tracking. It'd be fairly obvious what they were doing, and I believe we use court of public opinion as a tempering vector here. Social.example would have headlines about forced tracking, presumably...

There are many places in the world where we as browser vendors don't hear about the headlines, users don't know that a viable path is to go to media, users don't have a viable path to go to media, or users don't understand that they have a choice at all. The starting point for the web is "safe to roam" and that's what we need to maintain.

That said - perhaps shielding the result of the promise from social.example could be possible? They get to know that the user closed the prompt but not what the result was.

A similar misuse case happening in the wild and a similar discussion on remedies can be found here: #60

I don't follow the bounce tracking concern - this would seem to negate certain bounce tracking techniques - it would either

1. Allow storage access on an intermediate bounce tracker

   1. Useless, as it will not be a top level domain
   2. Very obvious (click a link to news.example, see a prompt asking if social.example can track you on tracker1.example)

2. Require immediate navigation to news.example, bypassing bounce trackers.

Bounce tracking typically relies on link decoration or HTTP headers to transfer tracking information across websites. Browsers have an ability to step in and filter those things out. Being able to request storage access for SiteB under SiteA, while on SiteB, can make the subsequent navigation be tracking-free.

In your minimum requirement, did you mean that the flow would need to start at the RP website with opt-in, before redirection to the IDP? This would be acceptable I believe- minimal updates required, that an SDK could do inline, rather than novel protocols. The requirement to build new auth protocols centered around Storage Access API that require UX and timing considerations is driving the issue here.

Would you consider a Firefox-esque automatic check, that the RP initiated the redirect to the IDP, as opt-in? __

We typically don't discuss browser specific things here unless it's an active spec interop issue. Mozilla has chosen some specific compatibility measures. I don't know if they plan to keep them. WebKit has its popup compatibility measure which we have clearly said is going away. Apart from that, WebKit has not expressed a desire to add further, general compatibility measures.

This is starting to sound much more like our IsLoggedIn proposal for federated logins: privacycg/is-logged-in#35. I do realize that you are talking about SSO, not federated logins, but that kind of a managed flow is what I'm after here. RP initiates, IDP authenticates+issues any tokens, RP confirms. If that was a flow managed by dedicated web APIs, we could look at making storage access smoother.

[johnwilander]

@hpsin Sure, but would we consider that O(n+1) or O(n^2), in terms of complexity? Needing those two parties to coordinate is not difficult, especially considering scenarios where an SDK from third-party.com is being used on first-party.com.

1. The destination website may not want to coordinate. You may own a website that merely embeds an image from social.example and you never engage in any cross-site tracking. If social.example came and asked for coordination on tracking, you'd say no. You as a site owner would lose control of that if social.example could just do it themselves and force tracking on users who want to be able to follow a link to your website.
2. Even if something bad is possible today, we don't want to make it easier or "standardized." The direction we are moving in is less tracking, more user control, and more transparency.

[jasonnutter]

@johnwilander

The destination website may not want to coordinate. You may own a website that merely embeds an image from social.example and you never engage in any cross-site tracking. If social.example came and asked for coordination on tracking, you'd say no. You as a site owner would lose control of that if social.example could just do it themselves and force tracking on users who want to be able to follow a link to your website.

Fair points. What if this flow required explicit signal from both parties? For example, in addition to document.requestStorageAccessForRelyingParty() mentioned above, there could be another new API , let's call it document.enableStorageAccessForThirdParty(), which would be invoked by the relying party before redirecting to the IDP, which would be a requirement before invoking document.requestStorageAccessForRelyingParty.

Example:

1. contoso.com wants to sign into idp.com, and knows it will need to potentially prompt the user for Storage Access for idp.com.
2. Before redirecting to idp.com, contoso.com invokes document.enableStorageAccessForThirdParty('idp.com'). This is a void method that sets a bit in the browser, which will be checked downstream in step 4.
3. User is then redirected to idp.com, where they complete auth challenges.
4. At the end of the auth challenges, idp.com invokes document.requestStorageAccessForRelyingParty('contoso.com'). This API throws unless it is done as a direct result of user interaction and the origin provided has made the corresponding document.enableStorageAccessForThirdParty call from step 2.
5. These conditions are met, and the user is (potentially) presented with a prompt. Accepting the prompt grants storage access for idp.com as if it was done from an iframe on contoso.com.
6. idp.com receives a hanging/resolved/reject promise if the user declines, per Make implicit deny and explicit deny indistinguishable #60.
7. User is redirected back to consotos.com, and is able to load iframes for idp.com that have access to the cookies set in first-party context.

One idea for preventing abuse when a user rejects would be that document.requestStorageAccessForRelyingParty() doesn't prompt the user until a redirect to the relying party is initiated, at which point the browser intercepts the request and injects the prompt, and regardless of the result, redirects the user. This gives the IDP the chance to provide context and set expectations with the user, but not the ability to prevent redirection if the user declines.

[samuelgoto]

FWIW, to +1 a comment by @johnwilander, this has been chrome's position so far:

If that was a flow managed by dedicated web APIs, we could look at making storage access smoother.

In WebID's formulation, once the browser observes a login (e.g. via mediation or a permission prompt) the browser allows two APIs to be called:

• navigator.credentials.logout() (called from the IDP embedding RPs with cookies) and
• navigator.credentials.refreshToken() (called from the RP embedding the IDP with cookies)

(API names largely TBD, but just to give you a sense of how we are approaching this problem)

So, to us, a lot of these problems (e.g. this one too) get a lot easier if the browser is able to observe a login, so most of our focus has been on finding ways to do that (and, like it was mentioned, the hard part is abuse).

[johannhof]

Thank you for the proposal and the great discussion so far! I think this is a good approach to a real-world problem that SAA doesn't do very well at the moment. I'm trying to be careful with my initial optimism to leave time and space to consider possible abuse and other downsides of this proposal. I think John already identified two(?) valid concerns:

1. The API could allow for abuse by an "IDP" that consent-gates its outgoing links
2. By intention this proposal is targeted at a very specific use case (authentication) but its design does not make any restrictions to allow browsers to validate/observe that it's being used for authentication. Should this be part of SAA?

For 1), I think that the flow outlined in #83 (comment) should solve this, and it makes sense to require participation from both parties. I'd say we need to put some further thought into when exactly the user should be prompted in this scenario. Generally the only suitable async call happens when the IDP calls requestStorageAccessForRelyingParty, but I can understand that we'd prefer to ensure a redirect actually happens before granting storage access.

For 2), Firefox already uses these heuristics (redirect/popups) in practice to deduce when authentication is happening. We would be happy to get rid of them eventually, but right now they're unavoidable. This proposal looks like it would be formalizing our heuristics into a web API, which will give us and our users more control over what's happening. It could ultimately reduce the number of sites we'd have to expose our heuristics to and give websites clear expectations and control over when storage access is granted.

This could also be solved by WebID, and the WebID flow is probably preferable in many cases. However, as we've said before, we're skeptical whether WebID will cover all use cases of SAA and also whether all providers will be able to adopt WebID or other types of browser-controlled auth flows. There are a lot of open questions that don't arise with generic access to cross-site cookies via user consent. As such, we want to work on evolving SAA to make it a pragmatic solution that can serve web developers today and in the future.

I think this approach is a step forward in that direction and if we can ensure participation from both sites and the ability for browsers to ask for user consent it doesn't seem to push the privacy boundaries of what is possible using iframes already, just makes the API more ergonomic to use. Again, I want to make sure we carefully consider this aspect.

[hpsin]

Hey folks,

Thanks for the great discussions offline and at the CG. Recapping, we believe we've found two complementary ways of building this:

1. Use the First Party Sets list to indicate a site is allowed to request access in a first party context, for another site in the set.
2. For sites not in a FPS together, require RP1 to explicitly declare that IDP1 can request storage access, prior to navigating to IDP1.

If two sites are in an FPS together, either one is allowed to request Storage Access directly. There's an implicit trust between them, so worries about maliciously blocking navigations between them should be reduced. Thus - IDP1 can call async requestStorageAccessForRelyingParty("rp1.example") from a first party context, without rp1.example previously indicating it is allowed.

For sites not in a FPS, rp1.example must call sync allowStorageAccessRequestForThirdParty("idp.example") prior to navigating to idp.example. This action tells the browser that the RP agrees with the prompt being shown.

Open questions still

1. What does resolution of the requestStorageAccessForRelyingParty Promise look like when the IDP is allowed to request access? I believe we can make it unblinded (return a reliable yes/no signal) since consent between the RP and IDP has been granted.
2. What does resolution of the requestStorageAccessForRelyingParty Promise look like when the IDP is not allowed to request access? Make implicit deny and explicit deny indistinguishable #60 likely directs this discussion.
3. When should the async storage request prompt be shown? On navigation to rp1.example, or immediately? I lean towards immediately, to make it possible to react to failure (e.g. tell the user they app might not work).
4. How long does the preauthorization from rp1.example to idp.example last? I'd like this to be time based, not "number of navigations" based. We can't guarantee that rp1.example will actually redirect to idp.example and remain there, in case idp.example uses a subsequent federated auth (extremely common for enterprise scenarios).

Other questions we should track? Naming and shape of API TBD of course.

[johannhof]

Hi @hpsin, sorry for the delay here while I figured out our stance on this idea. From Mozilla side we're supportive of this idea overall (sans the FPS pieces, as FPS still seems to need to reach some consensus) and would be interested to get additional implementer support from WebKit/Blink folks.

Your suggestions for the "open questions" mostly make sense to me. This is up to the browser, but I think we'd customize our prompt to make it clear to the user that they will be redirected to the other site soon. So regarding 4), there's a bit of a breakage risk when the forward doesn't happen quickly enough if we make this time-based. It's a bit weird but I wonder if we should force a redirect to a specific URL after the promise was handled...