Hi Logan, > Am 09.01.2026 um 11:52 schrieb Logan Widick <[email protected]>: > > If it is possible to use different cookie flag settings for cookies issued > before and after login (web framework cookie settings might apply to all > cookies issued), and pre-login cookies with SameSite=None are allowed > (security guides and scanners might not), that could work as well.
Sure, the server can set individual cookie attributes. In my example before, when setting the after-login-cookie „sessionid“, the backend can do this as follows: Set-Cookie: sessionid=ABC; SameSite=Lax I would expect that, given the fact that when the SameSite=None attribute is still not deprecated, there are other legitimate reasons too. Therefore, I think web frameworks still provide the opportunity to set cookies with this attribute. But you are right, there might at least be some middlewares or WAFs trying to replace these attributes in default configuration which complicates maintenance. Again, I think that form_post ist not the solution we should target in the specs, but it right now it should be recommended as a workaround until we have a better solution. And based on my experience, a workaround rarely comes alone… Greetings, Jonas > On Fri, Jan 9, 2026, 04:13 Primbs, Jonas <[email protected] > <mailto:[email protected]>> wrote: >> Wouldn’t it be easier to mitigate the SameSite issue as follows? >> >> 1. Client redirects to the authorization request endpoint by issuing a >> dedicated session cookie SameSite=None: >> >> HTTP/1.1 302 Found >> Location: >> https://as.example.com/authorize?response_mode=form_post&state=xyz&… >> Set-Cookie: login-session=abc; SameSite=None >> >> In the backend, the server associates the login session „abc“ with the state >> „xyz" and other parameters such as the code verifier or nonce. >> >> 2. The user authorizes the client. >> >> 3. The authorization server responds with the form that will auto-submit the >> following POST request to the client: >> >> POST /callback HTTP/1.1 >> Cookie: login-session=abc >> Content-Type: x-www-form-urlencoded >> >> state=xyz&code=… >> >> The reason SameSite=Lax or =Strict cookies are not sent with a POST request >> is to prevent CSRF. However, using the state parameter provides an effective >> CSRF protection mechanism. >> In most scenarios (login flows), the session state changes with a login >> anyway, so the backend can respond to this POST request by issuing a new >> session cookie and terminating the temporary session cookie: >> >> HTTP/1.1 200 OK >> Set-Cookie: login-session= >> Set-Cookie: sessionid=ABC >> … >> >> Or do I miss anything important here? >> >> Greetings, >> Jonas >> >> >>> Am 05.01.2026 um 22:49 schrieb Logan Widick <[email protected] >>> <mailto:[email protected]>>: >>> >>> It may be possible to use SameSite=Lax or SameSite=Strict cookies with the >>> redirection endpoint. If a redirection endpoint detects cookie loss due to >>> SameSite, the redirection endpoint could respond with a second >>> auto-submitting HTML form with the same data. Since the browser should be >>> on the client's website when the second auto-submitting form is sent, the >>> cookies should be sent also. >>> >>> Some possibilities for detecting cookie loss on the first auto-submitting >>> HTML form: >>> 1. Have the two auto-submitting HTML forms use different endpoints. If the >>> first auto-submitting HTML form's endpoint is used, assume cookie loss has >>> occurred. >>> 2. Have the second auto-submitting form include some additional fields. If >>> the additional fields are not set as expected, assume cookie loss has >>> occurred. >>> 3. Analyze header values to determine if cookie loss has occurred. >>> 4. Analyze cookie values to determine if cookie loss has occurred. >>> >>> On Tue, Nov 25, 2025, 12:29 Thomas Broyer <[email protected] >>> <mailto:[email protected]>> wrote: >>>> Hi all, re-upping that conversation as a client and client library >>>> developer (OIDC relying party actually) >>>> >>>> Do we all agree that the specific scenario where authorization codes leak >>>> through near real-time access to access logs can be mitigated by always >>>> exchanging the authorization code, even when CSRF is suspected? (absence >>>> of or non-matching state; assuming a conformant AS/IdP that has single-use >>>> authorization codes) >>>> response_mode=form_post can also work but has severe implications wrt >>>> cookies (requires either using SameSite=None cookies to store >>>> "authentication state" between the redirects, or running the AS/IdP and >>>> the application "same-site"; Chromium has had a "temporary" Lax+POST >>>> mitigation that also allows this to work: >>>> https://www.chromium.org/updates/same-site/faq/#q-what-is-the-lax-post-mitigation) >>>> >>>> And the other scenarios (brought in another thread) where the >>>> authorization code leaks through a downgrade to response_mode=fragment, or >>>> the victim sharing the URL (with authorization code) following an error, >>>> can be mitigated by always redirecting, even (particularly) in case of >>>> errors, to remove any code from the URL? (I chose to redirect to the same >>>> callback endpoint but with an error=, using a custom error value for cases >>>> like missing input –likely a response_mode=fragment downgrade– or missing >>>> session state –i.e. no cookies–, and always including a hash in the >>>> redirect URL –I use the same error=– to remove any authorization code from >>>> a response_mode=fragment downgrade) >>>> >>>> AFAICT, hardly anything can be done if the attacker is able to block the >>>> redirect back to the client callback so it never reaches the server. IIUC, >>>> this is the only scenario where response_mode=form_post would be the only >>>> way to mitigate the attack. >>>> >>>> And for those who deploy AS/IdP (we regularly ship Keycloak alongside our >>>> applications), they should configure them (assuming the clients are >>>> compatible) to: >>>> * enforce PKCE >>>> * forbid response_mode=fragment (and implicit grants btw) >>>> * follow other best practices (e.g. validating redirect URIs using exact >>>> URI matching) >>>> Keycloak can do that using Client Policies for instance. >>>> >>>> Am I missing something? >>>> >>>> Fwiw, I reproduced those scenarios (near real time access logs leak, >>>> response_mode=fragment downgrade, URL sharing) in functional tests of my >>>> client library and confirmed the above mitigations work in those cases. >>>> >>>> Spec-wise, I'd suggest including some wording to OAuth 2.1 recommending >>>> the above-mentioned mitigations. >>>> >>>> On Sat, Nov 8, 2025 at 8:00 AM Philippe De Ryck >>>> <[email protected] >>>> <mailto:[email protected]>> wrote: >>>>> I believe that the quoted line below is important: >>>>> >>>>>> On 7 Nov 2025, at 10:42, Frederik Krogsdal Jacobsen >>>>>> <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> PKCE by itself does not fix this problem, but intentionally using PKCE >>>>>> without a verifier is one way to revoke a code without getting a token >>>>>> that you could accidentally use. >>>>> >>>>> >>>>> It seems very logical that a client implementation that needs to exchange >>>>> an authorization code would need a PKCE verifier. It is trying to look it >>>>> up, but due to this being a malicious or tampered with flow, that lookup >>>>> is likely to fail (i.e, no PKCE verifier available). If I would write >>>>> this code, I would not call the AS knowing up front that this request is >>>>> going to fail. So based on this discussion, it really seems that we >>>>> should make this a guideline for implementing PKCE on the client. >>>>> >>>>> Philippe >>>>> _______________________________________________ >>>>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>>>> To unsubscribe send an email to [email protected] >>>>> <mailto:[email protected]> >>>> >>>> >>>> >>>> -- >>>> Thomas Broyer >>>> /tɔ.ma.bʁwa.je/ >>>> <https://ipa-reader.com/?text=t%C9%94.ma.b%CA%81wa.je&voice=Mathieu>_______________________________________________ >>>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>>> To unsubscribe send an email to [email protected] >>>> <mailto:[email protected]> >>> _______________________________________________ >>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] >>> <mailto:[email protected]> >>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
