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> 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> > 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 > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
