Subject: [OAUTH-WG] Authz Header + client_id in message body

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 01 Aug 2013 11:34:39 +0200

Hi,

while setting up our OIDC interop tests, we run into the following 
problem:

The test client sends a request to the token endpoint, which contains 
the client credentials in an authorization header. Additionally, it adds 
the client_id to the message body. Our server treats this as an invalid 
request and responds with HTTP status code 400.

Now my question: The last paragraph of RFC 6749, section 3.1 
(http://tools.ietf.org/html/rfc6749#section-3.2.1) states

"A client MAY use the "client_id" request parameter to identify itself
    when sending requests to the token endpoint."

This seems to allow the client to send the client_id in addition to any 
other credential used to authenticate it.

I'm not sure what the intension is/was. How is the server supposed to 
handle such cases? Shall it compare both ids (from the header and the 
body)? Must they match exactly?

Any feedback is appreciated.

regards,
Torsten.

---

From: John Bradley <[email-masked]>
Date: Thu, 1 Aug 2013 14:13:03 +0200

Hmm allowing sending the client_id even if there is no authentication was intended to mitigate cases where the client presenting the code or refresh_token was not the one that requested it, and for logging.

I don't think the intention was to allow the client_id to be sent twice.  

If it were my Token endpoint I would ignore the extra one and only processes the one sent as part of the authentication,  if there is no authentication then the value of the "client_id" parameter MUST match the client_id that was used to request the token.

It is probably a open question if the request should be considered malformed if it contains both.   

Personally I would recommend that the client not do that.

Others may remember it differently.

John B.

On 2013-08-01, at 11:34 AM, Torsten Lodderstedt <[email-masked]> wrote:

> Hi,
> 
> while setting up our OIDC interop tests, we run into the following problem:
> 
> The test client sends a request to the token endpoint, which contains the client credentials in an authorization header. Additionally, it adds the client_id to the message body. Our server treats this as an invalid request and responds with HTTP status code 400.
> 
> Now my question: The last paragraph of RFC 6749, section 3.1 (http://tools.ietf.org/html/rfc6749#section-3.2.1) states
> 
> This seems to allow the client to send the client_id in addition to any other credential used to authenticate it.
> 
> I'm not sure what the intension is/was. How is the server supposed to handle such cases? Shall it compare both ids (from the header and the body)? Must they match exactly?
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Thu, 1 Aug 2013 15:57:14 +0200

I thought I remembered that text from RFC 6749, section 3.1 as saying that
a *public* client MAY use the "client_id" request parameter to identify
itself...

Apparently that's not what it says. But I believe that was the intent - hat
a client with no means of authentication could identify itself by sending
only the "client_id" request parameter to the token endpoint.

Sec 2.3 (http://tools.ietf.org/html/rfc6749#section-2.3) says, "The client
MUST NOT use more than one authentication method in each  request."

And 5.2 (http://tools.ietf.org/html/rfc6749#section-5.2) has

         "invalid_request
               The request is missing a required parameter, includes an
               unsupported parameter value (other than grant type),
               repeats a parameter,* includes multiple credentials,*
               utilizes more than one mechanism for authenticating the
               client, or is otherwise malformed."

There is some room for ambiguity in all that but, based on the above, I'd
say that the way your server is behaving is correct Torsten.

On Thu, Aug 1, 2013 at 2:13 PM, John Bradley <[email-masked]> wrote:

> Hmm allowing sending the client_id even if there is no authentication was
> intended to mitigate cases where the client presenting the code or
> refresh_token was not the one that requested it, and for logging.
>
> If it were my Token endpoint I would ignore the extra one and only
> processes the one sent as part of the authentication,  if there is no
> authentication then the value of the "client_id" parameter MUST match the
> client_id that was used to request the token.
>
> > Now my question: The last paragraph of RFC 6749, section 3.1 (
> http://tools.ietf.org/html/rfc6749#section-3.2.1) states
> >

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 17 Aug 2013 20:15:08 +0200

Hi all,

would it make sense to issue an errata and add a "public" to the 
sentence as follows?

"A _public_ client MAY use the "client_id" request parameter to identify 
itself
    when sending requests to the token endpoint."

regards,
Torsten.

Am 01.08.2013 15:57, schrieb Brian Campbell:
> I thought I remembered that text from RFC 6749, section 3.1 as saying 
> that a *public* client MAY use the "client_id" request parameter to 
> identify itself...
>
> Apparently that's not what it says. But I believe that was the intent 
> - hat a client with no means of authentication could identify itself 
> by sending only the "client_id" request parameter to the token endpoint.
>
> Sec 2.3 (http://tools.ietf.org/html/rfc6749#section-2.3) says, "The 
> client MUST NOT use more than one authentication method in each  request."
>
>                repeats a parameter,*includes multiple credentials,*
> There is some room for ambiguity in all that but, based on the above, 
> I'd say that the way your server is behaving is correct Torsten.
>
>
>
> On Thu, Aug 1, 2013 at 2:13 PM, John Bradley <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hmm allowing sending the client_id even if there is no
>     authentication was intended to mitigate cases where the client
>     presenting the code or refresh_token was not the one that
>     requested it, and for logging.
>
>     processes the one sent as part of the authentication,  if there is
>     no authentication then the value of the "client_id" parameter MUST
>     match the client_id that was used to request the token.
>
>     On 2013-08-01, at 11:34 AM, Torsten Lodderstedt
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     > Hi,
>     >
>     > The test client sends a request to the token endpoint, which
>     contains the client credentials in an authorization header.
>     Additionally, it adds the client_id to the message body. Our
>     server treats this as an invalid request and responds with HTTP
>     status code 400.
>     >
>     > This seems to allow the client to send the client_id in addition
>     to any other credential used to authenticate it.
>     >
>     > I'm not sure what the intension is/was. How is the server
>     supposed to handle such cases? Shall it compare both ids (from the
>     header and the body)? Must they match exactly?
>     >
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 22 Aug 2013 11:33:54 -0600

I so believe that was the intent and what it probably should have said. So
maybe errata makes sense?
On Aug 17, 2013 12:15 PM, "Torsten Lodderstedt" <[email-masked]>
wrote:

>  Hi all,
>
> would it make sense to issue an errata and add a "public" to the sentence
> as follows?
>
>  Apparently that's not what it says. But I believe that was the intent -
> hat a client with no means of authentication could identify itself by
> sending only the "client_id" request parameter to the token endpoint.
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 22 Aug 2013 13:38:35 -0400

+1, I believe that was the intent of the edit.

  -- Justin

On 08/22/2013 01:33 PM, Brian Campbell wrote:
>
> I so believe that was the intent and what it probably should have 
> said. So maybe errata makes sense?
>
> On Aug 17, 2013 12:15 PM, "Torsten Lodderstedt" 
>     "A _public_ client MAY use the "client_id" request parameter to
>     identify itself
>>     I thought I remembered that text from RFC 6749, section 3.1 as
>>     saying that a *public* client MAY use the "client_id" request
>>     parameter to identify itself...
>>
>>     Apparently that's not what it says. But I believe that was the
>>     intent - hat a client with no means of authentication could
>>     identify itself by sending only the "client_id" request parameter
>>     to the token endpoint.
>>
>>     Sec 2.3 (http://tools.ietf.org/html/rfc6749#section-2.3) says,
>>     "The client MUST NOT use more than one authentication method in
>>     each  request."
>>
>>     There is some room for ambiguity in all that but, based on the
>>     above, I'd say that the way your server is behaving is correct
>>     Torsten.
>>
>>
>>
>>         authentication was intended to mitigate cases where the
>>         client presenting the code or refresh_token was not the one
>>         that requested it, and for logging.
>>
>>         If it were my Token endpoint I would ignore the extra one and
>>         only processes the one sent as part of the authentication,
>>          if there is no authentication then the value of the
>>         "client_id" parameter MUST match the client_id that was used
>>         to request the token.
>>
>>         It is probably a open question if the request should be
>>         considered malformed if it contains both.
>>
>>         > The test client sends a request to the token endpoint,
>>         which contains the client credentials in an authorization
>>         header. Additionally, it adds the client_id to the message
>>         body. Our server treats this as an invalid request and
>>         responds with HTTP status code 400.
>>         >
>>         > Now my question: The last paragraph of RFC 6749, section
>>         3.1 (http://tools.ietf.org/html/rfc6749#section-3.2.1) states
>>         >
>>         > This seems to allow the client to send the client_id in
>>         addition to any other credential used to authenticate it.
>>         >
>>         supposed to handle such cases? Shall it compare both ids
>>         (from the header and the body)? Must they match exactly?
>>         >

---

From: John Bradley <[email-masked]>
Date: Thu, 22 Aug 2013 16:47:06 -0400

Yes the was the intent.

On 2013-08-22, at 1:38 PM, Justin Richer <[email-masked]> wrote:

>> I so believe that was the intent and what it probably should have said. So maybe errata makes sense?
>> On Aug 17, 2013 12:15 PM, "Torsten Lodderstedt" <[email-masked]> wrote:
>> Hi all,
>> 
>> would it make sense to issue an errata and add a "public" to the sentence as follows?
>> 
>> "A _public_ client MAY use the "client_id" request parameter to identify itself
>>> I thought I remembered that text from RFC 6749, section 3.1 as saying that a *public* client MAY use the "client_id" request parameter to identify itself...
>>> 
>>> Apparently that's not what it says. But I believe that was the intent - hat a client with no means of authentication could identify itself by sending only the "client_id" request parameter to the token endpoint. 
>>> 
>>> Sec 2.3 (http://tools.ietf.org/html/rfc6749#section-2.3) says, "The client MUST NOT use more than one authentication method in each  request."
>>> 
>>>                repeats a parameter, includes multiple credentials,
>>> There is some room for ambiguity in all that but, based on the above, I'd say that the way your server is behaving is correct Torsten. 
>>> 
>>> 
>>>