You don’t have to encode the parameters into the state parameter, just have them be referenceable *from* the state parameter, so it’s complexity doesn’t change. What I’ve seen done in several implementations (including our own) is that you generate a random State value, then save that into the session, along with any other stateful information like an ultimate target URI or other parameters. When the request comes back, I look back inside the session object to see if the state value matches what I’d stored earlier. If so, I can get out all the rest of the stuff that we stored before the auth request.
— Justin > On May 20, 2015, at 2:00 PM, Bill Burke <bbu...@redhat.com> wrote: > > > > On 5/20/2015 1:37 PM, David Waite wrote: >> >>> On May 16, 2015, at 1:43 AM, Patrick Gansterer <par...@paroga.com> wrote: >>> >>> "OAuth 2.0 Dynamic Client Registration Protocol” [1] is nearly finished and >>> provides the possibility to register additional “Client Metadata”. >>> >>> OAuth 2.0 does not define any matching algorithm for the redirect_uris. The >>> latest information on that topic I could find is [1], which is 5 years old. >>> Is there any more recent discussion about it? >>> >>> I’d suggest to add an OPTIONAL “redirect_uris_matching_method” client >>> metadata. Possible valid values could be: >>> * “exact”: The “redirect_uri" provided in a redirect-based flow must match >>> exactly one of of the provided strings in the “redirect_uris” array. >>> * “prefix”: The "redirect_uri" must begin with one of the “redirect_uris”. >>> (e.g. "http://example.com/path/subpath” would be valid with >>> [“http://example.com/path/“, “http://example.com/otherpath/”]) >>> * “regex”: The provided “redirect_uris” are threatened as regular >>> expressions, which the “redirect_uri” will be matched against. (e.g. >>> “http://subdomain.example.com/path5/“ would be valid with >>> [“^http:\\/\\/[a-z]+\\.example\\.com\\/path\\d+\\/“] >> >> I don’t know if this is appropriate. For example, If a server is unwilling >> to support arbitrary regex matching, how would a client which required this >> be able to register dynamically? Or conversely: if a client did not require >> regex matching, why would they request this from a server? >> >> If a client requests regex or prefix, it was built to rely on these to work. >> If some set of servers choose not to support regex or prefix for scope or >> security reasons, this hurts interoperability from the perspective of >> dynamic registration. And we already have a workaround - instead make your >> client rely on the state parameter. >> >> A client doing code or implicit should specify exact return URLs in their >> registration, and if they need to send the user someplace else after >> authentication it should be represented to the client by their state param. >> > > Nice workaround, but you are then making the client more difficult to > implement and the state param larger and more complex. prefix matching seems > like it would be a very common thing that an auth server supports and clients > would want to have. > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
