On 8 May 2024, at 22:01, Joseph Heenan <jos...@authlete.com> wrote: On 8 May 2024, at 21:43, Sam Goto <g...@google.com> wrote:
Hi Neil
In particular, the call to the accounts endpoint assumes that the IdP is willing to provide PII about the user to the browser. That seems questionable.
Aside from a privacy/security threat model perspective (meaning, the user agent already has visibility over every network request made available to the content area)
Sure, but if I use the recommended auth code flow or encrypted ID tokens, then PII is not exposed to the browser. And it’s not just the browser itself in the current proposal, as the token is exposed to _javascript_, of course, so the usual XSS risks.
Sam’s response here is fair, but also note that as far as I understand it you can still use the authorization code flow or encrypted id tokens with the FedCM API
That's correct: the browser doesn't open the response from the IdP to the RP, so it can, for example, be encrypted.
I was assuming that Neil was referring to the fact that the id_assertion_endpoint (which contains the user's IdP's PII accounts) become, suddenly, transparent to the browser.
Oh yes, that’s true - but (I think) the data from the id_assertion_endpoint at least isn’t exposed to _javascript_ and isn’t vulnerable to XSS?
That depends on whether the IdP correctly enforces the presence of the sec-fetch-dest header. If it doesn’t then yes, it would be vulnerable. Presumably it’s also vulnerable on older/niche browsers that don’t block sec-* headers: caniuse.com reckons > 8% of users globally are using browsers that don’t understand any sec-fetch-* headers. I’m not sure when sec-* was added to the forbidden list.
I guess, flipping this around, we might ask what is the legitimate purpose for which browsers need to access the user’s name, email address (both requires) and other identifying information? I’d have thought an identifier (possibly randomised) and some user-supplied account nickname would be sufficient.
— Neil
|
