w3c-fedid / FedCM

A privacy preserving identity exchange Web API
https://w3c-fedid.github.io/FedCM/
Other
375 stars 72 forks source link

ID Assertion Endpoint Origin Trust Sanity Check #534

Closed philsmart closed 9 months ago

philsmart commented 9 months ago

The documentation here suggests the IdP return an identity token of some kind (claims about the subject I read it as, rather than claims about the authentication, but maybe it means the latter) when FedCM sends a request to the assertion endpoint. However, In this call to the assertions endpoint, the RP can not authenticate itself to the IdP, so trust is based exclusively on the origin of the RP sent by the browser (the RP can pretend to be any client_id it wants).

What happens if a rogue RP, sitting on the same origin as a trusted one, requests a token pretending to be the trusted RP? It seems the IdP would have no idea, and would pass back the requested claims to the browser which then passes it back to the RP. In OIDC or SAML the IdP would only (to the best of my knowledge) respond to a pre-registered endpoint. But in the FedCM world it can only respond to the browser's HTTP request.

An encrypted token would help here, but this is not always common.

I realise that a rogue RP on the same origin as a trusted one is not trivial, and if it does happen, other browser security mechanisms are not enforced (e.g. the SOP).

Either I have missed something (very possible), or this is not a concern, but I thought I would double check.

cbiesinger commented 9 months ago

Yes, this would be possible, though the web model in general does not really protect data within an origin. For example, the "attacker" URL on the same origin could load the real URL using window.open and inject javascript into that, or change various global objects in that javascript environment, etc.

philsmart commented 9 months ago

I get you, thanks for the explanation @cbiesinger.