[OAUTH-WG] Re: Browser-Swapping

[Thomas Broyer <[e-mail]>]

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 <
[e-mail]> wrote:

> I believe that the quoted line below is important:
>
> On 7 Nov 2025, at 10:42, Frederik Krogsdal Jacobsen <frederik.krogsdal=
> [e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/
<https://ipa-reader.com/?text=t%C9%94.ma.b%CA%81wa.je&voice=Mathieu>