> > 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. -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
