Apologies for the late response.
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Wednesday, June 15, 2011 1:27 PM > To: OAuth WG > Subject: [OAUTH-WG] Client authentication requirement > > 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. I would to suggest that perhaps we need a better definition of the "client" by way of identifying one or two (or three) types of clients and listing their respective security properties/capabilities. For example, if a client can/cannot keep cryptographic keys (secrets), then say so. Similarly, if a client can do TLS but cannot do proper X509 processing, then list this, etc. etc. In this way developers can at least map (in the minds) which client type matches their deployment scenario, based on the best-match capabilities list. > 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 +1 agree that client authentication (to access token endpoint) should be made a requirement. /thomas/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
