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

Nat Sakimura sakimura at gmail.com
Tue Feb 21 15:53:13 UTC 2012

Actually, after Johns blog post about the vulnerability of OAuth as
authentication, I got a strong feedback from security and privacy community
that it is insane to send the token to the server. The token was issued to
the user agent and sending that to the server constitutes security, privacy
and policy breach. If we are to avoid sending token to the server, implicit
flow is not simple any more. We have to use CORS or postMessage inter frame
communication etc.

That is another reason to consider the possibility of making the code flow
the default.

Nat Sakimura

On 2012/02/21, at 23:40, John Bradley <ve7jtb at ve7jtb.com> 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?

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

 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.

 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:


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

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?

Openid-specs-ab mailing
listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab

Openid-specs-ab mailing
listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab

Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120222/45502419/attachment-0001.html>

More information about the Openid-specs-ab mailing list