Hi Filip, This is an important point that you raise here. In an ideal world, the client would be able to learn whether the AS supports PKCE or not.
My proposal for a normative text would be this: --- If PKCE [@RFC7636] is used by the client and the authorization server supports PKCE, clients MAY opt to not use state for protection against Cross-Site Request Forgery, as such protection is provided by PKCE. In this case, state MAY be used again for its original purpose, namely transporting data about the application state of the client. It is important to note that: * If state is used for carrying application state, and integrity of its contents is a concern, clients MUST protect state against tampering and swapping. This can be achieved by binding the contents of state to the browser session and/or signed/encrypted state values [@I-D.bradley-oauth-jwt-encoded-state]. * There is no defined mechanism for clients to detect whether an authorization server supports PKCE or not. Clients that use PKCE despite the authorization server not supporting it will not receive any indication of the lack of support for PKCE. If the authorization server does not support PKCE, state MUST be used for CSRF protection. --- - Daniel Am 11.04.19 um 13:35 schrieb Filip Skokan: > In Prague we've seen and talked about this point from Torsten's deck > <https://datatracker.ietf.org/meeting/104/materials/slides-104-oauth-sessa-security-topics-00> > > > Use PKCE for CSRF prevention instead of state parameter > > * PKCE is mandatory now and can fulfill this additional task > * Simplifies recommendations and makes state available again for > original purpose (carry client transaction data) > > > While PKCE is now the suggested countermeasure to some attacks and is > to be used by Clients it's not yet mandatory to be implemented by the > AS and the client has no way of knowing for sure if it's implemented > (due to how PKCE is defined as backwards compatible to clients when AS > is missing its support). > > Since at no point in time does the client receive anything from the AS > suggesting that PKCE is in effect, is this a wise recommendation to > make in the current form? Some might interpret this as if they don't > need state to carry any client transaction data they might as well > just use PKCE and omit state altogether altho the server does not > support PKCE. > > S pozdravem, > *Filip Skokan* > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
