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

[John Bradley <[e-mail]>]

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 <[e-mail]> 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
> 
> "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.
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth