Advanced PKCE
@inzanez it is up to user, to decide rotation moment. RFC is not telling anything on the matter, except giving some level of cryptographic complexity. Means it is long enough for attacker to not be able to guess. I guess also, adding any PKCE to non-PKCE enabled client is a good thing and not potential issue. Potential issue is to not have PKCE at all.
I cannot add more to previous my comment, as I do not think everyone wants to think about PKCE all the time. This (rotation) should be documented and we should provide more complicated way of doing this with
Advanced PKCE.
Originally posted by @kilork in #64
If we want to have one time code challenges, we can go for at least two options:
- stateful: we add internal or external state there we store all challenges and then clean up them on authentication or after ttl, the
stateis used to transfer the reference to particular challenge - stateless: we encrypt challenge with private key and transfer it with
state. Until key is known to attacker we should be safe.
Both variants use state. Means we influence usage of state, which could be potential issue for some use-cases. We should keep currently implemented client lifetime PKCE, to have option for such use cases, if there would be any. The other thing is give possibility to still use state.
To achieve this we interpret state as JSON with field chg (challenge) and app for application specific parameters.