[Openid-specs-ab] Using UserInfo EP from a Javascript Client (was: Implicit grant and javascript clients)

John Bradley ve7jtb at ve7jtb.com
Thu Sep 29 01:38:01 UTC 2011


Yes this explains some of the security issues  http://www.json-p.org/

On 2011-09-28, at 10:15 PM, Nat Sakimura wrote:

> Actually, it is not only for the privacy sake, but a security problem as well. 
> 
> JSONP is not safe to use in our use case where dynamic association may happen. 
> 
> =nat via iPhone
> 
> On 2011/09/29, at 9:29, hideki nara <hdknr at ic-tact.co.jp> wrote:
> 
>> Thank you very much John.
>> 
>> In short, there must be some essential problem in JSONP itself for handling privacy data, 
>> not  specific to using JSONP in OpenID.
>> 
>> Am I missing?
>> --
>> hdknr
>> 
>> 
>> 2011/9/29 John Bradley <ve7jtb at ve7jtb.com>
>> The RP is the one at risk.   They windup exciting JS from the IdP.  In openID Connect that may be an unknown IdP that they just registered with.
>> 
>> As I understand it if the OP returns a proper JSON-P response that is not a problem, however the IdP might return other JS that might affect the RP.
>> 
>> Now in the case of an entirely JS client in the browser, there probably isn't much interesting they could do.
>> 
>> However the general concern over having the IdP return a script stands.   Unless we are certain that it will not create a security problem we need to be cautious.
>> 
>> The specific issue was having the user-info endpoint return responses in JSON-P so that a pure JS client loaded from a different domain can access the endpoint.
>> 
>> I am hoping there are better HTML 5 ways to accomplish the same thing.
>> 
>> John
>> 
>> On 2011-09-28, at 4:31 PM, hideki nara wrote:
>> 
>>> Hi, John.
>>> 
>>> A JSONP request from a Javascript MUST includes Authorization header with a proper access_token 
>>> and Cookie header which OP has Set-Cookied when the End Use was authenticated.
>>> I'd like to know security problem around this scenario more precisely.
>>> 
>>> ---
>>> hdknr
>>> 
>>> 2011/9/28 John Bradley <ve7jtb at ve7jtb.com>
>>> I think the issue was more of a security one.
>>> 
>>> Do we really want to be responsible for having RP execute JavaScript from perhaps unknown OP?
>>> 
>>> I know there are some people working on safe JSON-P http://www.json-p.org/,  however I don't know if that is mature enough for us to include safely at this point, as it seems browser dependent.
>>> 
>>> Breno or others might be able to point to safe HTML 5 methods for doing the same thing.
>>> 
>>> John
>>> On 2011-09-28, at 5:06 AM, sakimura wrote:
>>> 
>>> > Actually, we used to have JSONP response in earlier drafts.
>>> >
>>> > It was dropped in preference of HTML5 postMessage, I think.
>>> >
>>> > =nat
>>> >
>>> > On Fri, 16 Sep 2011 14:24:13 +0200, Andreas üükre Solberg wrote:
>>> >> I'm thinking of making a proof of concept Connect client that runs in
>>> >> the browser.
>>> >>
>>> >> I cannot think of a use case where it really makes a lot of sense,
>>> >> though. What do you think?
>>> >>
>>> >> With the implicit grant flow, it is possible and pretty simple to do
>>> >> this proof of concept. You can get an access token, and the id token,
>>> >> and even verify the id token, and extract the user id. What you cannot
>>> >> do, though is access the user info service. To make the user info
>>> >> service work, the only neccessary step; was to add support for JSONP.
>>> >>
>>> >> Is there any good descriptions (concrete examples) available on what
>>> >> use cases the implicit grant flow serves?
>>> >>
>>> >> Andreas
>>> >
>>> > _______________________________________________
>>> > Openid-specs-ab mailing list
>>> > Openid-specs-ab at lists.openid.net
>>> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> 
>>> 
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> 
>>> 
>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110928/663a2dcb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110928/663a2dcb/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list