Hi Jonas
If my understanding is correct, the cookie seems to need the weak spot, can
this process be removed for a framework that is certain.
I'm an still learning, please pardon my ignorance, if my questions seem to be
off path.
A protocol or framework that presents more options rather than for a better
robust security solution in this case, should be avoided.
That's what my thoughts tell me.
Pathing a secure foundation that does not raise questions, would be the ideal
approach, if possible in the environment.
Kind
Regards
Clint
Sent from [Proton Mail](https://proton.me/mail/home) for Android.
-------- Original Message --------
On Friday, 01/09/26 at 11:14 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
>>>>> <[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]
