draft-ietf-oauth-v2-threatmodel-06.txt   draft-ietf-oauth-v2-threatmodel-07.txt 
OAuth Working Group T. Lodderstedt, Ed. OAuth Working Group T. Lodderstedt, Ed.
Internet-Draft Deutsche Telekom AG Internet-Draft Deutsche Telekom AG
Intended status: Informational M. McGloin Intended status: Informational M. McGloin
Expires: December 29, 2012 IBM Expires: February 15, 2013 IBM
P. Hunt P. Hunt
Oracle Corporation Oracle Corporation
June 27, 2012 August 14, 2012
OAuth 2.0 Threat Model and Security Considerations OAuth 2.0 Threat Model and Security Considerations
draft-ietf-oauth-v2-threatmodel-06 draft-ietf-oauth-v2-threatmodel-07
Abstract Abstract
This document gives additional security considerations for OAuth, This document gives additional security considerations for OAuth,
beyond those in the OAuth specification, based on a comprehensive beyond those in the OAuth specification, based on a comprehensive
threat model for the OAuth 2.0 Protocol. threat model for the OAuth 2.0 Protocol.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 29, 2012. This Internet-Draft will expire on February 15, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 24 skipping to change at page 3, line 24
4.4.1.6. Threat: User session impersonation . . . . . . . . 28 4.4.1.6. Threat: User session impersonation . . . . . . . . 28
4.4.1.7. Threat: Authorization code leakage through 4.4.1.7. Threat: Authorization code leakage through
counterfeit client . . . . . . . . . . . . . . . . 29 counterfeit client . . . . . . . . . . . . . . . . 29
4.4.1.8. Threat: CSRF attack against redirect-uri . . . . . 30 4.4.1.8. Threat: CSRF attack against redirect-uri . . . . . 30
4.4.1.9. Threat: Clickjacking attack against 4.4.1.9. Threat: Clickjacking attack against
authorization . . . . . . . . . . . . . . . . . . 31 authorization . . . . . . . . . . . . . . . . . . 31
4.4.1.10. Threat: Resource Owner Impersonation . . . . . . . 32 4.4.1.10. Threat: Resource Owner Impersonation . . . . . . . 32
4.4.1.11. Threat: DoS, Exhaustion of resources attacks . . . 33 4.4.1.11. Threat: DoS, Exhaustion of resources attacks . . . 33
4.4.1.12. Threat: DoS using manufactured authorization 4.4.1.12. Threat: DoS using manufactured authorization
codes . . . . . . . . . . . . . . . . . . . . . . 33 codes . . . . . . . . . . . . . . . . . . . . . . 33
4.4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . 35 4.4.1.13. Threat: Code substitution (OAuth Login) . . . . . 35
4.4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . 36
4.4.2.1. Threat: Access token leak in 4.4.2.1. Threat: Access token leak in
transport/end-points . . . . . . . . . . . . . . . 35 transport/end-points . . . . . . . . . . . . . . . 36
4.4.2.2. Threat: Access token leak in browser history . . . 35 4.4.2.2. Threat: Access token leak in browser history . . . 36
4.4.2.3. Threat: Malicious client obtains authorization . . 35 4.4.2.3. Threat: Malicious client obtains authorization . . 36
4.4.2.4. Threat: Manipulation of scripts . . . . . . . . . 36 4.4.2.4. Threat: Manipulation of scripts . . . . . . . . . 37
4.4.2.5. Threat: CSRF attack against redirect-uri . . . . . 36 4.4.2.5. Threat: CSRF attack against redirect-uri . . . . . 37
4.4.3. Resource Owner Password Credentials . . . . . . . . . 37 4.4.2.6. Threat: Token substitution (OAuth Login) . . . . . 38
4.4.3. Resource Owner Password Credentials . . . . . . . . . 39
4.4.3.1. Threat: Accidental exposure of passwords at 4.4.3.1. Threat: Accidental exposure of passwords at
client site . . . . . . . . . . . . . . . . . . . 38 client site . . . . . . . . . . . . . . . . . . . 40
4.4.3.2. Threat: Client obtains scopes without end-user 4.4.3.2. Threat: Client obtains scopes without end-user
authorization . . . . . . . . . . . . . . . . . . 38 authorization . . . . . . . . . . . . . . . . . . 40
4.4.3.3. Threat: Client obtains refresh token through 4.4.3.3. Threat: Client obtains refresh token through
automatic authorization . . . . . . . . . . . . . 39 automatic authorization . . . . . . . . . . . . . 41
4.4.3.4. Threat: Obtain user passwords on transport . . . . 39 4.4.3.4. Threat: Obtain user passwords on transport . . . . 41
4.4.3.5. Threat: Obtain user passwords from 4.4.3.5. Threat: Obtain user passwords from
authorization server database . . . . . . . . . . 39 authorization server database . . . . . . . . . . 41
4.4.3.6. Threat: Online guessing . . . . . . . . . . . . . 40 4.4.3.6. Threat: Online guessing . . . . . . . . . . . . . 42
4.4.4. Client Credentials . . . . . . . . . . . . . . . . . . 40 4.4.4. Client Credentials . . . . . . . . . . . . . . . . . . 42
4.5. Refreshing an Access Token . . . . . . . . . . . . . . . . 40 4.5. Refreshing an Access Token . . . . . . . . . . . . . . . . 42
4.5.1. Threat: Eavesdropping refresh tokens from 4.5.1. Threat: Eavesdropping refresh tokens from
authorization server . . . . . . . . . . . . . . . . . 40 authorization server . . . . . . . . . . . . . . . . . 42
4.5.2. Threat: Obtaining refresh token from authorization 4.5.2. Threat: Obtaining refresh token from authorization
server database . . . . . . . . . . . . . . . . . . . 41 server database . . . . . . . . . . . . . . . . . . . 43
4.5.3. Threat: Obtain refresh token by online guessing . . . 41 4.5.3. Threat: Obtain refresh token by online guessing . . . 43
4.5.4. Threat: Obtain refresh token phishing by 4.5.4. Threat: Obtain refresh token phishing by
counterfeit authorization server . . . . . . . . . . . 41 counterfeit authorization server . . . . . . . . . . . 43
4.6. Accessing Protected Resources . . . . . . . . . . . . . . 42
4.6.1. Threat: Eavesdropping access tokens on transport . . . 42 4.6. Accessing Protected Resources . . . . . . . . . . . . . . 44
4.6.2. Threat: Replay authorized resource server requests . . 42 4.6.1. Threat: Eavesdropping access tokens on transport . . . 44
4.6.3. Threat: Guessing access tokens . . . . . . . . . . . . 43 4.6.2. Threat: Replay authorized resource server requests . . 44
4.6.3. Threat: Guessing access tokens . . . . . . . . . . . . 45
4.6.4. Threat: Access token phishing by counterfeit 4.6.4. Threat: Access token phishing by counterfeit
resource server . . . . . . . . . . . . . . . . . . . 43 resource server . . . . . . . . . . . . . . . . . . . 45
4.6.5. Threat: Abuse of token by legitimate resource 4.6.5. Threat: Abuse of token by legitimate resource
server or client . . . . . . . . . . . . . . . . . . . 44 server or client . . . . . . . . . . . . . . . . . . . 46
4.6.6. Threat: Leak of confidential data in HTTP-Proxies . . 44 4.6.6. Threat: Leak of confidential data in HTTP-Proxies . . 46
4.6.7. Threat: Token leakage via logfiles and HTTP 4.6.7. Threat: Token leakage via logfiles and HTTP
referrers . . . . . . . . . . . . . . . . . . . . . . 44 referrers . . . . . . . . . . . . . . . . . . . . . . 46
5. Security Considerations . . . . . . . . . . . . . . . . . . . 45 5. Security Considerations . . . . . . . . . . . . . . . . . . . 47
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1.1. Confidentiality of Requests . . . . . . . . . . . . . 45 5.1.1. Confidentiality of Requests . . . . . . . . . . . . . 47
5.1.2. Server authentication . . . . . . . . . . . . . . . . 46 5.1.2. Server authentication . . . . . . . . . . . . . . . . 48
5.1.3. Always keep the resource owner informed . . . . . . . 46 5.1.3. Always keep the resource owner informed . . . . . . . 48
5.1.4. Credentials . . . . . . . . . . . . . . . . . . . . . 47 5.1.4. Credentials . . . . . . . . . . . . . . . . . . . . . 49
5.1.4.1. Credential Storage Protection . . . . . . . . . . 47 5.1.4.1. Credential Storage Protection . . . . . . . . . . 49
5.1.4.2. Online attacks on secrets . . . . . . . . . . . . 48 5.1.4.2. Online attacks on secrets . . . . . . . . . . . . 50
5.1.5. Tokens (access, refresh, code) . . . . . . . . . . . . 49 5.1.5. Tokens (access, refresh, code) . . . . . . . . . . . . 51
5.1.5.1. Limit token scope . . . . . . . . . . . . . . . . 49 5.1.5.1. Limit token scope . . . . . . . . . . . . . . . . 51
5.1.5.2. Expiration time . . . . . . . . . . . . . . . . . 50 5.1.5.2. Expiration time . . . . . . . . . . . . . . . . . 52
5.1.5.3. Short expiration time . . . . . . . . . . . . . . 50 5.1.5.3. Short expiration time . . . . . . . . . . . . . . 52
5.1.5.4. Limit number of usages/ One time usage . . . . . . 51 5.1.5.4. Limit number of usages/ One time usage . . . . . . 53
5.1.5.5. Bind tokens to a particular resource server 5.1.5.5. Bind tokens to a particular resource server
(Audience) . . . . . . . . . . . . . . . . . . . . 51 (Audience) . . . . . . . . . . . . . . . . . . . . 53
5.1.5.6. Use endpoint address as token audience . . . . . . 51 5.1.5.6. Use endpoint address as token audience . . . . . . 53
5.1.5.7. Audience and Token scopes . . . . . . . . . . . . 52 5.1.5.7. Audience and Token scopes . . . . . . . . . . . . 54
5.1.5.8. Bind token to client id . . . . . . . . . . . . . 52 5.1.5.8. Bind token to client id . . . . . . . . . . . . . 54
5.1.5.9. Signed tokens . . . . . . . . . . . . . . . . . . 52 5.1.5.9. Signed tokens . . . . . . . . . . . . . . . . . . 54
5.1.5.10. Encryption of token content . . . . . . . . . . . 52 5.1.5.10. Encryption of token content . . . . . . . . . . . 54
5.1.5.11. Assertion formats . . . . . . . . . . . . . . . . 52 5.1.5.11. Assertion formats . . . . . . . . . . . . . . . . 54
5.1.6. Access tokens . . . . . . . . . . . . . . . . . . . . 53 5.1.6. Access tokens . . . . . . . . . . . . . . . . . . . . 55
5.2. Authorization Server . . . . . . . . . . . . . . . . . . . 53 5.2. Authorization Server . . . . . . . . . . . . . . . . . . . 55
5.2.1. Authorization Codes . . . . . . . . . . . . . . . . . 53 5.2.1. Authorization Codes . . . . . . . . . . . . . . . . . 55
5.2.1.1. Automatic revocation of derived tokens if 5.2.1.1. Automatic revocation of derived tokens if
abuse is detected . . . . . . . . . . . . . . . . 53 abuse is detected . . . . . . . . . . . . . . . . 55
5.2.2. Refresh tokens . . . . . . . . . . . . . . . . . . . . 53 5.2.2. Refresh tokens . . . . . . . . . . . . . . . . . . . . 55
5.2.2.1. Restricted issuance of refresh tokens . . . . . . 53 5.2.2.1. Restricted issuance of refresh tokens . . . . . . 55
5.2.2.2. Binding of refresh token to client_id . . . . . . 53 5.2.2.2. Binding of refresh token to client_id . . . . . . 55
5.2.2.3. Refresh Token Rotation . . . . . . . . . . . . . . 54 5.2.2.3. Refresh Token Rotation . . . . . . . . . . . . . . 56
5.2.2.4. Refresh Token Revocation . . . . . . . . . . . . . 54 5.2.2.4. Refresh Token Revocation . . . . . . . . . . . . . 56
5.2.2.5. Device identification . . . . . . . . . . . . . . 54 5.2.2.5. Device identification . . . . . . . . . . . . . . 56
5.2.2.6. X-FRAME-OPTION header . . . . . . . . . . . . . . 55 5.2.2.6. X-FRAME-OPTION header . . . . . . . . . . . . . . 57
5.2.3. Client authentication and authorization . . . . . . . 55 5.2.3. Client authentication and authorization . . . . . . . 57
5.2.3.1. Don't issue secrets to client with 5.2.3.1. Don't issue secrets to client with
inappropriate security policy . . . . . . . . . . 55 inappropriate security policy . . . . . . . . . . 57
5.2.3.2. Public clients without secret require user 5.2.3.2. Public clients without secret require user
consent . . . . . . . . . . . . . . . . . . . . . 56 consent . . . . . . . . . . . . . . . . . . . . . 58
5.2.3.3. Client_id only in combination with redirect_uri . 56 5.2.3.3. Client_id only in combination with redirect_uri . 58
5.2.3.4. Installation-specific client secrets . . . . . . . 56 5.2.3.4. Installation-specific client secrets . . . . . . . 58
5.2.3.5. Validation of pre-registered redirect_uri . . . . 57 5.2.3.5. Validation of pre-registered redirect_uri . . . . 59
5.2.3.6. Client secret revocation . . . . . . . . . . . . . 58 5.2.3.6. Client secret revocation . . . . . . . . . . . . . 60
5.2.3.7. Use strong client authentication (e.g. 5.2.3.7. Use strong client authentication (e.g.
client_assertion / client_token) . . . . . . . . . 58 client_assertion / client_token) . . . . . . . . . 60
5.2.4. End-user authorization . . . . . . . . . . . . . . . . 58 5.2.4. End-user authorization . . . . . . . . . . . . . . . . 60
5.2.4.1. Automatic processing of repeated 5.2.4.1. Automatic processing of repeated
authorizations requires client validation . . . . 59 authorizations requires client validation . . . . 61
5.2.4.2. Informed decisions based on transparency . . . . . 59 5.2.4.2. Informed decisions based on transparency . . . . . 61
5.2.4.3. Validation of client properties by end-user . . . 59 5.2.4.3. Validation of client properties by end-user . . . 61
5.2.4.4. Binding of authorization code to client_id . . . . 59 5.2.4.4. Binding of authorization code to client_id . . . . 61
5.2.4.5. Binding of authorization code to redirect_uri . . 60 5.2.4.5. Binding of authorization code to redirect_uri . . 62
5.3. Client App Security . . . . . . . . . . . . . . . . . . . 60 5.3. Client App Security . . . . . . . . . . . . . . . . . . . 62
5.3.1. Don't store credentials in code or resources 5.3.1. Don't store credentials in code or resources
bundled with software packages . . . . . . . . . . . . 60 bundled with software packages . . . . . . . . . . . . 62
5.3.2. Standard web server protection measures (for 5.3.2. Standard web server protection measures (for
config files and databases) . . . . . . . . . . . . . 60 config files and databases) . . . . . . . . . . . . . 62
5.3.3. Store secrets in a secure storage . . . . . . . . . . 60 5.3.3. Store secrets in a secure storage . . . . . . . . . . 62
5.3.4. Utilize device lock to prevent unauthorized device 5.3.4. Utilize device lock to prevent unauthorized device
access . . . . . . . . . . . . . . . . . . . . . . . . 61 access . . . . . . . . . . . . . . . . . . . . . . . . 63
5.3.5. Link state parameter to user agent session . . . . . . 61 5.3.5. Link state parameter to user agent session . . . . . . 63
5.4. Resource Servers . . . . . . . . . . . . . . . . . . . . . 61 5.4. Resource Servers . . . . . . . . . . . . . . . . . . . . . 63
5.4.1. Authorization headers . . . . . . . . . . . . . . . . 61 5.4.1. Authorization headers . . . . . . . . . . . . . . . . 63
5.4.2. Authenticated requests . . . . . . . . . . . . . . . . 62 5.4.2. Authenticated requests . . . . . . . . . . . . . . . . 64
5.4.3. Signed requests . . . . . . . . . . . . . . . . . . . 62 5.4.3. Signed requests . . . . . . . . . . . . . . . . . . . 64
5.5. A Word on User Interaction and User-Installed Apps . . . . 63 5.5. A Word on User Interaction and User-Installed Apps . . . . 65
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 66
8. Informative References . . . . . . . . . . . . . . . . . . . . 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Appendix A. Document History . . . . . . . . . . . . . . . . . . 66 8.1. Informative References . . . . . . . . . . . . . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 66
Appendix A. Document History . . . . . . . . . . . . . . . . . . 68
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70
1. Introduction 1. Introduction
This document gives additional security considerations for OAuth, This document gives additional security considerations for OAuth,
beyond those in the OAuth specification, based on a comprehensive beyond those in the OAuth specification, based on a comprehensive
threat model for the OAuth 2.0 Protocol [I-D.ietf-oauth-v2]. It threat model for the OAuth 2.0 Protocol [I-D.ietf-oauth-v2]. It
contains the following content: contains the following content:
o Documents any assumptions and scope considered when creating the o Documents any assumptions and scope considered when creating the
threat model. threat model.
skipping to change at page 35, line 5 skipping to change at page 35, line 5
sign-on protocol or through local authentication, the client sign-on protocol or through local authentication, the client
should suspend the access by a user account if the number of should suspend the access by a user account if the number of
invalid authorization codes submitted by this user exceeds a invalid authorization codes submitted by this user exceeds a
certain threshold. certain threshold.
o The authorization server should send an error response to the o The authorization server should send an error response to the
client reporting an invalid authorization code and rate limit or client reporting an invalid authorization code and rate limit or
disallow connections from clients whose number of invalid requests disallow connections from clients whose number of invalid requests
exceeds a threshold. exceeds a threshold.
4.4.1.13. Threat: Code substitution (OAuth Login)
An attacker could attempt to login to an application or web site
using a victim's identity. Applications relying on identity data
provided by an OAuth protected service API to login users are
vulnerable to this threat. This pattern can be found in so-called
"social login" scenarios.
As a pre-requisite, a resource server offers an API to obtain
personal information about a user which could be interpreted as
having obtained a user identity. In this sense the client is
treating the resource server API as an "identity" API. A client
utilizes OAuth to obtain an access token for the identity API. It
then queries the identity API for an identifier and uses it to look
up its internal user account data (login). The client asssumes that
because it was able to obtain information about the user, that the
user has been authenticated.
If the client uses the grant type "code", the attacker needs to
gather a valid authorization code of the respective victim from the
same identity provider used by the target client application. The
attacker tricks the victim into login into a malicious app (which may
appear to be legitimate to the Identity Provider) using the same
identity provider as the target application. This results in the
Identity Provider's authorization server issuing an authorization
code for the respective identity API. The malicious app then sends
this code to the attacker, which in turn triggers a login process
within the target application. The attacker now manipulates the
authorization response and substitutes their code (bound to their
identity) for the victim's code. This code is then exchanged by the
client for an access token, which in turn is accepted by the identity
API since the audience, with respect to the resource server, is
correct. But since the identifier returned by the identity API is
determined by the identity in the access token (issued based on the
victim's code), the attacker is logged into the target application
under the victim's identity.
Impact: the attacker gains access to an application and user-specific
data within the application.
Countermeasures:
o All clients must indicate their client id with every request to
exchange an authorization code for an access token. The
authorization server must validate whether the particular
authorization code has been issued to the particular client. If
possible, the client shall be authenticated beforehand.
o Clients should use appropriate protocol, such as OpenID (cf.
[openid]) or SAML (cf. [OASIS.sstc-saml-bindings-1.1]) to
implement user login. Both support audience restrictions on
clients.
4.4.2. Implicit Grant 4.4.2. Implicit Grant
In the implicit grant type flow, the access token is directly In the implicit grant type flow, the access token is directly
returned to the client as a fragment part of the redirection URI. It returned to the client as a fragment part of the redirection URI. It
is assumed that the token is not sent to the redirection URI target is assumed that the token is not sent to the redirection URI target
as HTTP user agents do not send the fragment part of URIs to HTTP as HTTP user agents do not send the fragment part of URIs to HTTP
servers. Thus an attacker cannot eavesdrop the access token on this servers. Thus an attacker cannot eavesdrop the access token on this
communication path and it cannot leak through HTTP referee headers. communication path and it cannot leak through HTTP referee headers.
4.4.2.1. Threat: Access token leak in transport/end-points 4.4.2.1. Threat: Access token leak in transport/end-points
skipping to change at page 37, line 12 skipping to change at page 38, line 16
request with the redirection URI used deliver the access token. request with the redirection URI used deliver the access token.
This will ensure the client is not tricked into completing any This will ensure the client is not tricked into completing any
redirect callback unless it is linked to an authorization request redirect callback unless it is linked to an authorization request
the client initiated. The state parameter should be unguessable the client initiated. The state parameter should be unguessable
and the client should be capable of keeping the state parameter and the client should be capable of keeping the state parameter
secret. secret.
o Client developers and end-user can be educated not follow o Client developers and end-user can be educated not follow
untrusted URLs. untrusted URLs.
4.4.2.6. Threat: Token substitution (OAuth Login)
An attacker could attempt to login to an application or web site
using a victim's identity. Applications relying on identity data
provided by an OAuth protected service API to login users are
vulnerable to this threat. This pattern can be found in so-called
"social login" scenarios.
As a pre-requisite, a resource server offers an API to obtain
personal information about a user which could be interpreted as
having obtained a user identity. In this sense the client is
treating the resource server API as an "identity" API. A client
utilizes OAuth to obtain an access token for the identity API. It
then queries the identity API for an identifier and uses it to look
up its internal user account data (login). The client asssumes that
because it was able to obtain information about the user, that the
user has been authenticated.
To succeed, the attacker needs to gather a valid access token of the
respective victim from the same identity provider used by the target
client application. The attacker tricks the victim into login into a
malicious app (which may appear to be legitimate to the Identity
Provider) using the same identity provider as the target application.
This results in the Identity Provider's authorization server issuing
an access token for the respective identity API. The malicious app
then sends this access token to the attacker, which in turn triggers
a login process within the target application. The attacker now
manipulates the authorization response and substitutes their access
token (bound to their identity) for the victim's access token. This
token is accepted by the identity API since the audience, with
respect to the resource server, is correct. But since the identifier
returned by the identity API is determined by the identity in the
access token, the attacker is logged into the target application
under the victim's identity.
Impact: the attacker gains access to an application and user-specific
data within the application.
Countermeasures:
o Clients should use appropriate protocol, such as OpenID (cf.
[openid]) or SAML (cf. [OASIS.sstc-saml-bindings-1.1]) to
implement user login. Both support audience restrictions on
clients.
4.4.3. Resource Owner Password Credentials 4.4.3. Resource Owner Password Credentials
The "Resource Owner Password Credentials" grant type (see The "Resource Owner Password Credentials" grant type (see
[I-D.ietf-oauth-v2], Section 4.3), often used for legacy/migration [I-D.ietf-oauth-v2], Section 4.3), often used for legacy/migration
reasons, allows a client to request an access token using an end- reasons, allows a client to request an access token using an end-
users user-id and password along with its own credential. This grant users user-id and password along with its own credential. This grant
type has higher risk because it maintains the uid/password anti- type has higher risk because it maintains the uid/password anti-
pattern. Additionally, because the user does not have control over pattern. Additionally, because the user does not have control over
the authorization process, clients using this grant type are not the authorization process, clients using this grant type are not
limited by scope, but instead have potentially the same capabilities limited by scope, but instead have potentially the same capabilities
skipping to change at page 64, line 19 skipping to change at page 66, line 19
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
7. Acknowledgements 7. Acknowledgements
We would like to thank Stephen Farrell, Barry Leiba, Hui-Lan Lu, We would like to thank Stephen Farrell, Barry Leiba, Hui-Lan Lu,
Francisco Corella, Peifung E Lam, Shane B Weeden, Skylar Woodward, Francisco Corella, Peifung E Lam, Shane B Weeden, Skylar Woodward,
Niv Steingarten, Tim Bray, and James H. Manger for their comments and Niv Steingarten, Tim Bray, and James H. Manger for their comments and
contributions. contributions.
8. Informative References 8. References
8.1. Informative References
[I-D.ietf-oauth-v2]
Hardt, D., "The OAuth 2.0 Authorization Framework",
draft-ietf-oauth-v2-31 (work in progress), August 2012.
[I-D.ietf-oauth-v2-bearer]
Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage",
draft-ietf-oauth-v2-bearer-23 (work in progress),
August 2012.
8.2. Informative References
[I-D.gondrom-x-frame-options] [I-D.gondrom-x-frame-options]
Ross, D. and T. Gondrom, "HTTP Header X-Frame-Options", Ross, D. and T. Gondrom, "HTTP Header X-Frame-Options",
draft-gondrom-x-frame-options-00 (work in progress), draft-gondrom-x-frame-options-00 (work in progress),
March 2012. March 2012.
[I-D.ietf-oauth-assertions] [I-D.ietf-oauth-assertions]
Jones, M., Campbell, B., and Y. Goland, "OAuth 2.0 Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
Assertion Profile", draft-ietf-oauth-assertions-03 (work "Assertion Framework for OAuth 2.0",
in progress), May 2012. draft-ietf-oauth-assertions-04 (work in progress),
July 2012.
[I-D.ietf-oauth-json-web-token] [I-D.ietf-oauth-json-web-token]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", draft-ietf-oauth-json-web-token-00 (work in (JWT)", draft-ietf-oauth-json-web-token-03 (work in
progress), May 2012. progress), July 2012.
[I-D.ietf-oauth-revocation] [I-D.ietf-oauth-revocation]
Lodderstedt, T., Dronia, S., and M. Scurtescu, "Token Lodderstedt, T., Dronia, S., and M. Scurtescu, "Token
Revocation", draft-ietf-oauth-revocation-00 (work in Revocation", draft-ietf-oauth-revocation-00 (work in
progress), May 2012. progress), May 2012.
[I-D.ietf-oauth-v2]
Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth
2.0 Authorization Framework", draft-ietf-oauth-v2-28 (work
in progress), June 2012.
[I-D.ietf-oauth-v2-bearer]
Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0
Authorization Framework: Bearer Token Usage",
draft-ietf-oauth-v2-bearer-21 (work in progress),
June 2012.
[I-D.ietf-oauth-v2-http-mac] [I-D.ietf-oauth-v2-http-mac]
Hammer-Lahav, E., "HTTP Authentication: MAC Access Hammer-Lahav, E., "HTTP Authentication: MAC Access
Authentication", draft-ietf-oauth-v2-http-mac-01 (work in Authentication", draft-ietf-oauth-v2-http-mac-01 (work in
progress), February 2012. progress), February 2012.
[IMEI] 3GPP, "International Mobile station Equipment Identities [IMEI] 3GPP, "International Mobile station Equipment Identities
(IMEI)", 3GPP TS 22.016 3.3.0, July 2002. (IMEI)", 3GPP TS 22.016 3.3.0, July 2002.
[OASIS.saml-core-2.0-os] [OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, Cantor, S., Kemp, J., Philpott, R., and E. Maler,
skipping to change at page 66, line 13 skipping to change at page 68, line 19
Security and Privacy Workshop, 2010. Security and Privacy Workshop, 2010.
[gross-sec-analysis] [gross-sec-analysis]
Gross, T., "Security Analysis of the SAML Single Sign-on Gross, T., "Security Analysis of the SAML Single Sign-on
Browser/Artifact Profile, 19th Annual Computer Security Browser/Artifact Profile, 19th Annual Computer Security
Applications Conference, Las Vegas", December 2003. Applications Conference, Las Vegas", December 2003.
[iFrame] World Wide Web Consortium, "Frames in HTML documents", [iFrame] World Wide Web Consortium, "Frames in HTML documents",
W3C HTML 4.01, Dec 1999. W3C HTML 4.01, Dec 1999.
[openid] "OpenID Foundation Home Page", <http://openid.net/>.
[owasp] "Open Web Application Security Project Home Page", [owasp] "Open Web Application Security Project Home Page",
<https://www.owasp.org/>. <https://www.owasp.org/>.
[portable-contacts] [portable-contacts]
Smarr, J., "Portable Contacts 1.0 Draft C", August 2008, Smarr, J., "Portable Contacts 1.0 Draft C", August 2008,
<http://portablecontacts.net/>. <http://portablecontacts.net/>.
[ssl-latency] [ssl-latency]
Sissel, J., Ed., "SSL handshake latency and HTTPS Sissel, J., Ed., "SSL handshake latency and HTTPS
optimizations", June 2010. optimizations", June 2010.
skipping to change at page 67, line 42 skipping to change at page 70, line 4
o Synchronisation with the core's security consideration section o Synchronisation with the core's security consideration section
(UPDATE 10.12 CSRF, NEW 10.14/15) (UPDATE 10.12 CSRF, NEW 10.14/15)
o Added Resource Owner Impersonation o Added Resource Owner Impersonation
o Improved section 5 o Improved section 5
o Renamed Refresh Token Replacement to Refresh Token Rotation o Renamed Refresh Token Replacement to Refresh Token Rotation
draft-ietf-oauth-v2-threatmodel-02 draft-ietf-oauth-v2-threatmodel-02
o Incoporated Tim Bray's review comments (e.g. removed all normative o Incoporated Tim Bray's review comments (e.g. removed all normative
language) language)
draft-ietf-oauth-v2-threatmodel-03 draft-ietf-oauth-v2-threatmodel-03
o removed 2119 boilerplate and normative reference o removed 2119 boilerplate and normative reference
o incorporated shepherd review feedback o incorporated shepherd review feedback
draft-ietf-oauth-v2-threatmodel-06
o incorporated AD review feedback o incorporated AD review feedback
draft-ietf-oauth-v2-threatmodel-07
o added new section on token substituation
o made references to core and bearer normative
Authors' Addresses Authors' Addresses
Torsten Lodderstedt (editor) Torsten Lodderstedt (editor)
Deutsche Telekom AG Deutsche Telekom AG
Email: torsten@lodderstedt.net Email: torsten@lodderstedt.net
Mark McGloin Mark McGloin
IBM IBM
 End of changes. 35 change blocks. 
110 lines changed or deleted 227 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/