Ok. That makes sense and in line with my other thread about implicit grant and registration.
So if a callback is not registered, we are basically at the mercy of the user not being an idiot. Seems like a good reason to require redirection URI registration for implicit grant clients. EHL From: Brian Eaton [mailto:[email protected]] Sent: Wednesday, June 15, 2011 5:29 PM To: Eran Hammer-Lahav Cc: Brian Campbell; OAuth WG Subject: Re: [OAUTH-WG] Client authentication requirement On Wed, Jun 15, 2011 at 5:21 PM, Eran Hammer-Lahav <[email protected]<mailto:[email protected]>> wrote: > I suspect another choice of words would be useful there. Implicit grants rely > on the browser's authentication of the receiving web site. When https is > used, that authentication is fairly strong. "authentication of the receiving web site"? Authentication how, and what is a receiving web site? The implicit grant relies on the presence of the user to "vouch" for the client by making the connection of how it got to the authorization server and what she is being asked to approve. In other words, the user does something that lands her in front an authorization page. If that page makes sense to her in that flow, she approves access to the party that got her there. Security for the implicit grant type comes from identifying the client based on the redirect URI. At client registration time, you bind client_id X to redirect URIs Y and Z. If the redirect URIs use HTTPs, that gives you reasonable security.
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
