RFC 6819
OAuth 2.0 Threat Model and Security Considerations
Internet Engineering Task Force (IETF) T. Lodderstedt, Ed. Request for Comments: 6819 Deutsche Telekom AG Category: Informational M. McGloin ISSN: 2070-1721 IBM P. Hunt Oracle Corporation January 2013 OAuth 2.0 Threat Model and Security ConsiderationsAbstract
This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification, based on a comprehensive threat model for the OAuth 2.0 protocol. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6819. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................6 2. Overview ........................................................7 2.1. Scope ......................................................7 2.2. Attack Assumptions .........................................7 2.3. Architectural Assumptions ..................................8 2.3.1. Authorization Servers ...............................8 2.3.2. Resource Server .....................................9 2.3.3. Client ..............................................9 3. Security Features ...............................................9 3.1. Tokens ....................................................10 3.1.1. Scope ..............................................11 3.1.2. Limited Access Token Lifetime ......................11 3.2. Access Token ..............................................11 3.3. Refresh Token .............................................11 3.4. Authorization "code" ......................................12 3.5. Redirect URI ..............................................13 3.6. "state" Parameter .........................................13 3.7. Client Identifier .........................................13 4. Threat Model ...................................................15 4.1. Clients ...................................................16 4.1.1. Threat: Obtaining Client Secrets ...................16 4.1.2. Threat: Obtaining Refresh Tokens ...................17 4.1.3. Threat: Obtaining Access Tokens ....................19 4.1.4. Threat: End-User Credentials Phished Using Compromised or Embedded Browser ....................19 4.1.5. Threat: Open Redirectors on Client .................20 4.2. Authorization Endpoint ....................................21 4.2.1. Threat: Password Phishing by Counterfeit Authorization Server ...............................21 4.2.2. Threat: User Unintentionally Grants Too Much Access Scope ..................................21 4.2.3. Threat: Malicious Client Obtains Existing Authorization by Fraud .............................22 4.2.4. Threat: Open Redirector ............................22 4.3. Token Endpoint ............................................23 4.3.1. Threat: Eavesdropping Access Tokens ................23 4.3.2. Threat: Obtaining Access Tokens from Authorization Server Database ......................23 4.3.3. Threat: Disclosure of Client Credentials during Transmission ................................23 4.3.4. Threat: Obtaining Client Secret from Authorization Server Database ......................24 4.3.5. Threat: Obtaining Client Secret by Online Guessing .24
4.4. Obtaining Authorization ...................................25
4.4.1. Authorization "code" ...............................25
4.4.1.1. Threat: Eavesdropping or Leaking
Authorization "codes" .....................25
4.4.1.2. Threat: Obtaining Authorization "codes"
from Authorization Server Database ........26
4.4.1.3. Threat: Online Guessing of
Authorization "codes" .....................27
4.4.1.4. Threat: Malicious Client Obtains
Authorization .............................27
4.4.1.5. Threat: Authorization "code" Phishing .....29
4.4.1.6. Threat: User Session Impersonation ........29
4.4.1.7. Threat: Authorization "code" Leakage
through Counterfeit Client ................30
4.4.1.8. Threat: CSRF Attack against redirect-uri ..32
4.4.1.9. Threat: Clickjacking Attack against
Authorization .............................33
4.4.1.10. Threat: Resource Owner Impersonation .....33
4.4.1.11. Threat: DoS Attacks That Exhaust
Resources ................................34
4.4.1.12. Threat: DoS Using Manufactured
Authorization "codes" ....................35
4.4.1.13. Threat: Code Substitution (OAuth Login) ..36
4.4.2. Implicit Grant .....................................37
4.4.2.1. Threat: Access Token Leak in
Transport/Endpoints .......................37
4.4.2.2. Threat: Access Token Leak in
Browser History ...........................38
4.4.2.3. Threat: Malicious Client Obtains
Authorization .............................38
4.4.2.4. Threat: Manipulation of Scripts ...........38
4.4.2.5. Threat: CSRF Attack against redirect-uri ..39
4.4.2.6. Threat: Token Substitution (OAuth Login) ..39
4.4.3. Resource Owner Password Credentials ................40
4.4.3.1. Threat: Accidental Exposure of
Passwords at Client Site ..................41
4.4.3.2. Threat: Client Obtains Scopes
without End-User Authorization ............42
4.4.3.3. Threat: Client Obtains Refresh
Token through Automatic Authorization .....42
4.4.3.4. Threat: Obtaining User Passwords
on Transport ..............................43
4.4.3.5. Threat: Obtaining User Passwords
from Authorization Server Database ........43
4.4.3.6. Threat: Online Guessing ...................43
4.4.4. Client Credentials .................................44
4.5. Refreshing an Access Token ................................44
4.5.1. Threat: Eavesdropping Refresh Tokens from
Authorization Server ...............................44
4.5.2. Threat: Obtaining Refresh Token from
Authorization Server Database ......................44
4.5.3. Threat: Obtaining Refresh Token by Online
Guessing ...........................................45
4.5.4. Threat: Refresh Token Phishing by
Counterfeit Authorization Server ...................45
4.6. Accessing Protected Resources .............................46
4.6.1. Threat: Eavesdropping Access Tokens on Transport ...46
4.6.2. Threat: Replay of Authorized Resource
Server Requests ....................................46
4.6.3. Threat: Guessing Access Tokens .....................46
4.6.4. Threat: Access Token Phishing by
Counterfeit Resource Server ........................47
4.6.5. Threat: Abuse of Token by Legitimate
Resource Server or Client ..........................48
4.6.6. Threat: Leak of Confidential Data in HTTP Proxies ..48
4.6.7. Threat: Token Leakage via Log Files and
HTTP Referrers .....................................48
5. Security Considerations ........................................49
5.1. General ...................................................49
5.1.1. Ensure Confidentiality of Requests .................49
5.1.2. Utilize Server Authentication ......................50
5.1.3. Always Keep the Resource Owner Informed ............50
5.1.4. Credentials ........................................51
5.1.4.1. Enforce Credential Storage
Protection Best Practices .................51
5.1.4.2. Online Attacks on Secrets .................52
5.1.5. Tokens (Access, Refresh, Code) .....................53
5.1.5.1. Limit Token Scope .........................53
5.1.5.2. Determine Expiration Time .................54
5.1.5.3. Use Short Expiration Time .................54
5.1.5.4. Limit Number of Usages or One-Time Usage ..55
5.1.5.5. Bind Tokens to a Particular
Resource Server (Audience) ................55
5.1.5.6. Use Endpoint Address as Token Audience ....56
5.1.5.7. Use Explicitly Defined Scopes for
Audience and Tokens .......................56
5.1.5.8. Bind Token to Client id ...................56
5.1.5.9. Sign Self-Contained Tokens ................56
5.1.5.10. Encrypt Token Content ....................56
5.1.5.11. Adopt a Standard Assertion Format ........57
5.1.6. Access Tokens ......................................57
5.2. Authorization Server ......................................57
5.2.1. Authorization "codes" ..............................57
5.2.1.1. Automatic Revocation of Derived
Tokens If Abuse Is Detected ...............57
5.2.2. Refresh Tokens .....................................57
5.2.2.1. Restricted Issuance of Refresh Tokens .....57
5.2.2.2. Binding of Refresh Token to "client_id" ...58
5.2.2.3. Refresh Token Rotation ....................58
5.2.2.4. Revocation of Refresh Tokens ..............58
5.2.2.5. Device Identification .....................59
5.2.2.6. X-FRAME-OPTIONS Header ....................59
5.2.3. Client Authentication and Authorization ............59
5.2.3.1. Don't Issue Secrets to Clients with
Inappropriate Security Policy .............60
5.2.3.2. Require User Consent for Public
Clients without Secret ....................60
5.2.3.3. Issue a "client_id" Only in
Combination with "redirect_uri" ...........61
5.2.3.4. Issue Installation-Specific Client
Secrets ...................................61
5.2.3.5. Validate Pre-Registered "redirect_uri" ....62
5.2.3.6. Revoke Client Secrets .....................63
5.2.3.7. Use Strong Client Authentication
(e.g., client_assertion/client_token) .....63
5.2.4. End-User Authorization .............................63
5.2.4.1. Automatic Processing of Repeated
Authorizations Requires Client Validation .63
5.2.4.2. Informed Decisions Based on Transparency ..63
5.2.4.3. Validation of Client Properties by
End User ..................................64
5.2.4.4. Binding of Authorization "code" to
"client_id" ...............................64
5.2.4.5. Binding of Authorization "code" to
"redirect_uri" ............................64
5.3. Client App Security .......................................65
5.3.1. Don't Store Credentials in Code or
Resources Bundled with Software Packages ...........65
5.3.2. Use Standard Web Server Protection Measures
(for Config Files and Databases) ...................65
5.3.3. Store Secrets in Secure Storage ....................65
5.3.4. Utilize Device Lock to Prevent Unauthorized
Device Access ......................................66
5.3.5. Link the "state" Parameter to User Agent Session ...66
5.4. Resource Servers ..........................................66
5.4.1. Authorization Headers ..............................66
5.4.2. Authenticated Requests .............................67
5.4.3. Signed Requests ....................................67
5.5. A Word on User Interaction and User-Installed Apps ........68
6. Acknowledgements ...............................................69 7. References .....................................................69 7.1. Normative References ......................................69 7.2. Informative References ....................................691. Introduction
This document gives additional security considerations for OAuth, beyond those in the OAuth specification, based on a comprehensive threat model for the OAuth 2.0 protocol [RFC6749]. It contains the following content: o Documents any assumptions and scope considered when creating the threat model. o Describes the security features built into the OAuth protocol and how they are intended to thwart attacks. o Gives a comprehensive threat model for OAuth and describes the respective countermeasures to thwart those threats. Threats include any intentional attacks on OAuth tokens and resources protected by OAuth tokens, as well as security risks introduced if the proper security measures are not put in place. Threats are structured along the lines of the protocol structure to help development teams implement each part of the protocol securely, for example, all threats for granting access, or all threats for a particular grant type, or all threats for protecting the resource server. Note: This document cannot assess the probability or the risk associated with a particular threat because those aspects strongly depend on the particular application and deployment OAuth is used to protect. Similarly, impacts are given on a rather abstract level. But the information given here may serve as a foundation for deployment-specific threat models. Implementors may refine and detail the abstract threat model in order to account for the specific properties of their deployment and to come up with a risk analysis. As this document is based on the base OAuth 2.0 specification, it does not consider proposed extensions such as client registration or discovery, many of which are still under discussion.
2. Overview
2.1. Scope
This security considerations document only considers clients bound to a particular deployment as supported by [RFC6749]. Such deployments have the following characteristics: o Resource server URLs are static and well-known at development time; authorization server URLs can be static or discovered. o Token scope values (e.g., applicable URLs and methods) are well- known at development time. o Client registration is out of scope of the current core specification. Therefore, this document assumes a broad variety of options, from static registration during development time to dynamic registration at runtime. The following are considered out of scope: o Communication between the authorization server and resource server. o Token formats. o Except for the resource owner password credentials grant type (see [RFC6749], Section 4.3), the mechanism used by authorization servers to authenticate the user. o Mechanism by which a user obtained an assertion and any resulting attacks mounted as a result of the assertion being false. o Clients not bound to a specific deployment: An example could be a mail client with support for contact list access via the portable contacts API (see [Portable-Contacts]). Such clients cannot be registered upfront with a particular deployment and should dynamically discover the URLs relevant for the OAuth protocol.2.2. Attack Assumptions
The following assumptions relate to an attacker and resources available to an attacker. It is assumed that: o the attacker has full access to the network between the client and authorization servers and the client and the resource server, respectively. The attacker may eavesdrop on any communications
between those parties. He is not assumed to have access to
communication between the authorization server and resource
server.
o an attacker has unlimited resources to mount an attack.
o two of the three parties involved in the OAuth protocol may
collude to mount an attack against the 3rd party. For example,
the client and authorization server may be under control of an
attacker and collude to trick a user to gain access to resources.
2.3. Architectural Assumptions
This section documents assumptions about the features, limitations,
and design options of the different entities of an OAuth deployment
along with the security-sensitive data elements managed by those
entities. These assumptions are the foundation of the threat
analysis.
The OAuth protocol leaves deployments with a certain degree of
freedom regarding how to implement and apply the standard. The core
specification defines the core concepts of an authorization server
and a resource server. Both servers can be implemented in the same
server entity, or they may also be different entities. The latter is
typically the case for multi-service providers with a single
authentication and authorization system and is more typical in
middleware architectures.
2.3.1. Authorization Servers
The following data elements are stored or accessible on the
authorization server:
o usernames and passwords
o client ids and secrets
o client-specific refresh tokens
o client-specific access tokens (in the case of handle-based design;
see Section 3.1)
o HTTPS certificate/key
o per-authorization process (in the case of handle-based design;
Section 3.1): "redirect_uri", "client_id", authorization "code"
2.3.2. Resource Server
The following data elements are stored or accessible on the resource server: o user data (out of scope) o HTTPS certificate/key o either authorization server credentials (handle-based design; see Section 3.1) or authorization server shared secret/public key (assertion-based design; see Section 3.1) o access tokens (per request) It is assumed that a resource server has no knowledge of refresh tokens, user passwords, or client secrets.2.3.3. Client
In OAuth, a client is an application making protected resource requests on behalf of the resource owner and with its authorization. There are different types of clients with different implementation and security characteristics, such as web, user-agent-based, and native applications. A full definition of the different client types and profiles is given in [RFC6749], Section 2.1. The following data elements are stored or accessible on the client: o client id (and client secret or corresponding client credential) o one or more refresh tokens (persistent) and access tokens (transient) per end user or other security-context or delegation context o trusted certification authority (CA) certificates (HTTPS) o per-authorization process: "redirect_uri", authorization "code"3. Security Features
These are some of the security features that have been built into the OAuth 2.0 protocol to mitigate attacks and security issues.
3.1. Tokens
OAuth makes extensive use of many kinds of tokens (access tokens, refresh tokens, authorization "codes"). The information content of a token can be represented in two ways, as follows: Handle (or artifact) A 'handle' is a reference to some internal data structure within the authorization server; the internal data structure contains the attributes of the token, such as user id (UID), scope, etc. Handles enable simple revocation and do not require cryptographic mechanisms to protect token content from being modified. On the other hand, handles require communication between the issuing and consuming entity (e.g., the authorization server and resource server) in order to validate the token and obtain token-bound data. This communication might have a negative impact on performance and scalability if both entities reside on different systems. Handles are therefore typically used if the issuing and consuming entity are the same. A 'handle' token is often referred to as an 'opaque' token because the resource server does not need to be able to interpret the token directly; it simply uses the token. Assertion (aka self-contained token) An assertion is a parseable token. An assertion typically has a duration, has an audience, and is digitally signed in order to ensure data integrity and origin authentication. It contains information about the user and the client. Examples of assertion formats are Security Assertion Markup Language (SAML) assertions [OASIS.saml-core-2.0-os] and Kerberos tickets [RFC4120]. Assertions can typically be directly validated and used by a resource server without interactions with the authorization server. This results in better performance and scalability in deployments where the issuing and consuming entities reside on different systems. Implementing token revocation is more difficult with assertions than with handles. Tokens can be used in two ways to invoke requests on resource servers, as follows: bearer token A 'bearer token' is a token that can be used by any client who has received the token (e.g., [RFC6750]). Because mere possession is enough to use the token, it is important that communication between endpoints be secured to ensure that only authorized endpoints may capture the token. The bearer token is convenient for client applications, as it does not require them to do anything to use them (such as a proof of identity). Bearer tokens have similar characteristics to web single-sign-on (SSO) cookies used in browsers.
proof token A 'proof token' is a token that can only be used by a
specific client. Each use of the token requires the client to
perform some action that proves that it is the authorized user of
the token. Examples of this are MAC-type access tokens, which
require the client to digitally sign the resource request with a
secret corresponding to the particular token sent with the request
(e.g., [OAuth-HTTP-MAC]).
3.1.1. Scope
A scope represents the access authorization associated with a
particular token with respect to resource servers, resources, and
methods on those resources. Scopes are the OAuth way to explicitly
manage the power associated with an access token. A scope can be
controlled by the authorization server and/or the end user in order
to limit access to resources for OAuth clients that these parties
deem less secure or trustworthy. Optionally, the client can request
the scope to apply to the token but only for a lesser scope than
would otherwise be granted, e.g., to reduce the potential impact if
this token is sent over non-secure channels. A scope is typically
complemented by a restriction on a token's lifetime.
3.1.2. Limited Access Token Lifetime
The protocol parameter "expires_in" allows an authorization server
(based on its policies or on behalf of the end user) to limit the
lifetime of an access token and to pass this information to the
client. This mechanism can be used to issue short-lived tokens to
OAuth clients that the authorization server deems less secure, or
where sending tokens over non-secure channels.
3.2. Access Token
An access token is used by a client to access a resource. Access
tokens typically have short life spans (minutes or hours) that cover
typical session lifetimes. An access token may be refreshed through
the use of a refresh token. The short lifespan of an access token,
in combination with the usage of refresh tokens, enables the
possibility of passive revocation of access authorization on the
expiry of the current access token.
3.3. Refresh Token
A refresh token represents a long-lasting authorization of a certain
client to access resources on behalf of a resource owner. Such
tokens are exchanged between the client and authorization server
only. Clients use this kind of token to obtain ("refresh") new
access tokens used for resource server invocations.
A refresh token, coupled with a short access token lifetime, can be
used to grant longer access to resources without involving end-user
authorization. This offers an advantage where resource servers and
authorization servers are not the same entity, e.g., in a distributed
environment, as the refresh token is always exchanged at the
authorization server. The authorization server can revoke the
refresh token at any time, causing the granted access to be revoked
once the current access token expires. Because of this, a short
access token lifetime is important if timely revocation is a high
priority.
The refresh token is also a secret bound to the client identifier and
client instance that originally requested the authorization; the
refresh token also represents the original resource owner grant.
This is ensured by the authorization process as follows:
1. The resource owner and user agent safely deliver the
authorization "code" to the client instance in the first place.
2. The client uses it immediately in secure transport-level
communications to the authorization server and then securely
stores the long-lived refresh token.
3. The client always uses the refresh token in secure transport-
level communications to the authorization server to get an access
token (and optionally roll over the refresh token).
So, as long as the confidentiality of the particular token can be
ensured by the client, a refresh token can also be used as an
alternative means to authenticate the client instance itself.
3.4. Authorization "code"
An authorization "code" represents the intermediate result of a
successful end-user authorization process and is used by the client
to obtain access and refresh tokens. Authorization "codes" are sent
to the client's redirect URI instead of tokens for two purposes:
1. Browser-based flows expose protocol parameters to potential
attackers via URI query parameters (HTTP referrer), the browser
cache, or log file entries, and could be replayed. In order to
reduce this threat, short-lived authorization "codes" are passed
instead of tokens and exchanged for tokens over a more secure
direct connection between the client and the authorization
server.
2. It is much simpler to authenticate clients during the direct
request between the client and the authorization server than in
the context of the indirect authorization request. The latter
would require digital signatures.
3.5. Redirect URI
A redirect URI helps to detect malicious clients and prevents
phishing attacks from clients attempting to trick the user into
believing the phisher is the client. The value of the actual
redirect URI used in the authorization request has to be presented
and is verified when an authorization "code" is exchanged for tokens.
This helps to prevent attacks where the authorization "code" is
revealed through redirectors and counterfeit web application clients.
The authorization server should require public clients and
confidential clients using the implicit grant type to pre-register
their redirect URIs and validate against the registered redirect URI
in the authorization request.
3.6. "state" Parameter
The "state" parameter is used to link requests and callbacks to
prevent cross-site request forgery attacks (see Section 4.4.1.8)
where an attacker authorizes access to his own resources and then
tricks a user into following a redirect with the attacker's token.
This parameter should bind to the authenticated state in a user agent
and, as per the core OAuth spec, the user agent must be capable of
keeping it in a location accessible only by the client and user
agent, i.e., protected by same-origin policy.
3.7. Client Identifier
Authentication protocols have typically not taken into account the
identity of the software component acting on behalf of the end user.
OAuth does this in order to increase the security level in delegated
authorization scenarios and because the client will be able to act
without the user being present.
OAuth uses the client identifier to collate associated requests to
the same originator, such as
o a particular end-user authorization process and the corresponding
request on the token's endpoint to exchange the authorization
"code" for tokens, or
o the initial authorization and issuance of a token by an end user
to a particular client, and subsequent requests by this client to
obtain tokens without user consent (automatic processing of
repeated authorizations)
This identifier may also be used by the authorization server to
display relevant registration information to a user when requesting
consent for a scope requested by a particular client. The client
identifier may be used to limit the number of requests for a
particular client or to charge the client per request. It may
furthermore be useful to differentiate access by different clients,
e.g., in server log files.
OAuth defines two client types, confidential and public, based on
their ability to authenticate with the authorization server (i.e.,
ability to maintain the confidentiality of their client credentials).
Confidential clients are capable of maintaining the confidentiality
of client credentials (i.e., a client secret associated with the
client identifier) or capable of secure client authentication using
other means, such as a client assertion (e.g., SAML) or key
cryptography. The latter is considered more secure.
The authorization server should determine whether the client is
capable of keeping its secret confidential or using secure
authentication. Alternatively, the end user can verify the identity
of the client, e.g., by only installing trusted applications. The
redirect URI can be used to prevent the delivery of credentials to a
counterfeit client after obtaining end-user authorization in some
cases but can't be used to verify the client identifier.
Clients can be categorized as follows based on the client type,
profile (e.g., native vs. web application; see [RFC6749], Section 9),
and deployment model:
Deployment-independent "client_id" with pre-registered "redirect_uri"
and without "client_secret" Such an identifier is used by
multiple installations of the same software package. The
identifier of such a client can only be validated with the help of
the end-user. This is a viable option for native applications in
order to identify the client for the purpose of displaying meta
information about the client to the user and to differentiate
clients in log files. Revocation of the rights associated with
such a client identifier will affect ALL deployments of the
respective software.
Deployment-independent "client_id" with pre-registered "redirect_uri"
and with "client_secret" This is an option for native
applications only, since web applications would require different
redirect URIs. This category is not advisable because the client
secret cannot be protected appropriately (see Section 4.1.1). Due
to its security weaknesses, such client identities have the same
trust level as deployment-independent clients without secrets.
Revocation will affect ALL deployments.
Deployment-specific "client_id" with pre-registered "redirect_uri"
and with "client_secret" The client registration process ensures
the validation of the client's properties, such as redirect URI,
web site URL, web site name, and contacts. Such a client
identifier can be utilized for all relevant use cases cited above.
This level can be achieved for web applications in combination
with a manual or user-bound registration process. Achieving this
level for native applications is much more difficult. Either the
installation of the application is conducted by an administrator,
who validates the client's authenticity, or the process from
validating the application to the installation of the application
on the device and the creation of the client credentials is
controlled end-to-end by a single entity (e.g., application market
provider). Revocation will affect a single deployment only.
Deployment-specific "client_id" with "client_secret" without
validated properties Such a client can be recognized by the
authorization server in transactions with subsequent requests
(e.g., authorization and token issuance, refresh token issuance,
and access token refreshment). The authorization server cannot
assure any property of the client to end users. Automatic
processing of re-authorizations could be allowed as well. Such
client credentials can be generated automatically without any
validation of client properties, which makes it another option,
especially for native applications. Revocation will affect a
single deployment only.
(page 15 continued on part 2)
