The changes introduced in Draft 29 had unintended consequences on parts of the
spec caused by
Sec 4.3, 4.4 and 6 referencing Sec 3.2.1 as part of client authentication.
This change restricts the requirement to send client_id to only Sec 4.1.4 for
clients that are not authenticated per Sec 3.2.1
Section 3.2.1
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". This protects
the client from substitution of the authentication code. (It
provides no additional security for the protected resource.)
Change to
A client MAY use the "client_id" request parameter to identify itself
when sending requests to the token endpoint.
In the "authorization_code" grant_type request to the token endpoint,
an unauthenticated client sends "client_id" to prevent itself from
inadvertently accepting a code
intended for a client with a different "client_id". This protects
the client from substitution of the authentication code. (It
provides no additional security for the protected resource.)
** This allows any client to send client ID and explains the threat to code.
4.1.3. Access Token Request
Add
client_id
REQUIRED if the client is NOT authenticating with the
authorization server as described in Section 3.2.1
** This makes client_id only REQUIRED for the code flow if the client is not
otherwise authenticated.
Change
ensure the authorization code was issued to the authenticated
confidential client or to the public client identified by the
"client_id" in the request,
To:
ensure the authorization code was issued to the authenticated
confidential client, or if the client is public, ensure the code was
issued to "client_id" in the request,
** That removes the implication of authentication.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
