It is true that a AS cannot tell what instance of a native client it is issuing a token to via the redirect URI.
10.16 is only talking about an attack on the client based on a lack of audience information. If there is a security consideration around AS differentiating between instances of public clients that should be documented separately. It might be possible using dynamic registration to give each instance of a client a separate client_id but I don't think that is manageable if the AS needs to maintain state for each client_id. Depending on the threat we are trying to mitigate using the forthcoming Proof of Possession spec to bind tokens to specific client instances may be a solution. I think the issues need to be kept separate. John B. On Feb 4, 2014, at 3:50 PM, Prateek Mishra <prateek.mis...@oracle.com> wrote: > 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 >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
