Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What cookies are passed in the Sign In API call? #248

Closed
dickhardt opened this issue Apr 9, 2022 · 4 comments
Closed

What cookies are passed in the Sign In API call? #248

dickhardt opened this issue Apr 9, 2022 · 4 comments

Comments

@dickhardt
Copy link

https://fedidcg.github.io/FedCM/#browser-api-rp-sign-in
9.3.1

In the POST to the IdP to mint an ID Token -- which cookies are being passed? Some IdPs that use 1P cookies lock down the cookies with sameSite -- will the browser send any cookies that would be sent in a 1P call to the IdP with the POST?

@ritou
Copy link
Contributor

ritou commented Apr 18, 2022

At this time (2022/4/17) Chrome Canary appears to only send SameSite=None cookies for accounts _list_endpoint / id_token_endpoint.

To achieve seamless identity federation in a world where 3rd party cookies do not exist, I believe that cookies handled only by 1st party should be sent.

This Issue seems to point out this problem.
#212

@samuelgoto
Copy link
Collaborator

We are still investigating our implementation, but I believe this is the case:

At this time (2022/4/17) Chrome Canary appears to only send SameSite=None cookies for accounts _list_endpoint / id_token_endpoint.

SameSite=None seems overly permissive to me, because FedCM isolates sites enough prior to user interaction (e.g. keeps the IDP blind to the RP and vice versa), that I'm thinking that something along the lines of SameSite=Federated (or just a Federated attribute to cookies) more accurately labels it (rather than push IDPs to use SameSite=None).

@johannhof
Copy link
Contributor

SameSite=None seems overly permissive to me, because FedCM isolates sites enough prior to user interaction (e.g. keeps the IDP blind to the RP and vice versa), that I'm thinking that something along the lines of SameSite=Federated (or just a Federated attribute to cookies) more accurately labels it (rather than push IDPs to use SameSite=None).

Note that per my understanding, we can't add new SameSite values because old browsers aren't handling that well. A new attribute might work technically, but I'm not sure what is too permissive about SameSite=None that would be fixed with Federated, are there additional security considerations here, since the two should be equivalent for privacy?

We're having an extended discussion in PrivacyCG around how to make SameSite work in edge cases with 3rd party cookie blocking that might be worth following as well (updates probably appear on privacycg/meetings#19)

@samuelgoto
Copy link
Collaborator

@cbiesinger found recently some resolution here for this question:

In the POST to the IdP to mint an ID Token -- which cookies are being passed? Some IdPs that use 1P cookies lock down the cookies with sameSite -- will the browser send any cookies that would be sent in a 1P call to the IdP with the POST?

Yes.

Because the prompt is mediated by the browser (and keeps the guarantees of separating the RP from the IDP up until the user consents), the browser will send the cookies to the IDP as if it were loaded in a first party context (e.g. ignoring the SameSite, because it is being used in a first party context).

At this time (2022/4/17) Chrome Canary appears to only send SameSite=None cookies for accounts _list_endpoint / id_token_endpoint.

That's correct.

With @cbiesinger 's resolution, we'll treat this behavior as a bug and fix it in the next few weeks.

Resolving this with this resolution, feel free to re-open if this doesn't work for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants