User identity associated with the RP should not be sent to the IDP before explicit consent is gathered

[bvandersloot-mozilla]

There is a potential attack that discloses that a user visited an RP to an IDP without explicit consent.

1. RP creates a credential, specifying the IDP in the federated parameter and required mode.
2. The browser begins executing the create-credential algorithm.
3. The browser fetches the manifest from the IDP. As specified, this sends a Referer header with value of the RP.
4. The IDP returns a unique account-list url in the manifest and remembers the tuple (account-list url, RP from referer).
5. The browser requests the account list via the url in the manifest, sending its IDP cookie.
6. The IDP checks for the account-list url among its tuples. Upon finding one, it creates a new tuple (IDP cookie from account-list request, Referer header from manifest request).
7. The IDP and RP have won.

There are two features that enable this attack: arbitrary URLs allowed in the manifest and the Referer header being sent with the manifest. Neither is explicitly permitted, but since they are explicitly forbidden in other API call in the spec I assume that they are allowed behaviors. Let me know if I'm misreading this at all!

[npm1]

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

[dj2]

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.

[dj2]

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

[samuelgoto]

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(); 

[bvandersloot-mozilla]

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.

[samuelgoto]

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?

[bvandersloot-mozilla]

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.

[cbiesinger]

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.

[achimschloss]

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.

[dj2]

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.

[bvandersloot-mozilla]

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.

[samuelgoto]

@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)

[bvandersloot-mozilla]

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.

[yi-gu]

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.