> 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?
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 protected]> wrote: > 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 > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
