Also seems this is related to the topic of native/mobile clients. As I understand it, native apps using the authorization code grant/flow have been the primary motivator for keeping client authentication optional. Anonymous client have come up too.
On Wed, Jun 15, 2011 at 11:26 AM, Eran Hammer-Lahav <[email protected]>wrote: > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
