Subject: [OAUTH-WG] overreach of the scope of when client_id is required from public clients?

From: Brian Campbell <[email-masked]>
Date: Wed, 25 Jul 2012 13:07:42 -0600

In -29 the quoted text below was introduced to §3.2.1 Client
Authentication [1] to protect clients against authorization code
substitution. However, the text's placement under 3.2. Token Endpoint
[2] and some of the wording suggest that public clients must use
client_id on all requests to the token endpoint, regardless of grant
type, even though the change was introduced only to mitigate an issue
with the authentication code.

"A public client that was not issued a client password MUST use the
   "client_id" request parameter to identify itself when sending
   requests to the token endpoint.  This allows the authorization server
   to ensure that the code was issued to the same client.  Sending
   "client_id" prevents the client from inadvertently accepting a code
   intended for a client with a different "client_id".  This protects
   the client from substitution of the authentication code.  (It
   provides no additional security for the protected resource.)"

Was the change intended to be that broad? I think it goes too far.
There are cases, like extension grants and even the resource owner
credentials grant type, where it's useful to allow requests from
unidentified clients.

Could that text (or the spirit of it) be moved somewhere under the
specific sections on the Authorization Code Grant so that it only
applies to that grant type?

A somewhat related issue is the following text from §2.3. Client Authentication

 "the authorization server MUST NOT rely
   on public client authentication for the purpose of identifying the
   client."

which seems to contradict the text from  §3.2.1 above as well as the
following from 4.1.3. Access Token Request [3]

"o  ensure the authorization code was issued to the authenticated
      confidential client or to the public client identified by the
      "client_id" in the request,

Should the text in §2.3 be loosened or somehow qualified so it doesn't
read like a contradiction?

Thanks,
Brian

[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-3.2.1
[2] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-3.2
[3] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-2.3
[3] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-4.1.3

---

From: John Bradley <[email-masked]>
Date: Wed, 25 Jul 2012 15:21:04 -0700

The client_id of a public client is self asserted in the request to the token endpoint, the authorization server can reject it if it is wrong without relying on it to be correct.

I agree that the word identify in both places seems like a contradiction on the surface.

4.1.3 could be softened from 'identified by' to 'indicated by'

For your first point, are there public clients without client_id?

If so how would a user revoke access?

One reading of 4.3 step c is that the server must authenticate the client.

If the intent really is to allow totally anonymous clients then I see your point.

Thoughts from others?

John B. 

Sent from my iPad

On 2012-07-25, at 12:07 PM, Brian Campbell <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Thu, 26 Jul 2012 10:29:07 -0600

Yes, the intent is to allow totally anonymous clients. There are cases
where that is very useful and where user revocation isn't applicable
(i.e. only an access token is issued).

The changes in -29 were introduced to protect clients against
authorization code substitution. Those changes are breaking changes to
the code flow (in some cases) but it was felt that the security
benefits warranted the change even this late in the process. However,
by placing that text in §3.2.1, and having it apply to all requests to
the token endpoint, the change impacts a lot more than just the
authorization code grant and introduces breaking changes to
functionality not subject to the authorization code substitution issue
that the change was made to address.

That inadvertent breaking changes isn't just theoretical either. It
breaks https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/
and https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ -
see the example at the end of section 4 of each for requests to the
token endpoint that legitimately have no client identification. The
change also breaks features that have been available in our product
for nearly a year (and presumably other products/services
implementations as well).

I realize it's late in the process to bring this up but the
aforementioned change was also introduced very late and had a broader
impact than what was intended. I'd strongly suggest that the text in
the last paragraph of §3.2.1 be moved (and slightly adjusted for
context) into §4.1.3 right after, or as part of, the paragraph about
client authentication.  And the the last paragraph of §3.2.1 should be
reverted to what it was in -28.

At this stage I don't know how that kind of thing is best handled - an
RFC editor note? But I believe it needs to be taken care of somehow
before publication.

Thanks,
Brian

---

From: John Bradley <[email-masked]>
Date: Thu, 26 Jul 2012 09:39:19 -0700

In thinking some more about this.  Affecting grants other than code was unintentional, and due to document structure.

I will talk to Brian today and come up with some wording that could go to the RFC editor to make that clear.

John B.