Re: [OAUTH-WG] Implicit flow, scopes, and url length limit

On 29/04/13 10:19, Nat Sakimura wrote:
> 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".
>
Should it be done in the next OAuth2 revision spec ? Seems like it's an 
OAuth2-level feature, except that a scope name would be more neutral, 
"client_registration" or similar...

Cheers, Sergey

> Best,
>
> Nat
>
>
> 2013/4/28 Bojan Živanović <bojanz@gmail.com <mailto:bojanz@gmail.com>>
>
>     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.html
>     attack).
>
>     Thoughts?
>
>     Thanks,
>     Bojan
>
>
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth