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. This is the driving design decision behind having it in there,
and from my perspective that's clear from the current text.
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. In this case the authorization step
doesn't make any sense and doing a code flow doesn't buy you any greater
security, either.
-- Justin
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
On Jul 9, 2012, at 12:08 AM, Mike Jones wrote:
A preliminary version of OAuth core draft -29 is attached for the
working group's consideration and discussion on today's call. I
believe that this addresses all issues that have been raised,
including Julian's issues about the ABNF, character sets, and form
encoding. Changes are:
* Added "MUST" to "A public client that was not issued a client
password MUST use theclient_idrequest parameter to identify
itself when sending requests to the token endpoint" and added
text explaining why this must be so.
* Added that the authorization server MUST "ensure the
authorization code was issued to the authenticated confidential
client or to the public client identified by theclient_idin the
request".
* Added Security Considerations section "Misuse of Access Token to
Impersonate Resource Owner at Public Client".
* Deleted ";charset=UTF-8" from examples formerly using
"Content-Type: application/x-www-form-urlencoded;charset=UTF-8".
* Added the phrase "and a character encoding of UTF-8" when
describing how to send requests using the HTTP request
entity-body, per Julian Reschke's suggestion.
* Added "The ABNF below is defined in terms of Unicode code points
[UNICODE5]; these characters are typically encoded in UTF-8".
* For symmetry when using HTTP Basic authentication, also apply
theapplication/x-www-form-urlencodedencoding to the client
password, just as was already done for the client identifier.
* Reduced multiple blank lines around artwork elements to single
blank lines.
* Removed Eran Hammer's name from the author list, at his request.
Dick Hardt is now listed as the editor.
Best wishes,
-- Mike
<draft-ietf-oauth-v2-29 preliminary.txt><draft-ietf-oauth-v2-29
preliminary.html><draft-ietf-oauth-v2-29
preliminary.pdf><draft-ietf-oauth-v2-29
preliminary.xml>_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
