1782772 - Create a universal Firebase sign-in shim

Status: RESOLVED FIXED

(Core :: Privacy: Anti-Tracking, enhancement)

Description

[Paul Zühlcke [:pbz]]

As per Bug 1780615 the "SignInWithRedirect" flow is not working with dFPI enabled.
This bug is for creating a shim that fixes the login-flow universally for all sites by requesting storage access on behalf of the site.

Comment 1

[Paul Zühlcke [:pbz]]

Attachment: Bug 1782772 - Add a shim for Firebase signInViaRedirect breakage. r=#anti-tracking!

Comment 2

[pavithrar]

Thanks for creating this! The URL requesting storage access will be of the form - "https://<project>.firebaseapp.com/__/auth/iframe?..."

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e0dfeeb6f3d9
Add a shim for Firebase signInViaRedirect breakage. r=anti-tracking-reviewers,webcompat-reviewers,bvandersloot,twisniewski

Comment 4

[Paul Zühlcke [:pbz]]

(In reply to pavithrar from comment #2)

Thanks for creating this! The URL requesting storage access will be of the form - "https://<project>.firebaseapp.com/__/auth/iframe?..."

Thanks! The shim will request storage access for any *.firebaseapp.com frame that matches the redirect. We detect the redirect with this pattern:

"*://*.firebaseapp.com/*/auth/*signInViaRedirect*"

Are there any other domains used by Firebase customers we should take into account that could be used for the redirect login flow?

Comment 5

[pavithrar]

Hi Paul,

The initial redirect request will match your regex - "://.firebaseapp.com/*/auth/signInViaRedirect"
For example - https://<project>.firebaseapp.com/__/auth/handler?apiKey=abc&appName=xyz&authType=signInViaRedirect

However, the URL that requests iframe access will not match the above regex, it will be of the form:

"https://<project>.firebaseapp.com/__/auth/iframe?apiKey=abc..."

The console warning I see when performing signInWithRedirect with TotalCookieProtection enabled looks like:

Partitioned cookie or storage access was provided to “https://<project>.firebaseapp.com/__/auth/iframe?<redacted>” because it is loaded in the third-party context and dynamic state partitioning is enabled.

So I think the regex should be like - "://.firebaseapp.com//auth/iframe"

We use this iframe for the redirect sign in flow only.

There are no other domains to allowlist.

Comment 6

[Paul Zühlcke [:pbz]]

Thanks for confirming!
The exact URL of the iframe is not relevant, since the storage access call is only concerned with the site. e.g. https://example.firebaseapp.com. This site is derived from the redirect target (of the initial redirect).
We've tested the shim with 3 different sites using the signInViaRedirect flow and it fixes the issue.

Comment 7

[pavithrar]

Sorry, the regex in my previous comment got modified due to formatting.

I meant that the initial redirect will match your regex of

"*://*.firebaseapp.com/*/auth/*signInViaRedirect*"

But the domain accessing the web storage will not match it.

The regex should be something like:

"*://*.firebaseapp.com/*/auth/iframe*"

Comment 8

[pavithrar]

Thanks for the info, Paul! Couple of questions:

The exact URL of the iframe is not relevant, since the storage access call is only concerned with the site. e.g. https://example.firebaseapp.com. This site is derived from the redirect target (of the initial redirect).

1. I am curious how this works - we first do https://<project>.firebaseapp.com/__/auth/handler?apiKey=abc&appName=xyz&authType=signInViaRedirect which redirects to an identity provider's login portal (like accounts.google.com), and then
   redirects back to https://<project>.firebaseapp.com/__/auth/handler (no signInViaRedirect in this URL). The https://<project>.firebaseapp.com/__/auth/iframe is opened here.

   Does the shim have the context of the original URL which had "authType=signInViaRedirect" ?

2. Thanks for testing this! I assume the login failed with Total Cookie Protection without the shim and passed with it. Would you be able to confirm that the app URL was in a different domain than "https://<project>.firebaseapp.com", so that the storage access in the iframe is cross-origin?

3. Do we need a Firefox update to test this on our end? I deploy my app on localhost, which makes the iframe(https://<project>.firebaseapp.com/__/auth/iframe) cross-origin. I still see the error message about cross-origin storage access.

Thanks again for your help on this!

Comment 9

[Paul Zühlcke [:pbz]]

(In reply to pavithrar from comment #8)

Thanks for the info, Paul! Couple of questions:

The exact URL of the iframe is not relevant, since the storage access call is only concerned with the site. e.g. https://example.firebaseapp.com. This site is derived from the redirect target (of the initial redirect).

1. I am curious how this works - we first do https://<project>.firebaseapp.com/__/auth/handler?apiKey=abc&appName=xyz&authType=signInViaRedirect which redirects to an identity provider's login portal (like accounts.google.com), and then
   redirects back to https://<project>.firebaseapp.com/__/auth/handler (no signInViaRedirect in this URL). The https://<project>.firebaseapp.com/__/auth/iframe is opened here.

   Does the shim have the context of the original URL which had "authType=signInViaRedirect" ?

The shim works as follows given a page "example.com" and "example.firebaseapp.com":

1. Listen for redirects to *://*.firebaseapp.com/*/auth/*signInViaRedirect*. If the destination of the redirect matches this pattern, pause the redirect
2. While still on https://example.com request storage access for https://example.firebaseapp.com under https://example.com. This usually auto-grants after a short delay, but may in some cases trigger a storage access prompt asking the user whether they want to allow storage access.
3. Once the storage access is granted, resume the redirect.
4. Once the redirect flow completes and example.firebaseapp.com redirects back to example.com the embedded iframe has first-party storage access under example.com from the storage access granted in step 2.

2. Thanks for testing this! I assume the login failed with Total Cookie Protection without the shim and passed with it. Would you be able to confirm that the app URL was in a different domain than "https://<project>.firebaseapp.com", so that the storage access in the iframe is cross-origin?

We've tested this for Bug 1779490, Bug 1742553, Bug 1660446 which are all sites using the signInWithRedirect auth flow and the *.firebaseapp.com domain which is cross-origin in that context.

3. Do we need a Firefox update to test this on our end? I deploy my app on localhost, which makes the iframe(https://<project>.firebaseapp.com/__/auth/iframe) cross-origin. I still see the error message about cross-origin storage access.

The shim is currently landing (going through our CI pipeline). Once landed it will be available in Firefox Nightly for testing. You can download Nightly here: https://www.mozilla.org/en-US/firefox/channel/desktop/. Nightlies are built two times a day so there might be a bit of delay until it's in there.
If there are no issues the shim will reach Firefox release users in version 105.

Comment 10

[pavithrar]

Thanks for the explanation, Paul! That sounds perfect, looking forward to trying this out.

I will try this out on Nightly tomorrow.

Comment 11

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/e0dfeeb6f3d9

Comment 12

[pavithrar]

Thanks Paul and Sandor! I was able to verify that this works in the nightly version. Is there an ETA for version 105 release? Thanks again for addressing this!

Comment 13

[Paul Zühlcke [:pbz]]

(In reply to pavithrar from comment #12)

Thanks Paul and Sandor! I was able to verify that this works in the nightly version. Is there an ETA for version 105 release? Thanks again for addressing this!

Thanks for verifying! Glad it's working.
The scheduled release day for Firefox 105 is September 20. (From https://fx-trains.herokuapp.com/release/?version=105)