Essentially, that is what OpenID Connect does with request_uri or request object.
In OpenID Connect, a client can register the request parameters to the server before hand and get the reference to it called request_uri. Then, it can be passed to the authorization server by an extensiion parameter called request_uri. In this case, scope includes only "openid" effectively saying "look at the registered request file for the details". Best, Nat 2013/4/28 Bojan Živanović <[email protected]> > Hi everyone, > I've written an oauth2 server for Drupal ( > http://drupal.org/project/oauth2_server) based on the > https://github.com/bshaffer/oauth2-server-php PHP library. > My company is preparing a fairly large OAuth 2.0 deployment based on that > code. > > On the library level we recently discussed the problem of scopes in the > redirect urls during implicit flow. > > The URL limit is 2083 characters (imposed by Internet Explorer). > During the implicit flow, scope is passed in the URL. > If the server uses long scope names, and the client gets granted several > of those, it is possible to breach that limit (especially since the domain > name and the rest of the redirect url path is also a part of that 2083 > limit). > Has this problem been discussed previously, and what were the conclusions? > > My idea was to introduce a setting that would cause scope to not be passed > through the redirect_url in this case, so that it is later fetched through > a separate resource (we have a "tokens" resource just like GitHub, Facebook > and Google do, for getting all information about the passed token. Calling > this resource from the server side after an implicit flow allows us to > avoid the > http://homakov.blogspot.com/2012/08/oauth2-one-accesstoken-to-rule-them-all.htmlattack > ). > > Thoughts? > > Thanks, > Bojan > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
