Am 16.11.19 um 14:28 schrieb Aaron Parecki: > Thanks for the reply. You're right, PKCE requires maintaining > application state as well, and does solve the main worry I have. > > However I think there is still something more. I guess my concern is > around the specific wording: > >> in this case, 'state' may be used again for its original purpose... > My concern is if people see this recommendation, (even though it's > clarified that it only applies if the authorization server supports > PKCE), they may revert back to static "state" values *regardless* of > whether the server supports PKCE, opening up a security hole again. > This is especially problematic because of the way PKCE works where > clients have no indication as to whether the server supports PKCE if > the whole flow is successful. > > I guess I just would rather not mention the possibility of using > static state values again. I would like to keep this note. We could change the wording, however. How about this:
"If PKCE [RFC7636] is used by the client and the client *has ensured* that the authorization server supports PKCE, the client MAY opt to not use "state" for CSRF protection". -Daniel
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
