[Openid-specs-ab] 3rd party and SameSite cookies (was Browser Interactions STC - Meeting Notes - 2021-05-05)

Brock Allen brockallen at gmail.com
Fri May 7 22:36:45 UTC 2021


> (As best I understand it anyway) a previously set cookie with SameSite=None will be sent by the browser on such a top-level cross-site POST request. Some folks have suggested that that will change with 3rd party cookies going away and that even a SameSite=None cookie will no longer be sent in that situation. But in my mental model of this stuff, the situation will be unchanged by 3rd party cookies going away - it's a cross-site request but because it is a top-level navigation the cookies are 1st party. SameSite enforcement is in place so SameSite=None cookies will be sent. But it's not 3rd party so is not impacted by disappearance or partitioning of 3rd party cookies.

I'm not Sam, but in my experience this is the case. In ASP.NET, the nonce cookie is configured with samesite=none and that's how it survives the cross-site POST.


> Anyway, that's what I'm hoping Sam can provide clarification on. Mostly for the benefit of my own understanding but also for the benefit of the group here as recent discussions have suggested that folks have divergent understanding and expectations of things. 


There is another leg to this workflow, though, which is affected by the scenario you describe Brian. And it's what breaks the login workflow (cross-site). My observations are from trying to reverse engineer what the browser is doing, so I don't know if it's intended. Also, it's complicated and I've always had a hard time explaining what I think is happening, so apologies in advance.

During this workflow, if the RP then issues its own SameSite=Strict (and Lax too IIRC) session cookie on that exact POST response and also emits a 302 elsewhere in the RP, then on that next request the browser makes it will omit sending the cookie. I think it does this because it detects that you're in the middle of a long redirect chain which originated at the OP and has crossed the line into the RP (cross-site). The end result is that it won't send the RP session cookie on that final request, and from the end user's (and RP's) perspective this last request is anonymous. I know this is complicated to follow, so apologies.

Interestingly, though, if the user were to just hit refresh in the browser or manually navigate to somewhere in the RP, then the cookie is sent normally since it's the user that initiates the request. IOW, on the POST cross-site, the browser accepts the cookie just fine. It's just that it doesn't send it on the request because the request chain looks initiated from cross-site.

Again, I'm sorry that I'm not describing this very well. I tried to cover it on a blog post I made a while ago:

https://brockallen.com/2019/01/11/same-site-cookies-asp-net-core-and-external-authentication-providers/


To work around this, I find that if on the response to the POST in the RP, I render a 200 and then emit HTML/JS which triggers a load of a different URL (by assigning window.location or use a meta tag) then the browser will send the cookie since the request looks RP-initiated (and thus same-site). 


I know this is not quite what you were asking about, but I thought I'd share since it's somewhat(?) relevant.

-Brock

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210507/35657a98/attachment.html>


More information about the Openid-specs-ab mailing list