cbiesinger
commented
1 month ago We currently require same-origin (which is actually more strict than same-host) because that simplifies questions around CSP and other security issues. We also have not had a request for this before. We could relax this to same-site fairly easily although we'd have to figure out if we need to do a separate CSP check for those resources.
Redirects are trickier. In principle same-site could work but fetch provides no API to only allow same-site redirects. It may be possible to add such an API but we have not explored that.
We should not allow cross-site IMO because that would allow an attacker to show their own account chooser and then point users to other IDPs just for the ID assertion, which is not something we should allow.
Would same-site (i.e. same eTLD+1) and no redirects work for your case?
We also have a proposal to allow multiple configURLs, as long as they point to the same accounts endpoint, which might possibly help as well (#552)
obfuscoder
During design discussions we had questions regarding deployments. Let's say an IdP is providing a configURL which is configured by several RPs. Now the IdP would like to provide the accounts_endpoint and id_assertion_endpoint on a different subdomain than the static configURL. This is currently not possible. The endpoints need to use same URL as the configURL. Redirect responses are also not allowed for id assertion and accounts endpoints.
Locking configURL and other endpoints to same domain prevents IdPs from supporting more complex deployments (e.g. multiple datacenters) without impact on RPs. If IdPs would need to move their endpoints, they would also need a new configURL which needs to be changed at all their RPs.
What is the reason for locking the endpoints to the same host address of the configURL?