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

Breno de Medeiros breno at google.com
Wed Feb 22 06:25:45 UTC 2012


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


More information about the Openid-specs-ab mailing list