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.
On Fri, Jan 9, 2026, 04:13 Primbs, Jonas <[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]>: > > 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]> 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]> wrote: >> >>> I believe that the quoted line below is important: >>> >>> On 7 Nov 2025, at 10:42, Frederik Krogsdal Jacobsen <frederik.krogsdal= >>> [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] >>> To unsubscribe send an email to [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] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
