Re: [OAUTH-WG] treatment of client_id for authentication and identification

[Eran Hammer-Lahav <[e-mail]>]

This is the best way to keep the protocol simple and secure of the main use cases it explicitly addresses.

There is not clean way to introduce the client_id parameter at the token endpoint without making it confusing for developers. The problem is how do explain when to perform authentication and when to perform identification and the different trust levels in each. I have no interest in going down that road.

The current language allows you to do exactly what you want but issuing a set of password credentials and supporting the client_id/client_secret parameters. You should support the client sending an empty client_secret and omitting it when no secret is issued.

If you want, we can tweak section 2.4.1 to make client_secret optional if the secret is the empty string. That will give you exactly what you want without making the document any more confusing.

EHL

From: Torsten Lodderstedt <[e-mail]<mailto:[e-mail]>>
Date: Wed, 27 Jul 2011 11:02:18 -0700
To: Eran Hammer-lahav <[e-mail]<mailto:[e-mail]>>
Cc: Brian Campbell <[e-mail]<mailto:[e-mail]>>, oauth <[e-mail]<mailto:[e-mail]>>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification

There is no need and I don't intend to "pro-forma" issue client secrets just to conform to some text of the spec. I thought we are beyond that point.

The obvious approach would be to use the client_id the same way as it is used on the authz endpoint.

regards,
Torsten.

Am 27.07.2011 13:45, schrieb Eran Hammer-Lahav:
You just issue them a set of password credentials (which can include an empty or fixed password). There is nothing preventing you from doing that and once you do, the spec requires them to use those credentials.

EHL

From: Torsten Lodderstedt <[e-mail]<mailto:[e-mail]>>
Date: Wed, 27 Jul 2011 10:38:36 -0700
To: Eran Hammer-lahav <[e-mail]<mailto:[e-mail]>>
Cc: Brian Campbell <[e-mail]<mailto:[e-mail]>>, oauth <[e-mail]<mailto:[e-mail]>>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification

Am 27.07.2011 12:08, schrieb Eran Hammer-Lahav:
The way I've set it up in –18 is that the client_id parameter in the authorization endpoint is used to identify the client registration record. The identifier is described in section 2.3. Then in section 2.4.1 the parameter is "extended" for use with the token endpoint for client authentication when Basic is not available.

So the idea is that the only place you should be using client_id is with the authorization endpoint to reference the client registration information (needed to lookup the redirection URI). I have argued in the past that a future extension to remove the need to register clients should make this parameter optional but that's outside our current scope.

The token endpoint performs client authentication instead of "client identification" using the client identifier as username.

It can do so for confidential clients only. What about public clients using e.g. the Resource Owners Password flow? I see the need to identify them as well. For example, if the authz server issues a refresh token to such a client there must be a way to relate this token to a certain client in order to give the user a chance to revoke this specific token.

regards,
Torsten.


Hope this helps.

EHL


From: Brian Campbell <[e-mail]<mailto:[e-mail]>>
Date: Wed, 27 Jul 2011 04:32:42 -0700
To: Eran Hammer-lahav <[e-mail]<mailto:[e-mail]>>
Cc: oauth <[e-mail]<mailto:[e-mail]>>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification

Okay, looking at some of those drafts again, I see that now. Except
for -16 they are all pretty similar on client_id back to -10.
Apparently it was my misunderstanding.  Maybe I'm the only one who
doesn't get it but I do think it could be clearer.  I'd propose some
text but I'm still not fully sure I understand what is intended.

If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST
NOT or OPTIONAL to be included on token endpoint requests?

Here's a specific question/example to illustrate my continued
confusion - it would seem like the majority of clients that would use
the Resource Owner Password Credentials grant (although 4.3.2 shows
the use of HTTP Basic) would be "public" clients.  How is it expected
that such clients Identify themselves to the AS?  The client identity,
even if not something that can be strongly relied on, is useful for
things like presenting a list of access grants to the user for
revocation.



http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.3.2


On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav <[e-mail]<mailto:[e-mail]>> wrote:
Not exactly.
The current setup was pretty stable up to –15. In –16 I tried to clean it up
by moving the parameter into each token endpoint type definition. That
didn't work and was more confusing so in –17 I reverted back to the –15
approach.
What makes this stand out in –20 is that all the examples now use HTTP Basic
instead of the parameters (since we decided to make them NOT RECOMMENDED).
So it feels sudden that client_id is gone, but none of this is actually much
different from –15 on. Client authentication is still performed the same
way, and the role of client_id is just as an alternative to using HTTP Basic
on the token endpoint.
I think the current text is sufficient, but if you want to provide specific
additions I'm open to it.
EHL
From: Brian Campbell <[e-mail]<mailto:[e-mail]>>
Date: Tue, 26 Jul 2011 10:16:21 -0700
To: Eran Hammer-lahav <[e-mail]<mailto:[e-mail]>>
Cc: oauth <[e-mail]<mailto:[e-mail]>>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and
identification

I'm probably somewhat biased by having read previous version of the
spec, previous WG list discussions, and my current AS implementation
(which expects client_id) but this seems like a fairly big departure
from what was in -16.  I'm okay with the change but feel it's wroth
mentioning that it's likely an incompatible one.
That aside, I feel like it could use some more explanation in
draft-ietf-oauth-v2 because, at least to me and hence my question, it
wasn't entirely clear how client_id should be used for those cases.
On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav <[e-mail]<mailto:[e-mail]>>
wrote:

The client_id is currently only defined for password authentication on the
token endpoint. If you are using Basic or any other form of authentication
(or no authentication at all), you are not going to use the client_id
parameter.





_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>https://www.ietf.org/mailman/listinfo/oauth