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 Considerations
Abstract
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.

6. Acknowledgements ...............................................697. References .....................................................697.1. Normative References ......................................697.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.