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

John Bradley ve7jtb at ve7jtb.com
Wed Sep 28 19:45:30 UTC 2011

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.


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/6966db79/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/6966db79/attachment-0001.p7s>

More information about the Openid-specs-ab mailing list