On Jul 9, 2012, at 1:21 PM, Justin Richer wrote: > Implicit grant makes perfect sense when the user agent and client are > collapsed into a single entity. In other words, if your client is inside the > user agent then doing a code flow doesn't actually buy you any extra security.
It protects the client from an attacker replacing the access token. > This is the driving design decision behind having it in there, and from my > perspective that's clear from the current text. I think the reasons for implicit flow are captured in 1.3.2, and it would be useful to point to them in 4.2 > > In a similar manner, the client credentials flow came about from collapsing > the client with the resource owner, effectively putting the resource owner > inside the client. It can be thought of like that, but that is not where it came from. > In this case the authorization step doesn't make any sense and doing a code > flow doesn't buy you any greater security, either. One can think of the client credential flow as the client already having the code and that the authorization happened out of band. No need to change any copy. On 07/09/2012 01:31 PM, Dick Hardt wrote: > Hi Mike > > Reading over the spec, I think some more color in 4.2 on the risks of the > Implicit Grant and where it makes sense and where it does not is in order. > Also, this should be in Section 9. > > Thoughts? > > -- Dick _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
