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."
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 <ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>> 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.
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
<tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> 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
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
