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

John Bradley ve7jtb at ve7jtb.com
Wed Feb 22 18:58:50 UTC 2012


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
> 
> 

-------------- 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/20120222/9570f946/attachment.p7s>


More information about the Openid-specs-ab mailing list