Client authentication has been one of the main problem areas in OAuth 1.0 and 2.0 does nothing to resolve it (arguably, it makes it more confusing).
Because of the desire to allow any client type in any deployment environment, we ended up with a barely defined client authentication model. We offer password-based client authentication using HTTP Basic (and an alternative parameter), but leave it optional. It has been suggested that by doing so, we have made the protocol security hard to define and harder to implement properly. The document was written largely with the requirement to use client authentication with any request to the access token endpoint. However, it does allow unauthenticated requests in section 3. Are there any other client properties than the client's ability to authenticate with regards to security? We have one grant type without client authentication (implicit), two with optional authentication (authorization code and username/password), and one with required authentication (client credentials). I would like to go back to requiring client authentication for the access token endpoint, using HTTP Basic or other schemes. To leave the door open for clients incapable of authenticating to use the endpoint, we will add a security consideration section discussing the ramifications of using the access token endpoint without client authentication. This suggestions is linked to the topic of refresh tokens which I'll post separately. EHL
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
