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 parameter, which are securely bound to the user agent, SHOULD be used for that purpose. In order to prevent mix-up attacks, clients MUST only process redirect responses of the OAuth authorization server they send the respective request to and from the same user agent this authorization request was initiated with. Clients MUST memorize which authorization server they sent an authorization request to and bind this information to the user agent and ensure any sub-sequent messages are sent to the same authorization server. Clients SHOULD use AS-specific redirect URIs as a means to identify the AS a particular response came from. ---- kind regards, Torsten. > Am 14.11.2018 um 09:26 schrieb Daniel Fett <danielf+oa...@yes.com>: > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
