I don't think this is quite correct. Per this table the referrer would not be sent on the manifest (fedcm.json) https://github.com/fedidcg/FedCM/blob/main/explainer.md#endpoint-properties

The step 3 above isn't correct, but isn't easy to determine from the spec at the moment. We should update the fedcm.json section to specify it is queried without referer or client_id. The fedcm.json file should not be associated to an RP.

We did clarify this in the explainer as @npm1 but it hasn't been backported to the spec yet.

That's quite an interesting attack @bvandersloot-mozilla , thanks for pointing it out!

While I agree with @npm1 and @dj2 that the specific attack you suggested is not viable (we need to fix the spec, PR on the way), I think that we should use this as an opportunity to find attacks that are akin to it.

For example, I think the the following attack is one that we wouldn't be able to mitigate right now:

const cred = await navigator.credentials.get({
  federated: {
    providers: [{
      url: `https://idp.example/${window.location.href}`
    }]
  }
});
// The following will fetch the manifest JSON file, which will know the origin of the RP :(
const {idToken} = cred.login(); 

Thanks for the info @dj2 and @npm1. Good to see this doesn't get through as diagrammed.

@samuelgoto : That is a good catch. This is related to #231. Both are something like link decoration of the IDP API endpoints.

As you said, there are two attack vectors here:

• link decoration and
• timing attacks

On link decoration, specifically, I'm wondering if something along the lines of an API that IDPs are required to "declare themselves as IDPs" in a moment that happens before any RPs can use them (and, hence, has to be RP-agnostic) would help. For example:

// This gets used across all RPs:
// Has to be called while the user is on idp.example:
FederatedCredential.registerIDP("https://idp.example");

HTML tags would also be an isomorphic formulation:

<meta name="fedcm-manifest" data-url="https://idp.example">

WDYT?

I agree that there are two vectors here, and I think that link decoration is the more concerning one. Timing attacks are definitely the more challenging vector to prevent. Until people begin to talk about removing third-party requests, I'm happy to punt on those :)

I think some pre-declaration of the API is a really useful tool. I worry about frequent or just-in-time uses of FederatedCredential.registerIDP("https://idp.example/${nonce}/"). For example, an IDP could define a "Log in with another account" button that causes a popup that calls the function then proceeds with the API, disclosing the user cookie. Could this API be restricted from call-to-use or call-to-call?

Another option is to have the account check occur after a user consent is gathered. This would require new structure in the browser because right now the only way to get the account state is to go through the IDP API. This would bind some permission to the RP and IDP pair that permits these requests. This starts to feel a little Storage Access API-like, but hopefully I've conveyed the picture. I think I prefer pre-declaration of the API endpoint though.

The downside of having account checks after user consent is that it would require two dialogs (first consent, then account chooser), which is a much worse UX. It would be much better if we could find a viable way that did not require that.

Without having though this through in depth - why not simply disallow path / fragments / query parts for the IDP URL? The only downside I see is that you can't run multiple IDPs on the same eTLD+1, but that might be an issue for some scenarios.

We had something like this originally where the URL was the IDP origin and the manifest was at .well-known/fedcm.json. We heard from some IDPs that this had issues for their setup and were requested to take the path into account for the IDP. So we switched to the current model which is a path provided by the RP and fedcm.json lives at that path.

We had something like this originally where the URL was the IDP origin and the manifest was at .well-known/fedcm.json. We hard from some IDPs that this had issues for their setup and were requested to take the path into account for the IDP. So we switched to the current model which is a path provided by the RP and fedcm.json lives at that path.

@dj2: Is there a thread or minutes for this? I'd like to know a little more about the use case and if there is a way to handle it less generally.

To make something explicit: an IDP could still smuggle the RDP in on the subdomain unless we restrict the path to only the eTLD+1 and well known URL as @asr-enid implied.

@dj2: Is there a thread or minutes for this? I'd like to know a little more about the use case and if there is a way to handle it less generally.

Here:

#160 (comment)

Looking at Tim's comment in that thread it looks similar to exactly the use case we fear: a unique endpoint per RP. I'm not that familiar with Azure AD and how it molds into FedCM. Would the intent be to run one IDP per tenant? A counterproposal could be for the RP to embed the tenant explicitly into the client ID, e.g. example-user@exampleAccount.com^exampleTenant.com. This would be post-consent so I wouldn't see an issue with sharing at that point.

For most consumer use cases, we'd expect a very small number(N) of IDPs per eTLD+1. While having the manifest under root (N=1) is not very extensible, @samuelgoto came up with an alternative proposal that tries to address this issue via an extra layer of indirection.

RP side

The RP API remains the same:

navigator.credentials.get({
  federated: {
    providers: [{
      "url": "https://foo.idp.example/sub",
      "clientId": "1234"
    }]
  }
});

IDP side

Unchanged

The IDP has the same manifest in https://foo.idp.example/sub/fedcm.json as they do today

{
  "accounts_endpoint": "/accounts.php",
  "client_metadata_endpoint": "/client_metadata.php",
  "id_token_endpoint": "/id_token.php",
  "revocation_endpoint": "revocation.php"
}

Changed

In addition, in this formulation, the IDP adds (a one time cost) an extra .well-known file under the root of eTLD+1 (https://idp.example/.well-known/fedcm.json) and point to the plausible IDP manifests:

{
  "provider_urls": ["https://foo.idp.example/sub/", "https://bar.idp.example/"]
}

The idea here is that a browser can check that the list of IDPs in the global .well-known file is sufficiently small to represent IDPs (say, a handful per company) but not RPs (say, thousands).

The proposal is to start with N=1, and make this larger as we learn that companies have more than 1 IDP.

Notes

• With N=1, this proposal resolves the manifest attack problem.
• The extra network request to the IDP does not come at an additional latency cost because we could
  • fetch the global and the local manifest in parallel and only proceed with the credentialed fetch when the urls from both responses match
  • cache the two manifests (by N days specified by IDP during fetch)

Caveat: we propose to start with N = 1 (and incrementally make it larger as needed) because when N becomes large it adds extra entropy that could be abused. We believe N would be able to handle most use cases and that, even if we need a larger N, the abuse would be publicly observable.

@bvandersloot-mozilla above is another thought that occurred to us as an alternative to the registration alternative we described here.

The advantage of this approach is that it: (a) it only requires a one-time configuration cost to add the global .well-known file while (b) fetching the .well-known file dynamically rather than registering it.

We think the alternative would be hard because it could get easily out of sync (race conditions, e.g. do we fail if we don't see anything registered before hand?) or attacked (e.g. can the RP collude with the IDP to make the IDP "register" moments before we use it? and if so, would we have to impose some sort of "old enough" criteria?).

WDYT?

• Do we know of IDPs that have more than one set of routes at a given etld+1?
• Do we expect these routes to really change often enough that this would be an issue? They seem like they'll be pretty long lived URLs so modifying the root file would be a pretty rare event.

With N=1 the above is a more complicated version of just having the fedcm.json file at the <etld+1>/.well-known/fedcm.json, is there a known benefit to the complication?

With N=1 the above is a more complicated version of just having the fedcm.json file at the <etld+1>/.well-known/fedcm.json, is there a known benefit to the complication?

The observation that lead to the indirection was that we have heard repeatedly that the teams/servers/codebases/release schedules responsible for running IDPs aren't the same teams/servers/codebases/release schedules responsible for running the etld+1. So, the indirection allows the IDP to move autonomously (e.g. change the configuration), while still being vouched by the etld+1 (which, I expect, needs to happen only one time).

FWIW, not having the indirection is a perfectly valid solution to me too (wearing a browser's hat), so they aren't mutually exclusive to me. I'm pretty confident we (wearing an IDP's hat) need the level of indirection, and once the browser has to pay that price, I don't know if not having the indirection buys you much, but nevertheless, they aren't mutually exclusive.

My overall argument was more one of a concern over runtime registration, rather than approaches that try to limit the entropy in the .well-known, so I don't feel particularly strongly about the indirection (it just codifies something that we had heard before).

Does that make sense?

@samuelgoto

I think I have two points to follow up on here:

1. Given the diversity of the web and microsoftonline.com's multi-tenancy use case, I don't think there is an N that makes sense here. Presumably for microsoftonline.com to work with this, N would have to be as large as the number of Azure AD tenants in existence and be updated every time someone registers a new tenant? I don't know the exact number here, but I registered a tenant for a side project in the last year to enable "Sign in with Microsoft" on a domain I owned. So I assume N would have to be large if I could have already increased it personally.
2. I don't think that moving from a Javascript registration of the manifest .well-known location (FederatedCredential.registerIDP("https://idp.example");) to the scheme @yi-gu describes here completely solves the attack we are worried about. The Client-side Javascript of the IDP could notify the server immediately before it creates a credential that a request is coming with a particular provider URL. This would probably rely on fingerprinting though, so I suppose that is an improvement.

@bvandersloot-mozilla could you elaborate on your attack in 2) a little bit? How would fingerprinting work?

One thing we're already aware of is this: since FedCM makes a client metadata request (with client ID & referrer) at about the same time as the account list request (with credentials), the server could try to correlate the two requests based on time and IP address and therefore know that a user was visiting the site even when they decline login. Is the attack you're thinking of more or less the same as this one?

@bvandersloot-mozilla could you elaborate on your attack in 2) a little bit? How would fingerprinting work?

One thing we're already aware of is this: since FedCM makes a client metadata request (with client ID & referrer) at about the same time as the account list request (with credentials), the server could try to correlate the two requests based on time and IP address and therefore know that a user was visiting the site even when they decline login. Is the attack you're thinking of more or less the same as this one?

Almost identical! It is a very similar attack, but a little different mechanism. I was thinking of RP Javascript just sending the URI over to the IDP with the Fetch API immediately before creating a credential with the IDP. I just didn't see where in the spec the Metadata endpoint was ever hit, so I didn't want to rely on that.

While fingerprinting is hard to solve entirely, we can try to reduce its feasibility and precision. But having a same-moment pair of requests from the same client containing the information we don't want correlated can lead to a very confident link.

Hmm the spec does seem unclear when the client metadata endpoint gets called. The idea is that it is fetched after the manifest, either concurrently or in sequence with the account list endpoint.

The attack is not 100% precise since the server only has the IP address and time to correlate, but yeah, we are aware that this is something we need to solve.

This seems fundamental to a one-click account chooser. Would it be UX breaking to put a IDP provider chooser before the account chooser?

This seems fundamental to a one-click account chooser.

One option to fix this that we are exploring is what we've been calling the "push model". In short, in the push model, the IDPs would push the accounts to the browser ahead of time, rather than be pulled dynamically. We think that pushing (as opposed to pulling) would mitigate all of these fingerprinting/timing problems.

Because we are expecting the push model to be super complex/involved, we are also trying to understand how important are these timing attacks, compared to other options an attacker would have (e.g. IP, other fingerprinting surface and bounce tracking).

Any thoughts on whether the "push model" would work?

Would it be UX breaking to put a IDP provider chooser before the account chooser?

Yeah, that could work, but would lead to awkward UX. One of the questions that occurred to us is whether the "IDP chooser" should be in the content area (e.g. only allow the API to be called behind a user gesture) or the browser UI.

Any thoughts on whether the "push model" would work?

My vision, based on my own priors and what you've said of the push model:

1. User logs into the IDP as a first party.
2. IDP calls a browser API to set up the account at the IDP in the browser.
3. Some time later the user presses an RP button that says Log In With X which calls a browser API.
4. The browser searches through its list of accounts that match all X the RP supports
5. The browser presents an account chooser to the user, and includes a link that navigates to the login page of each IDP with no accounts found.
6. User selects an IDP, Auth proceeds using storage, user is logged in.
7. Success

This does incur browser state for each user IDP account. These are rendered legible to the browser, and is more complicated in the browser. However I would be optimistic about the push model from a privacy perspective. There is no communication with the IDP between when top-level authentication is finished and when the user selects them for a given RP.

Yeah, that could work, but would lead to awkward UX. One of the questions that occurred to us is whether the "IDP chooser" should be in the content area (e.g. only allow the API to be called behind a user gesture) or the browser UI.

My first instinct is to make the IDP chooser in the browser UI, and if you are concerned about too much browser UI you could allow the RP to manage account choice in the content area . The user-RP privacy is at risk when an IDP is contacted, so I'd prefer to have that be gated by a browser-user interaction.

we are also trying to understand how important are these timing attacks, compared to other options an attacker would have (e.g. IP, other fingerprinting surface and bounce tracking).

w.r.t. IP and other fingerprinting: those are noisy mechanisms that, with work, may be brought back to k-anonymous for useful values of k. The attack here leaks a k=1 identifier (cookie) under reasonable conditions (one login per IP per O(RTT)). As solutions are used to make IP fingerprinting less practical, the privacy gains against all IP fingerprinting would be constrained by this attack because of how it allows precise timing to be added to the mechanism.

My vision, based on my own priors and what you've said of the push model:
...
This does incur browser state for each user IDP account. These are rendered legible to the browser, and is more complicated in the browser. However I would be optimistic about the push model from a privacy perspective. There is no communication with the IDP between when top-level authentication is finished and when the user selects them for a given RP.

Yeah, that sequence of steps matches more or less what I had in mind too, and the privacy/security trade-offs. It is substantially more complicated (for IDPs), so we've avoided it at first.

It seems like we are in agreement that The Push Model would sufficiently mitigate the timing attack problem. Ack?

My first instinct is to make the IDP chooser in the browser UI, and if you are concerned about too much browser UI you could allow the RP to manage account choice in the content area . The user-RP privacy is at risk when an IDP is contacted, so I'd prefer to have that be gated by a browser-user interaction.

Do you think that gating behind user gesture is a sufficient mitigation? That is, if we kept the "pull model" but gated it behind a browser-user interaction, do you think that would decrease the attack surface enough to mitigate it?

I didn't think that it would be that much harder for IDPs. Is there a place I can read where the difficulty arises?

It seems like we are in agreement that The Push Model would sufficiently mitigate the timing attack problem. Ack?
ACK

Do you think that gating behind user gesture is a sufficient mitigation? That is, if we kept the "pull model" but gated it behind a browser-user interaction, do you think that would decrease the attack surface enough to mitigate it?

It depends on what you mean by user gesture. If you mean a Browser UI that indicates the particular IDPs, then I think it would. If you mean user activation, then I don't think so.

I assume the browser owner is aware of any logins I perform

This is concerning.

To clarify, I'm not saying this is happening. Rather, that it is possible.

Yeah, agreed, more specifically, IDPs. While unfortunate and something we want to minimize as much as we possibly can, that's a deliberate trade-off (e.g. when we run out of ideas of ways that the browser make things backwards compatible, the next line of change goes towards IDPs - followed by RPs and users).

I understand the intent but I'm not sure it's true. As we've seen in other issues, there are many additional use cases that FedCM will need to support. As those use cases get added I highly suspect the impact to RPs will go up. There is also much intrenched deployed code that isn't in active development. Since RPs have to change (even if hopefully minimally) fixing that code can be quite challenging and take some time to figure out. We need to be careful to no underestimate the amount of work required to move to FedCM.

Just want to note that we addressed the deterministic attacks resulting from the filing of this issue by having a two-tier manifest. We still have the non-deterministic timing attack issue from the credentialed fetch ie #231

For those of you following this thread, I just wanted to report back on the progress that @bvandersloot-mozilla and @cbiesinger have been making.

Here are a few presentations that we have used to discuss options:

• Jun 2022
• Aug 2022

I think we are arriving at some convergence, which we expect to close at TPAC in person.

Just to write down here what we seem to be converging on, it is a variation of what @bvandersloot-mozilla proposed earlier:

My vision, based on my own priors and what you've said of the push model:

1. User logs into the IDP as a first party.
2. IDP calls a browser API to set up the account at the IDP in the browser.
3. Some time later the user presses an RP button that says Log In With X which calls a browser API.
4. The browser searches through its list of accounts that match all X the RP supports
5. The browser presents an account chooser to the user, and includes a link that navigates to the login page of each IDP with no accounts found.
6. User selects an IDP, Auth proceeds using storage, user is logged in.
7. Success

To support step (2),

IDP calls a browser API to set up the account at the IDP in the browser.

the proposal is to expose a browser API that allows IdPs to tell the browser that the user is logged in (with no UX prompt, a silent store). We've been calling this the "IdP Sign-in Status API", because, well, it is an API that allows IdPs to signal its user's sign-in status. Syntax largely TBD, but, based on what we heard from IdPs, we think it is likely useful to have a HTTP Header API (for IdPs that use a lot of 302s to log the user in and out) and/or a JS API (for IdPs that actually load content/script to log users in).

Here is an example of what that could look like:

IdP-Sign-In-Status: action=login
IdP-Sign-In-Status: action=logout

And in JS:

// logs the user in
IdentityProvider.login();

// logs the user out
IdentityProvider.logout();

Every IdP can be in one of three states: undefined (default), signed-in or signed-out and it can use the IdP Sign-in Status API to move between these states. The undefined state is introduced to allow us to bootstrap before the API exists.

To support step (4),

The browser searches through its list of accounts that match all X the RP supports

the browser then reads its local storage to determine if the user is logged in to the IdP or not.

1. If the IdP's Sign-in Status is undefined
   1. The IdP Sign-in Status API was never called before so
   2. We fetch the accounts list (incurring in a one-time-per-idp timing attack) and
   3. Set the IdP's Sign-in Status.
2. If the Sign-in Status is signed-out
   1. We resolve the JS promise immediately: nothing to be done, no timing attack to be paid.
3. If the Sign-in Status is signed-in
   1. We fetch the accounts list
   2. If we don't have accounts (e.g. session was invalidated server-side)
      1. we show a "login to IdP UI" and then
   3. We proceed with step (5).

The browser presents an account chooser to the user

This variation doesn't fully prevent the timing attack problem (e.g. step (5) can still incur in a timing attack), but it allows the API to guarantee that UX will always be shown regardless of the case, which substantially limits how it can be abused (e.g. invisibly) by trackers.

Importantly, we think this is likely a strict pre-requisite for more privacy preserving options (e.g. using a Web Push API to also cache the user's account metadata) and strikes the right balance between deployment feasibility and privacy protection.

This is somewhat related to the Login Status API, but I think it is not quite the same (at a minimum, it is a strict subset).
Here is where we are trying to understand the relationship between the two.

If we don't have accounts (e.g. session was invalidated server-side)
we show a "login to IdP UI" and then

Am I right that this assumes that an IDP Sign-In UX would be mandatory here (in case a session expired for example), i.e. could not be controlled by the RP but only a users choice to proceed or not? This seems to be the case - see discussion around "silent" parameters in classical flows (prompt=none).

How would one deal with Multi-IDP Scenarios here?

• IDP Sign-In in case NONE has a valid active session, if so which (priorized list)
• Offer Sign-In to RP directly (if there is at least one signed in account) + sign-in with other supported IDPs (for which no sessions are present...)

Reading through the updated slide deck it seems this step is meant to not occur with real IDPs albeit edge cases like network errors. It might also happen in case the session is timing out though, in which case the IDP will might not have been able to signal a logout via the API which is also mentioned in the deck

Am I right that this assumes that an IDP Sign-In UX would be mandatory here (in case a session expired for example), i.e. could not be controlled by the RP but only a users choice to proceed or not?

Yes you are right. The essence of this proposal is to prevent "silent tracking". i.e. whenever a timing attack could happen, we show some UI to users (except for the one-time-per-IdP silent tracking). Given that the API is likely called by the IdP, exposing some control to the RP could actually pass it to the IdP or trackers.

How would one deal with Multi-IDP Scenarios here?

• IDP Sign-In in case NONE has a valid active session, if so which (priorized list)

If a user has no active session with any of the IdPs, it's up to the RP to specify the order of IdPs. We are still working on UX details such as whether previous session should count w.r.t. the order. e.g. a user has signed in with one IdP in the past and signed out before the API is called. Suggestions are welcome!

• Offer Sign-In to RP directly (if there is at least one signed in account) + sign-in with other supported IDPs (for which no sessions are present...)

This matches our intuition as well. Again, we are still in early UI design stage so suggestions are welcome :)

Reading through the updated slide deck it seems this step is meant to not occur with real IDPs albeit edge cases like network errors. It might also happen in case the session is timing out though, in which case the IDP will might not have been able to signal a logout via the API which is also mentioned in the deck

Any insight into how often the session would time out without having an ability to call logout() would be useful. I agree that this is potentially a big problem, but I don't have any real IDP data.

I think this issue solved with all the work we've done in this area (well-known files and IdP login status)? Let me know if we can close