The change to 4.1.3 requires the endpoint to process it. At least as much as the the text for the Confidential client is requiring it.
John B. On 2012-07-02, at 5:45 PM, Anthony Nadalin wrote: > While the client may be forced to provide the client_id there are no > requirements for the endpoint to process the client_id (or how that is done) > so not sure what good the change actually does > > From: [email protected] [mailto:[email protected]] On Behalf Of > Justin Richer > Sent: Monday, July 02, 2012 8:32 AM > To: [email protected] > Subject: Re: [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3 > > I'm generally OK with the change, though it does change One problem I have > with this is that it can give a false sense of security about the information > being sent to the token endpoint and how trustworthy it is. A client_id is > public knowledge, and so someone impersonating a client on the Authentication > Endpoint could also impersonate it on the Token Endpoint just as easily. This > is not the attack that's being addressed here, and the possible phishing > vector in the one I'm describing is both well known and, I believe, well > covered by the existing documents. However, I think the new text might > confuse people into conflating these two. > > Basically, I think it needs to be made very clear, especially with this > change of text, that a client_id on its own should never be taken as > sufficient for authentication of the client. The context of the user's > decision, among other things, is as important as a client secret. > > -- Justin > > On 07/02/2012 11:17 AM, Mike Jones wrote: > I believe we should adopt this revised text. > > -- Mike > > From: [email protected] [mailto:[email protected]] On Behalf Of > John Bradley > Sent: Sunday, July 01, 2012 2:22 PM > To: [email protected] WG > Subject: [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3 > > Sec 4.1.2 states: > > The authorization code is bound to the client identifier and redirection URI. > > The security concern Sec 10.5 states > > If the client can be authenticated, the authorization servers MUST > authenticate the client and ensure that the authorization code was > issued to the same client. > > Sec 3.2.1 > A public client that was not issued a client password MAY use the > "client_id" request parameter to identify itself when sending > requests to the token endpoint (e.g. for the purpose of providing > end-user context, client usage statistics). > > Nothing in the current spec requires that a Public client send it's client_id > or redirect_uri to the token endpoint. > The client _id is only sent if it is a confidential client capable of > authenticating itself. > The redirect_uri is only sent if the 'redirect_uri' parameter was included in > the authorization request. > If the client has one registered redirect_uri it would not be sent to the > authorization or token endpoint. > > This leaves us with public clients using code flow that cannot determine if a > token was granted to them or some other public client. > > > I propose changing Sec 3.2.1 to read: > > A public client that was not issued a client password MUST use the > "client_id" request parameter to identify itself when sending > requests to the token endpoint. This allows the authorization server > to ensure that the code was issued to the same client. > Sending "client_id" prevents the client from > inadvertently accepting a code intended for a client with a different > "client_id". > > Also change Sec 4.1.3 from: > o authenticate the client if client authentication is included and > ensure the authorization code was issued to the authenticated > client, > > To: > o authenticate the client if client authentication is included, > o ensure the authorization code was issued to the authenticated > confidential client or to the public client identified by the > 'client_id', > > > > > The Original text implies that it is a good idea to send it, but is unclear > on what security it provides. > > It is a small change that should not brake existing implementations, but will > increase security for public clients using the code flow. > > Regards > John B. > > > > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
