search

w3ctag / design-reviews

W3C specs and API reviews
Creative Commons Zero v1.0 Universal
319 stars 55 forks source link

FedCM: LoginHint, UserInfo, and RPContext #839

Open npm1 opened 1 year ago

npm1 commented 1 year ago

こんにちは TAG-さん!

I'm requesting a TAG review of LoginHint, UserInfo, and RPContext. These are small additions to the FedCM API, so I'm filing a review to cover all three.

Further details:

You should also know that our current goal is to ship on Chrome 116, which branches on June 20, 2023. I plan to send a PR to the FedCM repo shortly.

We'd prefer the TAG provide feedback as (please delete all but the desired option): 💬 leave review feedback as a comment in this issue and @-notify @npm1

plinss commented 4 months ago

@rhiaro and I took a look at this today (apologies for the long delay), LoginHint and the RPContext seem fine by us, but we have a question about UserInfo.

The explainer mentions that the UA would retain user information even after the user signs out of the IDP. Considering a shared computer, e.g. I sign in to a service at a computer in my library, then sign out, it seems that the next person using that computer gets to see information about my identity, which I would not expect after having signed out. Are we understanding that correctly or are we missing something?

npm1 commented 4 months ago

Hello, I can clarify. The UA does not retain the user info, but instead performs an accounts fetch to determine which IDP accounts are still available at the time in which the UserInfo API is requested. So in the example mentioned, after you log out of the IDP in a shared computer, the next person would not see your identity since the accounts fetch will not return your account.

plinss commented 4 months ago

Understood, thanks for the clarification. This then raises the question of log out flow, if the user logs out of the RP, are they always logging out of the IDP? If not, is that clear to them that they are still logged in to the IDP?

npm1 commented 4 months ago

If the user logs out of the RP, they are still logged in to the IDP. They would have had to manually log in to the IDP, though, so that should not be surprising to a user.

plinss commented 4 months ago

Given people's experience with SAML/OIDC single-sign-out (and it's lack of consistent implementations) I expect most users don't really understand the difference. Having a normal logout flow not sign the user out of the IDP is reasonable, but I feel it's important for the distinction to be made clear to the user. Especially in a shared-use scenario.

npm1 commented 4 months ago

Sorry, how is this relevant to the features in this review? If this was about the login status API or some other feature that lets you login to the IDP, then I can see the concern. With the UserInfo API, the information is only available to the IDP iframe within the RP website. So if the user logs out of the RP, the user may see personalized info in the RP website because they are still logged in to the IDP. I don't see how this is unexpected.

plinss commented 4 months ago

The feedback is about UserInfo potentially leaking personal information in a shared computer environment. It's not about making the previous user's identity available to an iframe, but displaying it to the next user of the computer if the previous user didn't log out of what they thought they were logging out of.

Think of a public computer in a library, person A logs into a site via FedCM, then when finished, logs out of the RP, but doesn't realize they haven't logged out of the IDP, and closes the tab/window. The next person using the computer, potentially someone who was stalking person A, recognizes the site Person A was visiting, visits that site and gets to see person A's name and possibly email address.

(There's also the issue of the next user leveraging the status of still being logged in to the IDP and using that to access the RP as the previous user.)

npm1 commented 4 months ago

Hmm ok. But how did the user log in to the site via FedCM? They must have had to login to the IDP. So I suppose the steps are:

So in this case, the next person seeing person A's name and email on the RP can just as easily instead visit the IDP site, where the person A is still logged in(!!!). So UserInfo API is the least of person A's problems, and does not introduce any new information that the stalker cannot learn otherwise. In fact, the stalker has complete access to person A's IDP at this point since they forgot to log out of the IDP, regardless of the UserInfo API.

samuelgoto commented 2 days ago

Think of a public computer in a library, person A logs into a site via FedCM, then when finished, logs out of the RP, but doesn't realize they haven't logged out of the IDP, and closes the tab/window. The next person using the computer, potentially someone who was stalking person A, recognizes the site Person A was visiting, visits that site and gets to see person A's name and possibly email address.

From a security threat model perspective, we don't handle physically-local attacks, which includes the use of public computers. More information on the topic here:

https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model-

doesn't realize they haven't logged out of the IDP

If the user doesn't realize they haven't logged out of the IdP and leaves a valid session in the cookie jar that another user can have access to (e.g. in a public computer), there are much bigger problems that the user would have before the User Info API becomes a problem: the attacker has access to the full IdP session, which is orders of magnitude richer (e.g. access to the user's email, social profile, payment instruments, etc) than the data provided by the User Info API.

Much of the position regarding challenging related to physical attacks are inspired some of the lessons from past OS designs (example, example).