[Openid-specs-ab] Does Connect support public clients?

Nat Sakimura sakimura at gmail.com
Thu Feb 23 04:52:33 UTC 2012


+1

Unlike FB Connect, we do support asymmetric signature so the signature
validation actually can be done by the JS client as well.

=nat

On Thu, Feb 23, 2012 at 4:46 AM, Mike Jones <Michael.Jones at microsoft.com>wrote:

> Let's add discussion of getting this code written to our agenda for the
> in-person working group meeting.
>
>                                -- Mike
>
> -----Original Message-----
> From: John Bradley [mailto:ve7jtb at ve7jtb.com]
> Sent: Wednesday, February 22, 2012 10:59 AM
> To: Mike Jones
> Cc: openid-specs-ab at lists.openid.net; Justin Richer
> Subject: Re: [Openid-specs-ab] Does Connect support public clients?
>
> There are two approaches we could take with the JS code.
>
> The simple one is the example code I posted earlier in the thread that the
> client puts at it redirect_uri and it takes the fragment and sends it to
> the Web server client via POST for parsing.
>
> The more complicated one would be to have the JS make the and process the
> response setting the validated id_token as a cookie and save the user_info
> attributes to HTML local storage or post them back to the Web Client.
>
> That would be the most standalone example.   Include a JS login widget and
> it will set a openID cookie once they are logged in. The Web Client just
> needs to validate the signature of the id_token.
>
> There are probably in-between states.  There is probably example code
> around for most of that, someone needs to put it together and clean it up.
>
> John  B
> On 2012-02-22, at 3:24 PM, Mike Jones wrote:
>
> > This sounds to me like an argument for us to create the JavaScript code
> so the promise of clients not having do any substantial programming to use
> Connect can come true.  That's the reason we chose the implicit flow, and
> why I think we should make it possible by getting the code written.
> >
> > The process of writing the code might also give us valuable feedback on
> the specs, while we're still at Implementer's Draft stage.
> >
> > Who would make sense to write that code?  Maybe we could use some
> directed funding to make it happen???
> >
> >                               -- Mike
> >
> > -----Original Message-----
> > From: openid-specs-ab-bounces at lists.openid.net [mailto:
> openid-specs-ab-bounces at lists.openid.net] On Behalf Of Justin Richer
> > Sent: Wednesday, February 22, 2012 6:08 AM
> > To: John Bradley
> > Cc: openid-specs-ab at lists.openid.net
> > Subject: Re: [Openid-specs-ab] Does Connect support public clients?
> >
> > The token flow is simpler *if* there's an existing corroborating server
> page with the returned javascript, which is the Facebook use case.
> > Without that existing code, as John points out, it's no simpler than the
> code, and potentially more complex to implement securely.
> >
> > -- Justin
> >
> > On 02/22/2012 08:27 AM, John Bradley wrote:
> >> It was a close decision, as I recall.  Both flows work almost equally
> well.
> >>
> >> The question was what would look simpler for a client to implement.
> >>
> >> I think the thought at the time was that we could produce a JS that
> >> someone could drop on their site and have them up and running with the
> Basic profile without significant server side programming.
> >>
> >> One thing we are missing for the current Basic profile is that drop in
> JS code example.
> >>
> >> Without the implicit example/template JS the code flow may be simper
> for server side programers to understand.
> >>
> >> John B.
> >> On 2012-02-22, at 3:25 AM, Breno de Medeiros wrote:
> >>
> >>> On Tue, Feb 21, 2012 at 07:01, John Bradley<ve7jtb at ve7jtb.com>  wrote:
> >>>> As I recall it was Facebook and Google who were keen on the implicit
> flow.
> >>> Actually, I think I suggested at least once to have 'code' be the
> >>> basic flow in OpenIDConnect. Not that I think the current approach of
> >>> using 'token' to have been a bad decision. Just that I don't have a
> >>> strong view either way.
> >>>
> >>>
> >>>> Part of the argument was that it was easier to get someone to
> >>>> implement it by dropping some JS code on their site for the callback
> >>>> URI and setting the id_token as a cookie.
> >>>>
> >>>> It is a different approach than the more traditional library one,
> >>>> that fits the code flow better.
> >>>>
> >>>> I am not personally attached to the implicit flow.
> >>>>
> >>>> However we probably need wider feedback before changing the basic
> >>>> client profile.
> >>>>
> >>>> John
> >>>>
> >>>> On 2012-02-21, at 11:43 AM, Justin Richer wrote:
> >>>>
> >>>> Yes, I certainly do. It's cleaner in design, its pattern is more
> >>>> proven, and it can be implemented in all kinds of different clients,
> >>>> even lightweight Javascript ones. The implicit flow is an
> >>>> optimization for fewer network calls, and it's always felt more like
> >>>> a codified hack than a real protocol flow to me. Whenever I've seen
> >>>> somebody pressed on the issue of whether or not their clients could
> >>>> really support the code flow, they've admitted that yes, they could,
> >>>> but they didn't want to pay the time costs of a second round trip to
> the server.
> >>>>
> >>>> We're also concentrating on the code flow for our own Connect
> >>>> deployment, and we'll patch in the implicit flow sometime later.
> >>>>
> >>>> -- Justin
> >>>>
> >>>> On 02/21/2012 09:40 AM, John Bradley wrote:
> >>>>
> >>>> No problem, sometimes even I am surprised by things that have snuck
> >>>> in or are left over from older versions.
> >>>>
> >>>> Do you still prefer the code follow for the basic client profile?
> >>>>
> >>>> John
> >>>> On 2012-02-21, at 11:23 AM, Justin Richer wrote:
> >>>>
> >>>> Hrm. Reading through the drafts again just now, it does clearly say
> >>>> that 'code' and 'token id_token' are MTI, so I'm not sure where I
> >>>> got that impression from. My mistake.
> >>>>
> >>>> -- Justin
> >>>>
> >>>> On 02/21/2012 09:14 AM, John Bradley wrote:
> >>>>
> >>>> Both code and 'token id_token'  should be mediatory to implement for
> >>>> servers.
> >>>>
> >>>> Is there a particular place that you are seeing that in the spec.  I
> think
> >>>> that is a bug, if true.   I will look for it today.
> >>>>
> >>>> If the WG did want code to be the only MTI flow then we would
> >>>> defiantly need to change the basic profile to code.
> >>>>
> >>>> John
> >>>> On 2012-02-21, at 10:47 AM, Justin Richer wrote:
> >>>>
> >>>> I would prefer to have the Basic Client use the code flow for
> >>>> another
> >>>> reason: the code flow is the only one that's mandatory to implement
> >>>> for the server. So what we have right now is advice for servers to
> >>>> implement something that our advice to clients say they don't have to.
> >>>>
> >>>> -- Justin
> >>>>
> >>>> On 02/20/2012 07:30 PM, John Bradley wrote:
> >>>>
> >>>> Torsten,
> >>>>
> >>>> From your tickets it looks like you are thinking that the Basic
> >>>> client profile is for JS clients in the browser doing canvas type
> >>>> Aps and directly accessing the check_id and user_info endpoints.
> >>>>
> >>>> The idea for what i't worth was that it is intended to be a Web
> >>>> server profile that uses the browser side implicit flow, with a
> >>>> simple sever side callback that extracts the fragment and passes it
> to the server for
> >>>> processing and verification.   That is why Cross Origin Resource
> sharing is
> >>>> not mentioned win that profile.
> >>>>
> >>>> It is true that that profile could be used for a Canvas type JS app
> >>>> in the browser accessing the endpoints as well.
> >>>>
> >>>> Would your preference have been to make the basic client use the code
> flow?
> >>>> It is arguably similar in complexity at the end of the day,  but
> >>>> with better security for Web Server type applications.
> >>>>
> >>>> I would probably just have the client base64 decode the id_token and
> forget
> >>>> calling the check_id endpoint.   If the client doesn't have the
> correct
> >>>> token endpoint and gives the client secret to it checking the
> >>>> signature on the id_token is not very useful:)
> >>>>
> >>>> Regards
> >>>> John B.
> >>>> On 2012-02-20, at 3:58 PM, Torsten Lodderstedt wrote:
> >>>>
> >>>> Hi all,
> >>>>
> >>>> I'm unable to find out whether OpenID Connect supports public
> >>>> clients. It seems Connect assumes all clients register with the OP
> >>>> and obtain a client credential. If this observation is correct, what
> >>>> is the reason for being more restrictive than OAuth?
> >>>>
> >>>> regards,
> >>>> Torsten.
> >>>> _______________________________________________
> >>>> 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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Openid-specs-ab mailing list
> >>>> Openid-specs-ab at lists.openid.net
> >>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> >>>>
> >>>
> >>>
> >>> --
> >>> --Breno
> >
> > _______________________________________________
> > 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
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120223/ca4eba70/attachment-0001.html>


More information about the Openid-specs-ab mailing list