Hi Francisco,
if a token is created for access to server S1 and S2 then any party that gets access to the token can obviously access both servers. This should not be super surprising. So, if you have a deployment where you want to grant access to resources at multiple servers and the attack you describe is a concern then you need to create multiple tokens. The content of the token defines what the token can be used for. The bearer token specification does not define the content of the token and therefore it is difficult to say more about it beyond what it already says. If you think it is worth to specify highlight this type of attack then the appropriate place to describe it is the threats document. Ciao Hannes From: [email protected] [mailto:[email protected]] On Behalf Of ext Francisco Corella Sent: Wednesday, February 01, 2012 6:53 AM To: [email protected] Subject: REVISED Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0Authorization Protocol: Bearer Tokens) to Proposed Standard The bearer token protocol described in the document referenced in the subject line is vulnerable to the following attack by a malicious resource server. There are two resource servers S1 and S2, S1 hosting a resource R1, and S2 hosting a resource R2. Servers are not entitled to access resources that they do not host. S1 is malicious. The client obtains a broadly scoped access token that allows access to both resources. The client uses the access token to obtain resource R1 from server S1. Malicious server S1 then presents the access token received from the client to server S2 and gains access to resource R2, which it is not entitled to access. Including the identity of the intended recipients in the token, as recommended in Section 4.2, does not help, since the intended recipients of the broadly scoped token include both R1 and R2. Francisco
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
