Subject: [OAUTH-WG] Reasoning behind OAuth 2.0 PKCE

From: Marcin Szewczyk <[email-masked]>
Date: Tue, 11 May 2021 14:57:03 +0200

Hi,

I am reading RFC 7636 (Proof Key for Code Exchange by OAuth Public
Clients) to understand how it mitigates the problem of intercepting
authorization code on the device itself and not in internet transit.

I fail to understand reasoning behind the following paragraphs:

1. Introduction, 4b. (rephrased):

    the attacker observes both requests and responses to/from the
    authorization endpoint, not using MitM but http log of the OS
    leaking information (I presume URLs with parameters that ought to be
    secret)

1. Introduction, last paragraph:

> The authorization code obtained is then sent to the token endpoint
> with the "code verifier", and the server compares it with the
> previously received request code so that it can perform the proof of
> possession of the "code verifier" by the client. This works as the
> mitigation since the attacker would not know this one-time key, since
> it is sent over TLS and cannot be intercepted.

I do not understand the remark about TLS here as TLS alone does not
prevent the attack because the HTTP connection itself is not the source
of the leak. It is even stated explicitly that it is not about MitM. I
thought PKCE is all about TLS not being enough and leaking information
in the OS. Without TLS at every step (in general) the whole scheme seems
to fall apart.

If as mentioned in paragraph 4b. the source of the leak is the HTTP log
of Authorization Request: why would not the attacker know the code
verifier as well if Access Token Requests were logged too?

Is it assumed that Authorization Request is more susceptible to attack
than Access Token Request because it is more probable that log will
contain query parameters but not entity-body (request contents transfer
methods respectively)?

BTW, it may be impossible for the attacker to do a classic MitM but
maybe the attacker could crash the legitimate application just after one
gets the Access Token Request in log or just try to win the race or
maybe replay Access Token Request?

Additionally RFC 6750 (OAuth 2.0: Bearer Token Usage) allows sending
bearer access tokens in URI query parameter so these URIs in log would
pose danger as well. I suppose that is one of the reasons OAuth 2.0
Security Best Current Practice[1] discourages this method.

[1]: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics

The archive seems to contain mainly "internal" WG's discussions but
maybe it is acceptable to ask the question here. I am sorry if it is
not. I did not find a better place to ask.

-- 
Marcin Szewczyk
http://wodny.org

---

From: Aaron Parecki <[email-masked]>
Date: Tue, 11 May 2021 06:17:41 -0700

> verifier as well if Access Token Requests were logged too?

You're on the right track here. It's all about where the attacker is
sitting in the connection. PKCE isn't attempting to solve anything if there
is an attacker able observe the requests at the AS. It's about whether
there's an attacker between the client and AS.

The reason PKCE works here is that the PKCE code verifier never leaves the
client until the very last stage of exchanging the authorization code in an
HTTPS request directly to the token endpoint. That connection is assumed to
be secure since it is an HTTPS POST request. The attack PKCE prevents is
when the authorization code might be intercepted in the redirect from the
AS to the client, since that is *NOT* an HTTP/HTTPS request from the AS to
the client. That request is an HTTP redirect from the AS to the user agent,
and the user agent takes the authorization code and delivers it to the
client.

This distinction is the "front channel" vs "back channel". It comes up a
lot in the implicit flow discussions as well. I have some videos about the
implicit flow and general OAuth security that talk about this difference:

https://oauth.net/videos/

Hope this helps!

Aaron

On Tue, May 11, 2021 at 5:59 AM Marcin Szewczyk <[email-masked]>
wrote:

> [1]:
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>