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 to implement requirement. That’s why I would like to > relax it. Given we now have a stronger requirement on client > authentication that should be fine. > > Question to the list: what is your implementation experience > regarding one time use authorization codes? > > > There's a bit of discussion about this on this ticket in the Connect > WG: > https://bitbucket.org/openid/connect/issues/1057/oidcc-appears-to-override-single-use > FWIW. > > I do think that in some systems or architectures it can be difficult > to strictly guarantee that a code can only be used once. And it'd be > better for specs to come to terms with that rather than being > unrealistically strict about it. > > We have an AS implementation that does do strict one-time use of the > code. But it comes at a cost including some difficulties with > resiliency for any particular code. Not to mention some > troubleshooting and support issues/questions about it. We haven't > gotten to the point of changing anything but have, from time to time, > considered changing the implementation approach for code to something > that would appear to behave the same but might not 100% guarantee a > code could only be used once.
>From a security point of view: What do we want to achieve? I assume that the original text in 6749 tried to ensure that even if an authz code leaks to an attacker, the attacker (or a client on behalf of the attacker) cannot obtain an access token using this code. To capture this in a (very strong) security property, we could say: Even if the whole authz response leaks to an attacker, including all browser cookies, the attacker must not be able to obtain a token (or make the client obtain a token) with it (after the legitimate user used the code). With the current state of the draft, we can achieve this: We have client authentication and injection prevention (read: PKCE) to prevent any direct use of the code or use of the code in a new session with the client. We further require that each authz response is accepted only once by a client, in particular, we suggest to use a single-use "state" for this purpose. TL;DR: With single-use state and client authentication we do not gain security from single-use codes. I would be fine with relaxing the requirement on single-use codes in 6749. -Daniel
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
