+1 Phil
On 2012-07-02, at 8:17, Mike Jones <michael.jo...@microsoft.com> wrote: > I believe we should adopt this revised text. > > -- Mike > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > John Bradley > Sent: Sunday, July 01, 2012 2:22 PM > To: oauth@ietf.org 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
