Closed saschanaz closed 1 year ago
Good question. PKCE is an extension and not part of OAuth main (from what I understand) so I imagine that state and the PKCE logic allows for some more validation that a server and client can allow for verification, like being able to choose what kind of hashing algorithm in advance (my implementation opts for S512).
(Originally published at: https://jacky.wtf/2023/3/5nMd)
Oh hmm, good point. The OAuth main spec requires it, so it's probably not even an option to not implement it. https://www.rfc-editor.org/rfc/rfc6749#section-4.1.1
REQUIRED if the "state" parameter was present in the client authorization request. The exact value received from the client.
Thanks for the answer!
Oh, but then the main spec does not mandate including state
in the client request:
RECOMMENDED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHOULD be used for preventing cross-site request forgery as described in Section 10.12.
Perhaps the parameter can be optional on the endpoint if code_challenge
exists?
Although the OAuth spec says the state parameter should be used for CSRF protection, that doesn't mean the client can't use it for other purposes as well. For example, it could be used to:
I'm closing this, as PKCE is for the authorization server and state
is for the client. Probably good to require both for the best security.
59 added PKCE but didn't touch
state
. Per the spec: https://indieauth.spec.indieweb.org/#authorization-requestBut PKCE is also to prevent CSRF. Do we really need both?