That seems clear enough. Perhaps also saying something along the lines of your last sentence (saying that including the client_id only protects the client from substitution of the authorization code) would help address the concern Justin raised?
On Mon, Jul 2, 2012 at 4:15 PM, John Bradley <[email protected]> wrote: > Would this be clearer: > > ensure the authorization code was issued to the authenticated > > confidential client, or to the public client identified by the > > 'client_id' in the request, > > > The intent is always that the code must be presented by the client to which > it was issued. That is acceded by authenticating the client in the > confidential case and by inspecting the client_id in the public case. > > > Yes a client can always fake a client_id in the public case, so it is not > intended to protect the protected resource, only the client from token > substitution. > > > John B. > > > > > On 2012-07-02, at 6:02 PM, Anthony Nadalin wrote: > > I read 4.1.3 as the client_id just has to have been issued to a (or any) > public client > > From: John Bradley [mailto:[email protected]] > Sent: Monday, July 02, 2012 2:54 PM > To: Anthony Nadalin > Cc: Justin Richer; [email protected] > Subject: Re: [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3 > > 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 > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
