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

Nat Sakimura sakimura at gmail.com
Thu Feb 23 14:51:45 UTC 2012


In the case of FB, only the way that the web server can protect itself and
the user is to send the access token to an undocumented api /app and get
the intended client_id. That is just like the check id endpoint except that
it is using access token instead: i.e., it is a Check access token
endpoint. We could define such an extension endpoint.

Nat

On Thu, Feb 23, 2012 at 10:36 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> Yes, but the Basic client profile is only using symmetric signatures.
>
> The other issues is even if the JS client can validate the signature the
> Web server still can't trust the validation,  it needs to validate the
> assertion itself before releasing any of it's resources to the client.
>
> I suppose one interesting option we haven't talked about is using the
> id_token as the access_token for additional API resources on the Client Web
> Server.
> That should work quite nicely given the id_token has the client as it's
> audience already.
>
> John B.
>
>
> On 2012-02-23, at 1:52 AM, Nat Sakimura wrote:
>
> +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
>
>
>


-- 
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/d51c9678/attachment-0001.html>


More information about the Openid-specs-ab mailing list