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

From: Bojan Živanović <[email-masked]>
Date: Sun, 28 Apr 2013 17:22:46 +0200

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

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 29 Apr 2013 11:19:50 +0200

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-masked]>

> 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
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 29 Apr 2013 12:35:49 +0100

On 29/04/13 10:19, Nat Sakimura wrote:
> Essentially, that is what OpenID Connect does with request_uri or
> request object.
>
> 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ć <[email-masked] <mailto:[email-masked]>>
>
>     Hi everyone,
>     I've written an oauth2 server for Drupal
>     (http://drupal.org/project/oauth2_server) based on the
>     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.
>
>     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).
>     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
>
>
>
>     [email-masked] <mailto:[email-masked]>