Commentary on assumptions in section "Federated Authentication"

[whitehatguy]

I'm hoping this issue tracker is an appropriate venue for public commentary; if not, I apologize and feel free to redirect me.

The section titled "Federated Authentication" makes this explicit assumption:

the user is expected to interact with the identity provider to login

While this holds true for social authentication systems cited in that section, this often is not true for enterprise single sign-on systems. For example, many enterprise products employ the use of Integrated Windows Authentication in such a way that the user never meaningfully interacts with the authentication system within the user agent. In many cases, having any interaction is seen as a usability dissatisfier. Expecting additional interactions for accessing a system can have create real costs and friction for users (example: a nurse moving between rooms hundreds of times a day and accessing software on a physical workstation in each room).

[bvandersloot-mozilla]

I'm hoping this issue tracker is an appropriate venue for public commentary; if not, I apologize and feel free to redirect me. You are correct :)

The spec is vague on when the deletion occurs, but I should clear up that it isn't immediate. Instead, it happens after some time which is still not set in stone (and I would like to define explicitly at some point) and is a knob we have for usability. So if a user is logging in and out multiple times per day, this protection would have no affect on the user's flow because they would log out well before this protection would clear the state. Does that help/mitigate concerns?

It may be worth calling out the tradeoff login providers are faced with explicitly in this spec: do not show a login page for interaction and have a cap on session lifetime or induce friction for endless session lifetime.

[whitehatguy]

The spec is vague on when the deletion occurs, but I should clear up that it isn't immediate. Instead, it happens after some time which is still not set in stone (and I would like to define explicitly at some point) and is a knob we have for usability

Assuming that IdP state remains intact for a period longer than the user's session, the following should then hold true:

• A. The login process itself will not be interrupted by an inability to set state (cookies, localstorage, etc.) at the identity provider.
• B. Single log-out mechanisms that rely on state to correlate remote service provider sessions present at a single device should continue to function.

Does that help/mitigate concerns?

Yes, because in the scenario I originally described only item A is a primary concern.

In an environment where the operating system itself provides the user authentication mechanism, users typically do not utilize application log-out functions (instead, they use operating system log off and lock functions.) Even if deletion of state at the IdP were to occur during the lifetime of a user's operating system session, the user would typically not be relying on single log-out as provided by the IdP and/or relying party websites/applications.

[prameshj]

Thanks for filing this issue! I want to add one more usecase - Firebase Authentication when using Federated providers on mobile (example - https://firebase.google.com/docs/auth/android/google-signin).

The typical flow would be:

1) mobile app clicks on a "login with provider" button, redirected to .firebaseapp.com. This stores some info in session storage. 2) The above page redirects to the identity provider (google.com, github.com etc) 3) IDP redirects back to .firebaseapp.com. 4) .firebaseapp.com reads session storage and processes IDP response, redirecting back to the mobile app.

The session storage read in step 4 might be affected by the bounce tracking defence, since there is no user interaction before the session storage read. Based on @bvandersloot-mozilla 's comment, the session storage entries will be present for sometime, so this flow should work. Is that correct?

@bvandersloot-mozilla is there an update on how long the entries will be accessible for? Thanks!

[Trikolon]

The way it's currently implemented in Firefox we don't clear storage immediately but rather on a scheduled job. I don;t think this would change even if we do heuristics based classification (in addition to our current detection via Disconnect list). So I assume this wouldn't break the use case you describe. I'll also let Ben chime in though.

[bvandersloot-mozilla]

@bvandersloot-mozilla is there an update on how long the entries will be accessible for? Thanks!

Last we talked on this, it was on the order of weeks. @wanderview - does that sound right?

[wanderview]

First, my understanding was that firebase was recommending the following which would largely mitigate any concern here since these solutions avoid using a cross-domain site:

https://firebase.google.com/docs/auth/web/redirect-best-practices

That being said, I don't think firebase redirect auth would be impacted by bounce tracking mitigations regardless.

In terms of the bounce tracking there are a couple of relevant timers. We are still investigating exact values, but we have some ballparks in mind.

One is how long after a bounce we could possibly consider whether the data should be deleted. This is likely on the order of a small number of hours.

Another is how long a user interaction protects from deletion. This is likely on the order of a month or more.

[wanderview]

Also, thanks for pinging me on this issue. Somehow I missed when it was originally filed.

In regards to OS authentication this seems similar to browser facilitated sign-in. For example, the user signing into their google account in chrome settings, their microsoft account in edge settings, etc. Our plan here was to treat these types of logins as an interaction as if the user had used the account management website instead of the browser settings UI.

I need to read up on Integrated Windows Authentication, but maybe this concept can be extended there.

[prameshj]

Thanks all for confirming this!

First, my understanding was that firebase was recommending the following which would largely mitigate any concern here since these solutions avoid using a cross-domain site:

https://firebase.google.com/docs/auth/web/redirect-best-practices

That being said, I don't think firebase redirect auth would be impacted by bounce tracking mitigations regardless.

In terms of the bounce tracking there are a couple of relevant timers. We are still investigating exact values, but we have some ballparks in mind.

One is how long after a bounce we could possibly consider whether the data should be deleted. This is likely on the order of a small number of hours.

Another is how long a user interaction protects from deletion. This is likely on the order of a month or more.

Thanks for the details.. You are correct about https://firebase.google.com/docs/auth/web/redirect-best-practices preventing cross-origin storage access, but that is on web applications. The bounce tracking scenario was more for mobile applications, which open a browser when a button is clicked on a mobile app. As a result, i assume the .firebaseapp.com is considered cross origin from mobile app since it did not have any domain associated with it.

The above comments in this thread clarify that this flow won't be affected. cc @sam-gc

[wanderview]

Out of curiosity, when the button is pressed in the mobile app is it sending an intent to the browser or opening the page in a webview? I'm not sure we fully understand all the app/web interactions yet.

[prameshj]

Out of curiosity, when the button is pressed in the mobile app is it sending an intent to the browser or opening the page in a webview? I'm not sure we fully understand all the app/web interactions yet.

It opens an intent to the browser/custom chrome tab.