Hi Clint, I get your point. This should not be the official solution to solve the Browser Swapping issue.
Moreover, I just stepped into another issue when using response_mode=form_post for desktop applications with a loopback redirect URI (which, by the way, does not need cookies at all): Safari shows a dialog „This is a non-secure form“ when trying to send a POST request from the authorization server (HTTPS) to the loopback redirect URI (HTTP). The reason is that Safari wants to warn users when switching from a secure (HTTPS) context to an insecure (HTTP) context, thereby ignoring the exception (step 4 [1]) that loopback addresses should be considered as secure even when using HTTP. However, before Dick’s HTTP Redirect Header becomes usable, I think we don’t have many other solutions left. I think we should still consider response_mode=form_post as a "temporary workaround“. Greetings, Jonas [1] https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy > Am 09.01.2026 um 10:53 schrieb kcloud <[email protected]>: > > 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] >> <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] >> To unsubscribe send an email to [email protected] >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
