Works for me, sounds like that clears up the confusion I am worried about. Aaron
On Mon, Nov 25, 2019 at 7:12 AM Daniel Fett <[email protected]> wrote: > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > -- ---- Aaron Parecki aaronparecki.com @aaronpk <http://twitter.com/aaronpk>
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
