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

Nat Sakimura sakimura at gmail.com
Thu Sep 29 01:15:32 UTC 2011


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/20110929/3aaeff65/attachment-0001.html>


More information about the Openid-specs-ab mailing list