The token endpoint can always reject it. The issue is if the client can count on it being rejected if the client_id is wrong.
If the Authorization server is allowed to not to compare the client_id to the one it issued the token to there is no point in making the change. As Justin pointed out leaving it insecure to discourage people from using this flow is also an option. This just mitigates against one attack on public clients using the code flow. At the end of the day a confidential client is going to be more secure. John B. On 2012-07-02, at 5:38 PM, Anthony Nadalin wrote: > Not sure why this has to be a MUST in section 3.2.1 as the token endpoint has > to the choice to reject it either way (provided or not) > > 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. > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
