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ć <[email protected] <mailto:[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.html
attack).
Thoughts?
Thanks,
Bojan
_______________________________________________
OAuth mailing list
[email protected] <mailto:[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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
