w3c-fedid / FedCM

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

Multi-tenant considerations with endpoint metadata #153

Open hpsin opened 2 years ago

hpsin commented 2 years ago

Several IDPs support a multi-tenant model, whereby users can access other organizations. They authenticate to a specific issuer, but can utilize their SSO session to authenticate within another tenant. Applications are able to use that pattern to their benefit, signing a user in at a "common" endpoint that performs user discovery, and then thereafter performing "tenanted" login to direct the user to a specific organization for future sign ins.

Under FedCM, it does not appear that an application can do this pattern - sign a user in at idp.example, and then make futrther requests to sign the user in to another organization, e.g. idp.example/company2. Company2 would seem to register as another IDP, and not receive the federated credential stashed by the browser for the original idp.example domain.

Consider: could a "tenant" or "sub-IDP" concept be added to the system, to allow an IDP to transfer SSO state from one IDP to another?

dj2 commented 2 years ago

Do you have a link to some docs so I can understand how this works now? Is the SSO session to authenticate with another tenant a request to the IDP that uses the cookie or is it a request that just needs the id_token (or some other kind of token?)

What SSO state needs to be transfered? Oh, re-reading, are you saying it would be, essentially, swapping the url of the provider that we work with? So, you'd sign in with idp.example.com and when that was complete you'd want say something like, ok, go get idp.test.com/.well-known/endpoint and use that for all future requests? How does the teneted login get the IDP cookie to know the user is authenticated?