I agree that using a JWT is not the only way to do it, however many clients were not sending state at all or doing something insecure.
Particularly some people were having trouble with AS like Google who do exact redirect_uri matching and not being able to see how to pass multiple parameters in state rather then tacking extra query parameters on to the redirect_uri. Documenting how to do it with a JWT and some of the security considerations specific to crating a useful state value has been useful to some people. RFC 6819 has only a short section on state. 3.6 <https://tools.ietf.org/html/rfc6819#section-3.6>. "state" Parameter The "state" parameter is used to link requests and callbacks to prevent cross-site request forgery attacks (see Section 4.4.1.8 <https://tools.ietf.org/html/rfc6819#section-4.4.1.8>) where an attacker authorizes access to his own resources and then tricks a user into following a redirect with the attacker's token. This parameter should bind to the authenticated state in a user agent and, as per the core OAuth spec, the user agent must be capable of keeping it in a location accessible only by the client and user agent, i.e., protected by same-origin policy. That is a bit hand wavy for some developers who wanted examples. In any event I think we agree that dragging the whole JWT signed state draft into the checking state mitigation. The mitigation makes checking the integrity of state by the client signing less important, as tampering with the value would be detected by the server in the code flow. Perhaps as we develop the mitigation spec we could move some of the more critical advice on how to bind the browser instance to the state over to the mitigation draft. John B. > On Jan 22, 2016, at 1:32 PM, Thomas Broyer <t.bro...@gmail.com> wrote: > > > Hi John, > > > Le jeu. 21 janv. 2016 15:42, John Bradley <ve7...@ve7jtb.com > <mailto:ve7...@ve7jtb.com>> a écrit : > We merged the state verification in with this rather than forcing people to > also look at the JWT encoded State draft. > https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state > <https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state>. > > While JWT encoded state is how I would do state in a client and at-least one > client I know of uses it, it is not the only way to manage state, > > And not how I'd do it (unless you convince me that jwt is really better and > the advantages outweigh the network bloat) > > and I am hesitant that developers might be scared away by thinking they need > to encode state as a JWT. > > I decided that cross referencing them is better. This made sending much > simpler to describe. > > Wouldn't linking to RFC 6819 be enough? > > I also removed the hashing from state. That cut the text by about 2/3 by > not having to describe character set normalization so that both the client > and the AS could calculate the same hash. > That also achieved the goal of not requiring a simple OAuth client doing the > code flow to add a crypto library to support SHA256. > > Once we make a algorithm mandatory, we need to defend why we don’t have > crypto agility eg support for SHA3 etc. We would be forced by the IESG to > add another parameter to the request to specify the hash alg if we went that > direction. > > Given that we assume state to be public info in the request that an attacker > can see, hashing state provides not much value for a lot of complexity that > people may get wrong or not implement. > > I appreciate why from a theory point of view hashing it would have been > better. > > If people really want it I can add it back. > > John B. > >> On Jan 21, 2016, at 3:28 AM, Mike Jones <michael.jo...@microsoft.com >> <mailto:michael.jo...@microsoft.com>> wrote: >> >> John Bradley and I collaborated to create the second OAuth 2.0 Mix-Up >> Mitigation draft. Changes were: >> · Simplified by no longer specifying the signed JWT method for >> returning the mitigation information. >> · Simplified by no longer depending upon publication of a discovery >> metadata document. >> · Added the “state” token request parameter. >> · Added examples. >> · Added John Bradley as an editor. >> >> The specification is available at: >> · http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 >> <http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01> >> >> An HTML-formatted version is also available at: >> · >> http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html >> <http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html> >> >> -- Mike >> >> P.S. This note was also posted at http://self-issued.info/?p=1526 >> <http://self-issued.info/?p=1526> and as @selfissued >> <https://twitter.com/selfissued>. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <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
