Well, that's where this is coming from... Client registration needs to be defined, and it should be specific about the requirements for clients capable of authentication vs. not, as well as the redirection URI registration requirements for using the implicit grant type (see other message).
We need to be clear about the value of client authentication, and what does it enables us to do. The only value I know of for client authentication is when using an authorization code, it prevents others from stealing the code and using it. This enables the authorization server to present information about the client to the user with more confidence which helps the user make better decisions. But I have no idea why we need client authentication for using a refresh token? I can see the value of using client authentication with the username/password grant type, to restrict most clients from being allowed to use this flow, but at the same time, the most likely clients to use this grant type are those who cannot authentication (native applications). This is goo. EHL From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Wednesday, June 15, 2011 11:47 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Client authentication requirement 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 <e...@hueniverse.com<mailto:e...@hueniverse.com>> 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 OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
