Subject: [OAUTH-WG] rfc6749 question about the optional use of the client_id in the request body

From: Tom Van Oppens <[email-masked]>
Date: Wed, 24 Jan 2018 10:19:33 +0000

Dear Oauth Mailing List

After some discussion i had i wanted to ask you for some guidance.

For the following request

request_uri 
https://example.com/token
request_method 
POST 
request_headers 
{"Accept":"application/json","Authorization":"Basic 
bWFnaWNpZDpwb3RhdG9zZWNyZXQ=","Content-Type":"application/x-www-form-urlencoded","Content-Length":"91"} 

request_body 
grant_type=client_credentials&scope=accounts&client_id=magicid 

We had some discussions whether or not this request is a valid request, to 
be more exact wether the clientid can be in the body.
Section 2.3.1 states 
A client MAY use the "client_id" request parameter to identify itself when 
sending requests to the token endpoint. 

But at the same time in the case of a client password (2.3.1)
The clientid and secret are carried in the basic auth header as a form of 
authentication as a preferred method ,
But the standard states that if you choose to use the body as a form of 
authentication that if you can ommit the clientsecret the clientsecret is 
an empty string, therefore passing only the client_id is the same as 
passing the client_id and an empty string clientsecret .

So the current request would be according to the spec interpreted as 
follows 
Authentication 1) basic auth cleintid:secret
Authentication 2) body auth  clientd and blank secret

You can choose to use the client_id in the body with public clients or in 
the confidential client (the Lloyds situation) if you choose to add the 
clientsecret there as well and are not using the basic auth header (this 
is due to spec section 2.3 which states 
The client MUST NOT use more than one authentication method in each 
request. 

In short there is no way in the spec that allows for the oauth provider to 
distinguish between your intention of sending in the client_id again for 
identification and a malformed request with double authentication.

So my stance is (for now) that you cannot send a clientid when you find 
yourself in the clientid with a corresponding password situation.
Is that a correct statement ?
and if it is not how would that work ?
and if it is, when can you send the clientid in the body but use something 
else for authentication  (something like mtls ?) ?

Kind Regards
Van Oppens Tom

Tenzij hierboven anders aangegeven: / Sauf indication contraire ci-dessus: 
/ Unless otherwise stated above:

International Business Machines of Belgium sprl / bvba
Siège social / Maatschappelijke zetel: Avenue du Bourget 42 Bourgetlaan, 
B-1130 Bruxelles/Brussel
N° d'entreprise / Ondernemingsnr: TVA / BTW BE 0405 912 336
RPM Bruxelles / RPR Brussel

---

From: Brian Campbell <[email-masked]>
Date: Thu, 25 Jan 2018 07:26:33 -0700

Hi Tom,

Indeed RFC 6749 is not well written with respect to this situation and
unfortunately leaves some room for varied interpretations. However, in my
own not entirely uninformed view having worked on this stuff for awhile
now, it is erroneous to interpret the presence of the client_id parameter
in the request body as client_secret_post authentication when there is no
corresponding client_secret parameter. As you alluded to, there are other
types of client authentication that explicitly allow (JWT
<https://tools.ietf.org/html/rfc7521>, SAML
<https://tools.ietf.org/html/rfc7522>, and their base spec
<https://tools.ietf.org/html/rfc7521#section-4.2>) or require (MTLS
<https://tools.ietf.org/html/draft-ietf-oauth-mtls-06>) the client_id
parameter and the OIDC core spec even has an example of the client_id
parameter in the body
<http://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication>
when doing JWT client auth. If client_id with no client_secret in the
request body actually implies client_secret_post, then those RFCs (one soon
to be RFC) and OIDF standards are all contradicting OAuth 2.0 /RFC 6749.
Those supplementary standards as well as widespread
implementations/deployments in practice should, I believe, be considered
more authoritative than one particular implementation's problematic (in
terms of interoperability) interpretation of a not particularly well
written area of the OAuth spec.

The problematic text from https://tools.ietf.org/html/rfc6749#section-2.3.1
says that "the client MAY omit the [client_secret] parameter if the client
secret is an empty string" so it would only really be reasonable for an AS
to reject a request as having two client authentication methods in the case
that it issued a client the empty string as a client secret (not a public
client but a client with an empty string as its actual secret), which
should never happen in practice, and that client sent both a basic
authorization header without a password and a client_id without a
client_secret in the body. That's one way to read it anyway. And regardless
that text in Sec 2.3.1 is problematic and should probably be updated with
an errata on RFC 6749 to get rid of the text about empty string password
and just state that the client_secret parameter is required when doing
client_secret_post authentication. Unfortunately the errata often get
overlooked but it'd still be good to have that fixed somewhere and a
published RFC can't be changed so errata is the only real option to
document the actual intent of the original specification.

The presence of the client_secret parameter should be the only thing that
implies client_secret_post authentication.

If a client_id parameter is present in conjunction with some client
authentication mechanism, then both must refer to the same client.

On Wed, Jan 24, 2018 at 3:19 AM, Tom Van Oppens <[email-masked]>
wrote:

> *request_uri*
> * request_method*
> * request_headers*
> bWFnaWNpZDpwb3RhdG9zZWNyZXQ=","Content-Type":"application/x-
> www-form-urlencoded","Content-Length":"91"}
> * request_body*
> *A client MAY use the "client_id" request parameter to identify itself
> when sending requests to the token endpoint. *
>
> clientsecret there as well and are not using the basic auth header (this is
> due to spec section 2.3 which states
> *The client MUST NOT use more than one authentication method in each
> request. *
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 26 Jan 2018 00:16:20 +0000

+1 to Brian.

I would like to point out that listing the participant in the protocol
message and the authentication of the message sender is an entirely
different thing. I see no problems in duplicating client_id in body and
header. Of course, they have to match and must fail the authentication if
they do not, but this should not be a problem. In fact, it may even be
desirable for the message body to have self-contained references to the
participants in the authentication protocol as shown in [1]. In such a
case, it will necessarily duplicate in case of the basic authentication.

[1] Basin, D., Cremers, C., Meier, S.: Provably Repairing the ISO/IEC 9798
Standard for Entity Authentication. Journal of Computer Security - Security
and Trust Principles archive Volume 21 Issue 6, 817-846 (2013)

Best,

---
Nat Sakimura

On Thu, Jan 25, 2018 at 11:28 PM Brian Campbell <[email-masked]>
wrote:

> The problematic text from
> https://tools.ietf.org/html/rfc6749#section-2.3.1 says that "the client
> MAY omit the [client_secret] parameter if the client secret is an empty
> string" so it would only really be reasonable for an AS to reject a request
> as having two client authentication methods in the case that it issued a
> client the empty string as a client secret (not a public client but a
> client with an empty string as its actual secret), which should never
> happen in practice, and that client sent both a basic authorization header
> without a password and a client_id without a client_secret in the body.
> That's one way to read it anyway. And regardless that text in Sec 2.3.1 is
> problematic and should probably be updated with an errata on RFC 6749 to
> get rid of the text about empty string password and just state that the
> client_secret parameter is required when doing client_secret_post
> authentication. Unfortunately the errata often get overlooked but it'd
> still be good to have that fixed somewhere and a published RFC can't be
> changed so errata is the only real option to document the actual intent of
> the original specification.
>
> On Wed, Jan 24, 2018 at 3:19 AM, Tom Van Oppens <[email-masked]
> > wrote:
>
>> Dear Oauth Mailing List
>>
>> We had some discussions whether or not this request is a valid request,
>> to be more exact wether the clientid can be in the body.
>> Section 2.3.1 states
>> In short there is no way in the spec that allows for the oauth provider
>> to distinguish between your intention of sending in the client_id again for
>> and if it is, when can you send the clientid in the body but use
>> something else for authentication  (something like mtls ?) ?
>>
>> Kind Regards
>> Van Oppens Tom
>>
>> Tenzij hierboven anders aangegeven: / Sauf indication contraire
>> ci-dessus: / Unless otherwise stated above:
>>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> [email-masked]
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation

---

From: Tom Van Oppens <[email-masked]>
Date: Fri, 26 Jan 2018 13:20:13 +0100

@Brian +1
 I agree that the section is confusing and that errata should be published 
about it, but before we go there it might be interesting why someone took 
the effort to describe the situation with an empty client secret, because 
including these suggestions will break the ability for an sever to dectect 
a double authentication when the client secret is an empty string

- As for the client secret not being an empty, it might be that it's 
updateable by the client.Maybe specifying that a client secret can't be an 
empty string might be the most elegant solution. 
- Secondly I couldn't find the the "If a client_id parameter is present in 
conjunction with some client authentication mechanism, then both must 
refer to the same client. " section nor can i find anywhere in the spec 
what the 

I do agree that many to be specs and implementations use the client_id in 
the body, and there are valid arguments to be made for that. But without 
errata in the OAuth2 spec they are violating the OAuth2 spec, And seeing 
the nature of it i think adding errata to the OAuth2 spec is the way to go

Do you have another suggestion to interpret the problematic section ?

@Nat
Nowhere in the spec i can find that they must match or even that the AS is 
supposed to do anything with it
When you read the specs at this point the problem is that if a client_id 
is in the body it is the same as a client_id and a secret (but a blank 
secret) and that is a double authentication when the Auth header is 
present

@all

Shoudln't we define or maybe in the OIDC spec add some information so that 
the AS needs to do something with that clien_id in the body, saying it 
must match the client_id coming in somewhere else ?
Or at least have the AS do something with it .

From:   Nat Sakimura <[email-masked]>
To:     Brian Campbell <[email-masked]>
Cc:     Tom Van Oppens <[email-masked]>, oauth <[email-masked]>
Date:   26/01/2018 01:16
Subject:        Re: [OAUTH-WG] rfc6749 question about the optional use of 
the client_id in the request body

+1 to Brian. 

[1] Basin, D., Cremers, C., Meier, S.: Provably Repairing the ISO/IEC 9798 
Standard for Entity Authentication. Journal of Computer Security - 
Security and Trust Principles archive Volume 21 Issue 6, 817-846 (2013) 

Best, 

---
Nat Sakimura

On Thu, Jan 25, 2018 at 11:28 PM Brian Campbell <
[email-masked]> wrote:
Hi Tom,

Indeed RFC 6749 is not well written with respect to this situation and 
unfortunately leaves some room for varied interpretations. However, in my 
own not entirely uninformed view having worked on this stuff for awhile 
now, it is erroneous to interpret the presence of the client_id parameter 
in the request body as client_secret_post authentication when there is no 
corresponding client_secret parameter. As you alluded to, there are other 
types of client authentication that explicitly allow (JWT, SAML, and their 
base spec) or require (MTLS) the client_id parameter and the OIDC core 
spec even has an example of the client_id parameter in the body when doing 
JWT client auth. If client_id with no client_secret in the request body 
actually implies client_secret_post, then those RFCs (one soon to be RFC) 
and OIDF standards are all contradicting OAuth 2.0 /RFC 6749. Those 
supplementary standards as well as widespread implementations/deployments 
in practice should, I believe, be considered more authoritative than one 
particular implementation's problematic (in terms of interoperability) 
interpretation of a not particularly well written area of the OAuth spec.

The problematic text from 
https://tools.ietf.org/html/rfc6749#section-2.3.1 says that "the client 
MAY omit the [client_secret] parameter if the client secret is an empty 
string" so it would only really be reasonable for an AS to reject a 
request as having two client authentication methods in the case that it 
issued a client the empty string as a client secret (not a public client 
but a client with an empty string as its actual secret), which should 
never happen in practice, and that client sent both a basic authorization 
header without a password and a client_id without a client_secret in the 
body. That's one way to read it anyway. And regardless that text in Sec 
2.3.1 is problematic and should probably be updated with an errata on RFC 
6749 to get rid of the text about empty string password and just state 
that the client_secret parameter is required when doing client_secret_post 
authentication. Unfortunately the errata often get overlooked but it'd 
still be good to have that fixed somewhere and a published RFC can't be 
changed so errata is the only real option to document the actual intent of 
the original specification.

Dear Oauth Mailing List 

request_uri 

request_body 

Kind Regards 
Van Oppens Tom

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth
-- 
Nat Sakimura
Chairman of the Board, OpenID Foundation

---

From: Brian Campbell <[email-masked]>
Date: Mon, 29 Jan 2018 12:58:18 -0700

The development of the OAuth 2.0 spec was a rather tumultuous time. That's
probably true for most standards but I think most would agree that it's
particularly true for OAuth 2.0. So trying to understand why someone took
the effort to describe the situation can be a difficult task. I looked back
in the archives to try and understand the origins of the "client MAY omit
the [client_secret] parameter if the client secret is an empty string"
text. It looks as though a few of us (myself included) were advocating to
have the client_id parameter allowed/defined at the token endpoint in
general to enable public clients to identify themselves. There was some
push back from the editor at the time that that didn't fit the model of the
spec and that instead those clients should be issued an empty secret and
that text about omitting the client secret when it is an empty string was
added to draft -21 as a compromise of sorts. It seems kind of silly looking
back at it and even then the conversation was confusing. But I don't think
that the intent of the text was ever to have the client_id parameter itself
be considered a form of authentication that would trigger an error response
when used in conjunction with another client authentication mechanism.

I don't know that particularly broad changes can be made in errata. So I'd
propose that the text around client secret in Section 2.3.1 should simply
say this:

   client_secret
         REQUIRED.  The client secret.

That should take away the potential for interpreting the presence of the
client_id parameter in the request body as client_secret_post
authentication when there is no corresponding client_secret parameter. And
more explicitly allow for other client authentication methods to use client_id
as needed (as has already happened). That does leave some ambiguity with a
client_id and http basic but doesn't consider it multiple client
authentication mechanisms so at least better allows for it. And considering
Postel's law here along with the reality that some/many clients will always
send the client_id strongly suggests that such a request not be rejected
(either ignoring the client_id in that case or checking that it is the same
as the HTTP basic username).

The example in question in the OIDC spec is using JWT client authentication
from RFC 7523 that inherits some of its base processing rules from RFC
7521, which has the following about client_id. It might be difficult to
find but I think that much is well defined at least.

   client_id
      OPTIONAL.  The client identifier as described in Section 2.2
<https://tools.ietf.org/html/rfc7521#section-2.2> of
      OAuth 2.0 [RFC6749 <https://tools.ietf.org/html/rfc6749>].  The
"client_id" is unnecessary for client
      assertion authentication because the client is identified by the
      subject of the assertion.  If present, the value of the
      "client_id" parameter MUST identify the same client as is
      identified by the client assertion.

On Fri, Jan 26, 2018 at 5:20 AM, Tom Van Oppens <[email-masked]>
wrote:

> - Secondly I couldn't find the the "If a client_id parameter is present
> in conjunction with some client authentication mechanism, then both must
> secret) and that is a double authentication when the Auth header is present
>
> @all
>
> the AS needs to do something with that clien_id in the body, saying it must
> match the client_id coming in somewhere else ?
> ------------------------------
>
>
>
> +1 to Brian.
>
> [email-masked]* <[email-masked]>> wrote:
> Hi Tom,
>
> types of client authentication that explicitly allow (*JWT*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7521&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EDy3oEPZpxW3JhWJwq89LQ66wvTze6bsNrW7kfbsIDo&m=tFxbEJbIhavKlMInYBs8JIzjD8yckAbYak3svMx0cb8&s=ltDJsK2vgDCcr3IWY5iRsp7x_QzDCvieNa9IgAZy4O0&e=>,
> *SAML*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7522&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EDy3oEPZpxW3JhWJwq89LQ66wvTze6bsNrW7kfbsIDo&m=tFxbEJbIhavKlMInYBs8JIzjD8yckAbYak3svMx0cb8&s=5t-IZXowcm7MIN20j4QOl2BxJaJxFWz-0XlKJ_X0xms&e=>,
> and *their base spec*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7521-23section-2D4.2&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EDy3oEPZpxW3JhWJwq89LQ66wvTze6bsNrW7kfbsIDo&m=tFxbEJbIhavKlMInYBs8JIzjD8yckAbYak3svMx0cb8&s=YD8pI9CXBa4So5_hCdyJdLWxtYItyJwCo9YZ8eR2DiA&e=>)
> or require (*MTLS*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Dmtls-2D06&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EDy3oEPZpxW3JhWJwq89LQ66wvTze6bsNrW7kfbsIDo&m=tFxbEJbIhavKlMInYBs8JIzjD8yckAbYak3svMx0cb8&s=2A8Zs7FE2MOm62jSvabFzu3FPNNpRiGa3iAgcIX6YJU&e=>)
> the client_id parameter and the OIDC core spec even has *an example of
> the client_id parameter in the body*
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dcore-2D1-5F0.html-23ClientAuthentication&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EDy3oEPZpxW3JhWJwq89LQ66wvTze6bsNrW7kfbsIDo&m=tFxbEJbIhavKlMInYBs8JIzjD8yckAbYak3svMx0cb8&s=RdRe04BFRix4FU47Mj3lxX9jOi29ZK2qLjn-6LB0wiQ&e=>
> *https://tools.ietf.org/html/rfc6749#section-2.3.1*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6749-23section-2D2.3.1&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EDy3oEPZpxW3JhWJwq89LQ66wvTze6bsNrW7kfbsIDo&m=tFxbEJbIhavKlMInYBs8JIzjD8yckAbYak3svMx0cb8&s=oHR04160M5ZlXvS-AxD8FIxmu7FO9yypX4XaEfM9TaI&e=>
> On Wed, Jan 24, 2018 at 3:19 AM, Tom Van Oppens <
> [email-masked]* <[email-masked]>> wrote:
> Dear Oauth Mailing List
>
> * request_uri*
> *https://example.com/token*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__example.com_token&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EDy3oEPZpxW3JhWJwq89LQ66wvTze6bsNrW7kfbsIDo&m=tFxbEJbIhavKlMInYBs8JIzjD8yckAbYak3svMx0cb8&s=UymuwhkQmfGvQJpdKAk5Q7WIUgfoVeZ5Y7efT0_zf3E&e=>
> * request_method*
> POST
> * request_headers*
> * A client MAY use the "client_id" request parameter to identify itself
> * The client MUST NOT use more than one authentication method in each
> request. *
>
> [email-masked]* <[email-masked]>
> *https://www.ietf.org/mailman/listinfo/oauth*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EDy3oEPZpxW3JhWJwq89LQ66wvTze6bsNrW7kfbsIDo&m=tFxbEJbIhavKlMInYBs8JIzjD8yckAbYak3svMx0cb8&s=vXv7xPsgwxa42v5HlNordnbr8N9H5yp848-VvYIF2j8&e=>
>
>
>
> * CONFIDENTIALITY NOTICE: This email may contain confidential and
> [email-masked]* <[email-masked]>
> *https://www.ietf.org/mailman/listinfo/oauth*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EDy3oEPZpxW3JhWJwq89LQ66wvTze6bsNrW7kfbsIDo&m=tFxbEJbIhavKlMInYBs8JIzjD8yckAbYak3svMx0cb8&s=vXv7xPsgwxa42v5HlNordnbr8N9H5yp848-VvYIF2j8&e=>
> --
>
> Nat Sakimura
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 29 Jan 2018 21:39:00 +0000

I an strongly against sending the client_id and client_secret in two places (both in the Authorization: Basic header and in the body).  That’s a standard no-no in protocol design because it creates new error cases and attacks that otherwise couldn’t exist.  (What do you do if the two values don’t match?)

RFC 6749 suggests that they should be absent from the body if present in the header.  (Yes, it’s badly written.)  We shouldn’t screw that up.

                                                       -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Monday, January 29, 2018 11:58 AM
To: Tom Van Oppens <[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] rfc6749 question about the optional use of the client_id in the request body

The development of the OAuth 2.0 spec was a rather tumultuous time. That's probably true for most standards but I think most would agree that it's particularly true for OAuth 2.0. So trying to understand why someone took the effort to describe the situation can be a difficult task. I looked back in the archives to try and understand the origins of the "client MAY omit the [client_secret] parameter if the client secret is an empty string" text. It looks as though a few of us (myself included) were advocating to have the client_id parameter allowed/defined at the token endpoint in general to enable public clients to identify themselves. There was some push back from the editor at the time that that didn't fit the model of the spec and that instead those clients should be issued an empty secret and that text about omitting the client secret when it is an empty string was added to draft -21 as a compromise of sorts. It seems kind of silly looking back at it and even then the conversation was confusing. But I don't think that the intent of the text was ever to have the client_id parameter itself be considered a form of authentication that would trigger an error response when used in conjunction with another client authentication mechanism.
I don't know that particularly broad changes can be made in errata. So I'd propose that the text around client secret in Section 2.3.1 should simply say this:

   client_secret

That should take away the potential for interpreting the presence of the client_id parameter in the request body as client_secret_post authentication when there is no corresponding client_secret parameter. And more explicitly allow for other client authentication methods to use client_id as needed (as has already happened). That does leave some ambiguity with a client_id and http basic but doesn't consider it multiple client authentication mechanisms so at least better allows for it. And considering Postel's law here along with the reality that some/many clients will always send the client_id strongly suggests that such a request not be rejected (either ignoring the client_id in that case or checking that it is the same as the HTTP basic username).
The example in question in the OIDC spec is using JWT client authentication from RFC 7523 that inherits some of its base processing rules from RFC 7521, which has the following about client_id. It might be difficult to find but I think that much is well defined at least.

   client_id

      OPTIONAL.  The client identifier as described in Section 2.2<https://tools.ietf.org/html/rfc7521#section-2.2> of

      OAuth 2.0 [RFC6749<https://tools.ietf.org/html/rfc6749>].  The "client_id" is unnecessary for client

On Fri, Jan 26, 2018 at 5:20 AM, Tom Van Oppens <[email-masked]<mailto:[email-masked]>> wrote:
@Brian +1
 I agree that the section is confusing and that errata should be published about it, but before we go there it might be interesting why someone took the effort to describe the situation with an empty client secret, because including these suggestions will break the ability for an sever to dectect a double authentication when the client secret is an empty string

- As for the client secret not being an empty, it might be that it's updateable by the client.Maybe specifying that a client secret can't be an empty string might be the most elegant solution.
- Secondly I couldn't find the the "If a client_id parameter is present in conjunction with some client authentication mechanism, then both must refer to the same client. " section nor can i find anywhere in the spec what the

I do agree that many to be specs and implementations use the client_id in the body, and there are valid arguments to be made for that. But without errata in the OAuth2 spec they are violating the OAuth2 spec, And seeing the nature of it i think adding errata to the OAuth2 spec is the way to go

@Nat
Nowhere in the spec i can find that they must match or even that the AS is supposed to do anything with it
When you read the specs at this point the problem is that if a client_id is in the body it is the same as a client_id and a secret (but a blank secret) and that is a double authentication when the Auth header is present

@all

Shoudln't we define or maybe in the OIDC spec add some information so that the AS needs to do something with that clien_id in the body, saying it must match the client_id coming in somewhere else ?
Or at least have the AS do something with it .

From:        Nat Sakimura <[email-masked]<mailto:[email-masked]>>
To:        Brian Campbell <[email-masked]<mailto:[email-masked]>>
Cc:        Tom Van Oppens <[email-masked]<mailto:[email-masked]>>, oauth <[email-masked]<mailto:[email-masked]>>
Date:        26/01/2018 01:16
Subject:        Re: [OAUTH-WG] rfc6749 question about the optional use of the client_id in the request body
________________________________

+1 to Brian.

I would like to point out that listing the participant in the protocol message and the authentication of the message sender is an entirely different thing. I see no problems in duplicating client_id in body and header. Of course, they have to match and must fail the authentication if they do not, but this should not be a problem. In fact, it may even be desirable for the message body to have self-contained references to the participants in the authentication protocol as shown in [1]. In such a case, it will necessarily duplicate in case of the basic authentication.

[1] Basin, D., Cremers, C., Meier, S.: Provably Repairing the ISO/IEC 9798 Standard for Entity Authentication. Journal of Computer Security - Security and Trust Principles archive Volume 21 Issue 6, 817-846 (2013)

Best,

---
Nat Sakimura

On Thu, Jan 25, 2018 at 11:28 PM Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tom,

Indeed RFC 6749 is not well written with respect to this situation and unfortunately leaves some room for varied interpretations. However, in my own not entirely uninformed view having worked on this stuff for awhile now, it is erroneous to interpret the presence of the client_id parameter in the request body as client_secret_post authentication when there is no corresponding client_secret parameter. As you alluded to, there are other types of client authentication that explicitly allow (JWT<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7521&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EDy3oEPZpxW3JhWJwq89LQ66wvTze6bsNrW7kfbsIDo&m=tFxbEJbIhavKlMInYBs8JIzjD8yckAbYak3svMx0cb8&s=ltDJsK2vgDCcr3IWY5iRsp7x_QzDCvieNa9IgAZy4O0&e=>, SAML<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7522&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EDy3oEPZpxW3JhWJwq89LQ66wvTze6bsNrW7kfbsIDo&m=tFxbEJbIhavKlMInYBs8JIzjD8yckAbYak3svMx0cb8&s=5t-IZXowcm7MIN20j4QOl2BxJaJxFWz-0XlKJ_X0xms&e=>, and their base spec<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7521-23section-2D4.2&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EDy3oEPZpxW3JhWJwq89LQ66wvTze6bsNrW7kfbsIDo&m=tFxbEJbIhavKlMInYBs8JIzjD8yckAbYak3svMx0cb8&s=YD8pI9CXBa4So5_hCdyJdLWxtYItyJwCo9YZ8eR2DiA&e=>) or require (MTLS<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Dmtls-2D06&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EDy3oEPZpxW3JhWJwq89LQ66wvTze6bsNrW7kfbsIDo&m=tFxbEJbIhavKlMInYBs8JIzjD8yckAbYak3svMx0cb8&s=2A8Zs7FE2MOm62jSvabFzu3FPNNpRiGa3iAgcIX6YJU&e=>) the client_id parameter and the OIDC core spec even has an example of the client_id parameter in the body<https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dcore-2D1-5F0.html-23ClientAuthentication&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EDy3oEPZpxW3JhWJwq89LQ66wvTze6bsNrW7kfbsIDo&m=tFxbEJbIhavKlMInYBs8JIzjD8yckAbYak3svMx0cb8&s=RdRe04BFRix4FU47Mj3lxX9jOi29ZK2qLjn-6LB0wiQ&e=> when doing JWT client auth. If client_id with no client_secret in the request body actually implies client_secret_post, then those RFCs (one soon to be RFC) and OIDF standards are all contradicting OAuth 2.0 /RFC 6749. Those supplementary standards as well as widespread implementations/deployments in practice should, I believe, be considered more authoritative than one particular implementation's problematic (in terms of interoperability) interpretation of a not particularly well written area of the OAuth spec.

The problematic text from https://tools.ietf.org/html/rfc6749#section-2.3.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6749-23section-2D2.3.1&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EDy3oEPZpxW3JhWJwq89LQ66wvTze6bsNrW7kfbsIDo&m=tFxbEJbIhavKlMInYBs8JIzjD8yckAbYak3svMx0cb8&s=oHR04160M5ZlXvS-AxD8FIxmu7FO9yypX4XaEfM9TaI&e=> says that "the client MAY omit the [client_secret] parameter if the client secret is an empty string" so it would only really be reasonable for an AS to reject a request as having two client authentication methods in the case that it issued a client the empty string as a client secret (not a public client but a client with an empty string as its actual secret), which should never happen in practice, and that client sent both a basic authorization header without a password and a client_id without a client_secret in the body. That's one way to read it anyway. And regardless that text in Sec 2.3.1 is problematic and should probably be updated with an errata on RFC 6749 to get rid of the text about empty string password and just state that the client_secret parameter is required when doing client_secret_post authentication. Unfortunately the errata often get overlooked but it'd still be good to have that fixed somewhere and a published RFC can't be changed so errata is the only real option to document the actual intent of the original specification.

The presence of the client_secret parameter should be the only thing that implies client_secret_post authentication.

If a client_id parameter is present in conjunction with some client authentication mechanism, then both must refer to the same client.

On Wed, Jan 24, 2018 at 3:19 AM, Tom Van Oppens <[email-masked]<mailto:[email-masked]>> wrote:
Dear Oauth Mailing List

request_uri
https://example.com/token<https://urldefense.proofpoint.com/v2/url?u=https-3A__example.com_token&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EDy3oEPZpxW3JhWJwq89LQ66wvTze6bsNrW7kfbsIDo&m=tFxbEJbIhavKlMInYBs8JIzjD8yckAbYak3svMx0cb8&s=UymuwhkQmfGvQJpdKAk5Q7WIUgfoVeZ5Y7efT0_zf3E&e=>
request_method
POST
request_headers
{"Accept":"application/json","Authorization":"Basic bWFnaWNpZDpwb3RhdG9zZWNyZXQ=","Content-Type":"application/x-www-form-urlencoded","Content-Length":"91"}
request_body
grant_type=client_credentials&scope=accounts&client_id=magicid

We had some discussions whether or not this request is a valid request, to be more exact wether the clientid can be in the body.
Section 2.3.1 states
A client MAY use the "client_id" request parameter to identify itself when sending requests to the token endpoint.

But at the same time in the case of a client password (2.3.1)
The clientid and secret are carried in the basic auth header as a form of authentication as a preferred method ,
But the standard states that if you choose to use the body as a form of authentication that if you can ommit the clientsecret the clientsecret is an empty string, therefore passing only the client_id is the same as passing the client_id and an empty string clientsecret .

So the current request would be according to the spec interpreted as follows
Authentication 1) basic auth cleintid:secret
Authentication 2) body auth  clientd and blank secret

You can choose to use the client_id in the body with public clients or in the confidential client (the Lloyds situation) if you choose to add the clientsecret there as well and are not using the basic auth header (this is due to spec section 2.3 which states
The client MUST NOT use more than one authentication method in each request.

In short there is no way in the spec that allows for the oauth provider to distinguish between your intention of sending in the client_id again for identification and a malformed request with double authentication.

So my stance is (for now) that you cannot send a clientid when you find yourself in the clientid with a corresponding password situation.
Is that a correct statement ?
and if it is not how would that work ?
and if it is, when can you send the clientid in the body but use something else for authentication  (something like mtls ?) ?

Kind Regards
Van Oppens Tom

Tenzij hierboven anders aangegeven: / Sauf indication contraire ci-dessus: / Unless otherwise stated above:

International Business Machines of Belgium sprl / bvba
Siège social / Maatschappelijke zetel: Avenue du Bourget 42 Bourgetlaan, B-1130 Bruxelles/Brussel
N° d'entreprise / Ondernemingsnr: TVA / BTW BE 0405 912 336
RPM Bruxelles / RPR Brussel
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EDy3oEPZpxW3JhWJwq89LQ66wvTze6bsNrW7kfbsIDo&m=tFxbEJbIhavKlMInYBs8JIzjD8yckAbYak3svMx0cb8&s=vXv7xPsgwxa42v5HlNordnbr8N9H5yp848-VvYIF2j8&e=>

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EDy3oEPZpxW3JhWJwq89LQ66wvTze6bsNrW7kfbsIDo&m=tFxbEJbIhavKlMInYBs8JIzjD8yckAbYak3svMx0cb8&s=vXv7xPsgwxa42v5HlNordnbr8N9H5yp848-VvYIF2j8&e=>
--

Nat Sakimura

Tenzij hierboven anders aangegeven: / Sauf indication contraire ci-dessus: / Unless otherwise stated above:

International Business Machines of Belgium sprl / bvba
Siège social / Maatschappelijke zetel: Avenue du Bourget 42 Bourgetlaan, B-1130 Bruxelles/Brussel
N° d'entreprise / Ondernemingsnr: TVA / BTW BE 0405 912 336
RPM Bruxelles / RPR Brussel

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: Brian Campbell <[email-masked]>
Date: Mon, 29 Jan 2018 14:58:19 -0700

Sending the client_id and client_secret in two places is using more than
one authentication method, which isn't allowed. I don't think anyone is
suggesting changing that.

I'm suggesting removing (in errata) the text in the client_secret
definition that says, "The client MAY omit the [client_secret] parameter if
the client secret is an empty string" because it's sometimes led to the
interpretation that the client_id parameter by itself in the body without a
client_secret parameter constitutes a form of client authentication.

On Mon, Jan 29, 2018 at 2:39 PM, Mike Jones <[email-masked]>
wrote:

> I an strongly against sending the client_id and client_secret in two
> places (both in the Authorization: Basic header and in the body).  That’s a
> standard no-no in protocol design because it creates new error cases and
> attacks that otherwise couldn’t exist.  (What do you do if the two values
> don’t match?)
>
>
>
> RFC 6749 suggests that they should be absent from the body if present in
> the header.  (Yes, it’s badly written.)  We shouldn’t screw that up.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* OAuth [mailto:[email-masked]] *On Behalf Of *Brian
> Campbell
> *Sent:* Monday, January 29, 2018 11:58 AM
> *To:* Tom Van Oppens <[email-masked]>
> *Cc:* oauth <[email-masked]>
>
> *Subject:* Re: [OAUTH-WG] rfc6749 question about the optional use of the
> client_id in the request body
>
>
>
> more explicitly allow for other client authentication methods to
> use client_id as needed (as has already happened). That does leave some
> ambiguity with a client_id and http basic but doesn't consider it multiple
> client authentication mechanisms so at least better allows for it. And
> considering Postel's law here along with the reality that some/many clients
> will always send the client_id strongly suggests that such a request not be
> rejected (either ignoring the client_id in that case or checking that it is
> the same as the HTTP basic username).
>
> The example in question in the OIDC spec is using JWT client
> authentication from RFC 7523 that inherits some of its base processing
> rules from RFC 7521, which has the following about client_id. It might be
> difficult to find but I think that much is well defined at least.
>
>    client_id
>
>       OPTIONAL.  The client identifier as described in Section 2.2 <https://tools.ietf.org/html/rfc7521#section-2.2> of
>
>       OAuth 2.0 [RFC6749 <https://tools.ietf.org/html/rfc6749>].  The "client_id" is unnecessary for client
>
> SAML
> and their base spec
> or require (MTLS
> the client_id parameter and the OIDC core spec even has an example of the
> client_id parameter in the body
> <https://maps.google.com/?q=Avenue+du+Bourget+42+Bourgetlaan,+B-1130+Bruxelles/Brussel&entry=gmail&source=g>
> <https://maps.google.com/?q=Avenue+du+Bourget+42+Bourgetlaan,+B-1130+Bruxelles/Brussel&entry=gmail&source=g>
> your computer. Thank you.*
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 29 Jan 2018 22:01:26 +0000

OK – I’m fine with that.  Thanks for the clarification, Brian.

From: Brian Campbell [mailto:[email-masked]]
Sent: Monday, January 29, 2018 1:58 PM
To: Mike Jones <[email-masked]>
Cc: Tom Van Oppens <[email-masked]>; oauth <[email-masked]>
Subject: Re: [OAUTH-WG] rfc6749 question about the optional use of the client_id in the request body

Sending the client_id and client_secret in two places is using more than one authentication method, which isn't allowed. I don't think anyone is suggesting changing that.
I'm suggesting removing (in errata) the text in the client_secret definition that says, "The client MAY omit the [client_secret] parameter if the client secret is an empty string" because it's sometimes led to the interpretation that the client_id parameter by itself in the body without a client_secret parameter constitutes a form of client authentication.

On Mon, Jan 29, 2018 at 2:39 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
I an strongly against sending the client_id and client_secret in two places (both in the Authorization: Basic header and in the body).  That’s a standard no-no in protocol design because it creates new error cases and attacks that otherwise couldn’t exist.  (What do you do if the two values don’t match?)

                                                       -- Mike

From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian Campbell
Sent: Monday, January 29, 2018 11:58 AM
To: Tom Van Oppens <[email-masked]<mailto:[email-masked]>>
Cc: oauth <[email-masked]<mailto:[email-masked]>>

   client_secret

   client_id

@Nat

@all

+1 to Brian.

Best,

---
Nat Sakimura

request_uri

Kind Regards
Van Oppens Tom

Siège social / Maatschappelijke zetel: Avenue du Bourget 42 Bourgetlaan, B-1130 Bruxelles/Brussel<https://maps.google.com/?q=Avenue+du+Bourget+42+Bourgetlaan,+B-1130+Bruxelles/Brussel&entry=gmail&source=g>

Nat Sakimura

International Business Machines of Belgium sprl / bvba
Siège social / Maatschappelijke zetel: Avenue du Bourget 42 Bourgetlaan, B-1130 Bruxelles/Brussel<https://maps.google.com/?q=Avenue+du+Bourget+42+Bourgetlaan,+B-1130+Bruxelles/Brussel&entry=gmail&source=g>
N° d'entreprise / Ondernemingsnr: TVA / BTW BE 0405 912 336
RPM Bruxelles / RPR Brussel