Enforce CORS on the Identity Assertions endpoint

[antosart]

The spec says in a red note that

An IDP MUST check the referrerOrigin header to ensure that a malicious RP does not receive an ID token corresponding to another RP. In other words, the IDP MUST check that the referrerOrigin header is represented by the client_id. As the client_id are IDP-specific, the user agent cannot perform this check.

This seems a crucial check that the IdP must implement, as it would otherwise allow anyone the get the user's id token. Wouldn't it be safer to enforce CORS here (i.e.: the user agent throws an exception if the response does not include the correct Access-Control-Allow-Origin header)? CORS exist exactly for this usecase. And this would make it impossible for IdPs to forget to implement this check.

[antosart]

(I know there was a longer discussion regarding CORS in #320, but it seems to me that there we were mostly concerned with the requests which did not want to disclose the RP to the IdP, and that we did not take this into consideration.)

[npm1]

I don't think that CORS would avoid the problem being noted in the red note. The problem is that the IDP could in theory just use the clientID to determine what the client is, and this clientID is provided via JavaScript, so the website could lie about it. So it is inevitable that they have to verify that the clientID being used matches what the user agent says is the RP.

[antosart]

Yes. In my opinion, responding with the appropriate CORS headers means exactly that the server explicitly acknowledges that it performed the appropriate checks (which of course are specific to the business logic of the API, and in the case of FedCM boil down to checking that client_id and origin match).

[domfarolino]

So the threat scenario here is where evil.com invokes FedCM with some trusted RP's public client_id in hopes of impersonating the RP and stealing the user's credentials token, right?

The absolute minimal CORS check that an IDP might perform would return ACAO headers to any trusted RP, independent of client_id, which would then allow trusted RPs to impersonate each other, but that still seems like a base-line improvement as it protects against evil.com impersonating a trusted RP (when talking to the IDP). And a more complete CORS check would indeed consider client_id and ensure that ACAO headers only get returned when the Origin and client_id match, as @antosart mentions.

Separately, it seems odd that if client_id is so crucial to the equation, we don't do any browser-side verification at all, instead hope the server does some based on the Origin, for which the usual verification mechanism is CORS. The note mentions that the browser can't do the verification because the client_id is IDP-specific, but the browser knows which IDP it is talking to, so maybe it could do some work here? Anyways, it might be too late in the game to suggest that.

[npm1]

I suppose it is true that the browser could add a step to enforce that the RP is not lying about the client ID. For instance, the user agent could send client_id and the Origin to the IDP and the IDP needs to reply with some confirmation that those are indeed a match. It should be coupled with some fetch, for instance the ID assertion fetch, to not introduce latency. However, I do not think CORS is the right header for this because it increases the chance that the IDP accidentally makes the id assertion endpoint readable via other JS APIs from all RPs, which would be much worse than the attack being described here.

[cbiesinger]

@antosart ping -- did you have thoughts on npm1's comment above?

I guess we could add an origin field in the ID assertion response if people find that valuable

[achimschloss]

However, I do not think CORS is the right header for this because it increases the chance that the IDP accidentally makes the id assertion endpoint readable via other JS APIs from all RPs, which would be much worse than the attack being described here.

Using CORS to check if the pair of client_id and origin in a client side fetch call is valid is common practice for credentialed js calls with IDPs. The IDP would return all elligible origins for a specific client ID using CORS (the above mentioned easy method would not be possible honestly at least here in the EU)

Access-Control-Allow-Origin: <ORIGIN> Access-Control-Allow-Credentials: true

I guess we could add an origin field in the ID assertion response if people find that valuable

Assuming we are shifting and removing referer and use origin instead this is a must. In the end the IDP must have the client_id and the origin available (which is the key part here) and will check if the pair is as expected.

[achimschloss]

IDP accidentally makes the id assertion endpoint readable via other JS APIs from all RPs, which would be much worse than the attack being described here.

That might be a fair point as the FedCM API Call is not a classical client side fetch from the RP itself

[achimschloss]

I guess we could add an origin field in the ID assertion response if people find that valuable

Assuming we are shifting and removing referer and use origin instead this is a must. In the end the IDP must have the client_id and the origin available (which is the key part here) and will check if the pair is as expected.

Sorry I misread that - you mean the IDP should return the origin in its response? How does that ad value?

[antosart]

IDP accidentally makes the id assertion endpoint readable via other JS APIs from all RPs, which would be much worse than the attack being described here.

It's not totally clear to me where the risk would be in that case. In order to receive an ID token, the RP would still have to send an authenticated request with the proper cookie. Basically this would just mean that the RP could perform the auth flow without using the FedCM API (again, assuming it can send the first-party IDP cookie). If the IDP want to open this API only to FedCM, it can still check the X- header.

[domfarolino]

Also I want to make sure I fully understand the risk of using CORS here. IIUC, there is no risk of exposing the tokens to JS on any old site, right? (Because ACAO: * cannot be used with credentialed CORS requests). So the threat is that the IDP risks exposing tokens to the JS of trusted RPs? If the RPs are trusted, is that so bad? Maybe that's a dumb question — sorry for my lack of FedCM knowledge.

[cbiesinger]

The concern is that they will echo back the origin in ACAO, and forget to check the sec-fetch-dest. this would mean that websites can bypass FedCM and the corresponding user confirmation and send a request to the token endpoint directly.

[domfarolino]

If they naively echo back ACAO with any old origin, then the IDP isn't checking that the origin is a trusted RP, which the spec currently states is a requirement for security (see OP), so that threat (from enabling CORS) doesn't leave us any worse off than the current state of affairs.

[cbiesinger]

Fair enough, but my point is still that even if they do check that it's still possible to forget to check sec-fetch-dest, and suddenly the result becomes readable. I'm skeptical that using CORS adds any real security.