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 <eran@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
> https://www.ietf.org/mailman/listinfo/oauth
>
>