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

hideki nara hdknr at ic-tact.co.jp
Thu Sep 29 02:04:04 UTC 2011


=Nat, John,

Thank you very much for your clarification.

---
hdknr

2011/9/29 John Bradley <ve7jtb at ve7jtb.com>

> 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>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>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/>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>Openid-specs-ab at lists.openid.net
>>> > <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>>  <Openid-specs-ab at lists.openid.net>Openid-specs-ab at lists.openid.net
>>>  <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
>>> 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/20110929/3a4ec50c/attachment.html>


More information about the Openid-specs-ab mailing list