Hi,
here is the respective text proposal for section 2.1. (Note: we also refactored
the text in order to disentangle CSRF/replay and mix-up detection).
Clients MUST prevent CSRF and ensure that each authorization response is only
accepted once. One-time use CSRF tokens carried in the state
Am 13.11.18 um 17:29 schrieb Brian Campbell:
>
> > Does this "MUST be single-use” not effectively already require
> the code is invalidated after first use? If so why downgrade this
> to a “SHOULD”?
>
> You are right. My feeling is single use can turn out to be a
> really hard t
> > Does this "MUST be single-use” not effectively already require the code
> is invalidated after first use? If so why downgrade this to a “SHOULD”?
>
> You are right. My feeling is single use can turn out to be a really hard
> to implement requirement. That’s why I would like to relax it. Given w
Hi Joseph,
> Am 09.11.2018 um 18:27 schrieb Joseph Heenan :
>
> Hi Torsten,
>
> A few comments having just read this afresh:
>
> 2.1: 'Clients SHALL avoid’ - is that normatively different to ’SHOULD’ given
> it appears to be permitted?
SHALL is equivalent to MUST, changed it into SHOULD for
Hi Torsten,
A few comments having just read this afresh:
2.1: 'Clients SHALL avoid’ - is that normatively different to ’SHOULD’ given it
appears to be permitted?
I find it a little hard to understand exactly what "avoid any redirects or
forwards which can be parameterized by URI query paramete
Hi all,
the new revision incorporates the recommendation to use more secure grant types
instead of implicit we agreed to add during the WG session on Monday. It also
has more text around justifications for our recommendation. Especially, there
is a new section 3.6 on access token injection.
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.
Title : OAuth 2.0 Security Best Current Practice
Authors : Torsten Lodderstedt
J
