Well, the proposed correction does point to a genuine security hazard
Specifically, when client instances share the same re-direct URI,
typically mobile clients
this is independent of whether implicit or code flows are used
It is only injective clients - each of whose instances bind to unique
redirect URLs - that can support discriminative Az servers
So I would re-phrase the proposed text as:
[quote]
For public, non-injective clients, this specification does not
provide any method for the authorization server to determine what
client an access token was issued to.
[\quote]
- prateek
The text in 10.16 is correct.
This is a security consideration that has caused serious problems for Facebook
and other implementers.
In the Implicit flow there is no way for a client to know if a access token was
issued to it or another client.
The UA presenting the access token in an implicit flow may be the resource
owner but may also be any other client that has ever received an access token
for the resource.
In the implicit flow the Authorization server knows what client it has issued a
access token to via the registered redirect URI.
The change doesn't reflect the intent of the security consideration.
John B.
On Feb 4, 2014, at 1:13 PM, RFC Errata System <rfc-edi...@rfc-editor.org> wrote:
The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3880
--------------------------------------
Type: Technical
Reported by: Eriksen Costa <eriksenco...@gmail.com>
Section: 10.16
Original Text
-------------
For public clients using implicit flows, this specification does not
provide any method for the client to determine what client an access
token was issued to.
Corrected Text
--------------
For public clients using implicit flows, this specification does not
provide any method for the authorization server to determine what
client an access token was issued to.
Notes
-----
A client can only know about tokens issued to it and not for other clients.
Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.
--------------------------------------
RFC6749 (draft-ietf-oauth-v2-31)
--------------------------------------
Title : The OAuth 2.0 Authorization Framework
Publication Date : October 2012
Author(s) : D. Hardt, Ed.
Category : PROPOSED STANDARD
Source : Web Authorization Protocol
Area : Security
Stream : IETF
Verifying Party : IESG
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
