[Openid-specs-fapi] The reasons behind requiring PKCE for confidential clients?

Torsten Lodderstedt torsten at lodderstedt.net
Sat Aug 26 08:42:59 UTC 2017


You may just refer to https://tools.ietf.org/html/draft-ietf-oauth-security-topics-01, in particular section 3.1

> Am 26.08.2017 um 10:14 schrieb Nat Sakimura <nat at sakimura.org>:
> 
> Thanks, Torsten.
> 
> Right. So an attack scenario I guess is a privilege escalation using code injection.
> 
> Environment
> -------------
> - RFC6749 code grant with a confidential client (e.g. web server client)
> - The victim's front channel communication is somehow compromised (e.g., through WPAD attack, server log, etc.)
> - The client is implementing RFC6749 properly with XSRF protection etc.
> 
> Attack Scenario
> -----------------
> 1. The victim and the attacker are using the same web client.
> 2. The attacker gets the victim's `code` somehow, e.g., WPAD attack.
> 3. The attacker inserts the `code` into the session he started.
> 4. The client sends the `code` with its client secret to the token endpoint.
> 5. The token endpoint verifies the client secret and that the code was issued to the client.
> 6. The token endpoint sends the access token back to the client.
> 7. The client accesses the victim's protected resource successfully and returns it to the attacker. SUCCESS.
> 
> 
> Mitigation
> -----------
> Use PKCE with S256. By doing so, the above scenario changes to:
> 
> 1. The victim and the attacker are using the same web client.
> 2. The attacker gets the victim's `code` somehow, e.g., WPAD attack.
> 3. The attacker inserts the `code` into the session he started.
> 4. The client sends the `code` with its client secret and the code verifier to the token endpoint.
> 5. The token endpoint verifies the client secret and that the code was issued to the client.
> 5a. The token endpoint verifies the code verifier matches the one tied to the code. This fails.
> 6. The token endpoint sends the error back to the client.
> 7. The attack FAILED.
> 
> I will add the above explanation to the ticket #11. The ticket itself was saying that we should document it, which we did not :-(
> 
> 
> For Read&Write, we are mandating hybrid flow. However, for the Read only, we are not.
> Thus, for the Read Only (Part 1), we should still mandate the use of PKCE.
> 
> That's why it is saying
> 
> * shall support [RFC7636] or the mechanisms defined in Financial API - Part 2;
> 
> 
> ---
> Nat Sakimura
> Research Fellow, Nomura Research Institute
> Chairman of the Board, OpenID Foundation
> 
>> On 2017-08-25 18:15, Torsten Lodderstedt wrote:
>> Hi Nat,
>> just guessing - the new OAuth security BCP recommends use of PKCE for
>> detecting/preventing code injection attacks. That might be the reason
>> for adding the requirement to the FAPI profile.
>> I know the hybrid flow („code id_token“) is an alternative
>> countermeasure in the OIDC space. So my question is: will FAPI allow
>> use of pure authz code flow? Then recommending PKCE for code injection
>> makes a lot of sense.
>> best regards,
>> Torsten.
>>> Am 24.08.2017 um 19:43 schrieb Nat Sakimura via Openid-specs-fapi <openid-specs-fapi at lists.openid.net>:
>>> Hi.
>>> Current text reads like it is requiring PKCE support even for the confidential client.
>>> Do you remember the reason for it? Or is it just an editorial error?
>>> John may have mentioned a potential attack that PKCE could help but I do not quite remember the details....
>>> If it is an error, then we should fix it for the final.
>>> Best,
>>> --
>>> Nat Sakimura
>>> Research Fellow, Nomura Research Institute
>>> Chairman of the Board, OpenID Foundation
>>> _______________________________________________
>>> Openid-specs-fapi mailing list
>>> Openid-specs-fapi at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20170826/93e25ca6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2378 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20170826/93e25ca6/attachment.p7s>


More information about the Openid-specs-fapi mailing list