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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Attack Assumptions . . . . . . . . . . . . . . . . . . . . 7
2.3. Architectural assumptions . . . . . . . . . . . . . . . . 8
2.3.1. Authorization Servers . . . . . . . . . . . . . . . . 8
2.3.2. Resource Server . . . . . . . . . . . . . . . . . . . 8
2.3.3. Client . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Security Features . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 9
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. Redirection URI . . . . . . . . . . . . . . . . . . . . . 13
3.6. State parameter . . . . . . . . . . . . . . . . . . . . . 13
3.7. Client Identitifier . . . . . . . . . . . . . . . . . . . 13
4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.1. Threat: Obtain Client Secrets . . . . . . . . . . . . 15
4.1.2. Threat: Obtain Refresh Tokens . . . . . . . . . . . . 17
4.1.3. Threat: Obtain 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 . . . . . . . . . . . . . . . . . . 20
4.2.1. Threat: Password phishing by counterfeit
authorization server . . . . . . . . . . . . . . . . . 20
4.2.2. Threat: User unintentionally grants too much
access scope . . . . . . . . . . . . . . . . . . . . . 21
4.2.3. Threat: Malicious client obtains existing
authorization by fraud . . . . . . . . . . . . . . . . 21
4.2.4. Threat: Open redirector . . . . . . . . . . . . . . . 22
4.3. Token endpoint . . . . . . . . . . . . . . . . . . . . . . 22
4.3.1. Threat: Eavesdropping access tokens . . . . . . . . . 22
4.3.2. Threat: Obtain access tokens from authorization
server database . . . . . . . . . . . . . . . . . . . 23
4.3.3. Threat: Disclosure of client credentials during
transmission . . . . . . . . . . . . . . . . . . . . . 23
4.3.4. Threat: Obtain client secret from authorization
server database . . . . . . . . . . . . . . . . . . . 23
4.3.5. Threat: Obtain client secret by online guessing . . . 24
Lodderstedt, et al. Expires April 9, 2013 [Page 2]
Internet-Draft OAuth 2.0 Security October 2012
4.4. Obtaining Authorization . . . . . . . . . . . . . . . . . 24
4.4.1. Authorization Code . . . . . . . . . . . . . . . . . . 24
4.4.1.1. Threat: Eavesdropping or leaking authorization
codes . . . . . . . . . . . . . . . . . . . . . . 24
4.4.1.2. Threat: Obtain authorization codes from
authorization server database . . . . . . . . . . 25
4.4.1.3. Threat: Online guessing of authorization codes . . 26
4.4.1.4. Threat: Malicious client obtains authorization . . 26
4.4.1.5. Threat: Authorization code phishing . . . . . . . 28
4.4.1.6. Threat: User session impersonation . . . . . . . . 28
4.4.1.7. Threat: Authorization code leakage through
counterfeit client . . . . . . . . . . . . . . . . 29
4.4.1.8. Threat: CSRF attack against redirect-uri . . . . . 31
4.4.1.9. Threat: Clickjacking attack against
authorization . . . . . . . . . . . . . . . . . . 31
4.4.1.10. Threat: Resource Owner Impersonation . . . . . . . 32
4.4.1.11. Threat: DoS, Exhaustion of resources attacks . . . 33
4.4.1.12. Threat: DoS using manufactured authorization
codes . . . . . . . . . . . . . . . . . . . . . . 34
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
transport/end-points . . . . . . . . . . . . . . . 36
4.4.2.2. Threat: Access token leak in browser history . . . 37
4.4.2.3. Threat: Malicious client obtains authorization . . 37
4.4.2.4. Threat: Manipulation of scripts . . . . . . . . . 37
4.4.2.5. Threat: CSRF attack against redirect-uri . . . . . 38
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
client site . . . . . . . . . . . . . . . . . . . 40
4.4.3.2. Threat: Client obtains scopes without end-user
authorization . . . . . . . . . . . . . . . . . . 40
4.4.3.3. Threat: Client obtains refresh token through
automatic authorization . . . . . . . . . . . . . 41
4.4.3.4. Threat: Obtain user passwords on transport . . . . 42
4.4.3.5. Threat: Obtain user passwords from
authorization server database . . . . . . . . . . 42
4.4.3.6. Threat: Online guessing . . . . . . . . . . . . . 42
4.4.4. Client Credentials . . . . . . . . . . . . . . . . . . 43
4.5. Refreshing an Access Token . . . . . . . . . . . . . . . . 43
4.5.1. Threat: Eavesdropping refresh tokens from
authorization server . . . . . . . . . . . . . . . . . 43
4.5.2. Threat: Obtaining refresh token from authorization
server database . . . . . . . . . . . . . . . . . . . 43
4.5.3. Threat: Obtain refresh token by online guessing . . . 44
4.5.4. Threat: Obtain refresh token phishing by
counterfeit authorization server . . . . . . . . . . . 44
Lodderstedt, et al. Expires April 9, 2013 [Page 3]
Internet-Draft OAuth 2.0 Security October 2012
4.6. Accessing Protected Resources . . . . . . . . . . . . . . 44
4.6.1. Threat: Eavesdropping access tokens on transport . . . 44
4.6.2. Threat: Replay authorized resource server requests . . 45
4.6.3. Threat: Guessing access tokens . . . . . . . . . . . . 45
4.6.4. Threat: Access token phishing by counterfeit
resource server . . . . . . . . . . . . . . . . . . . 46
4.6.5. Threat: Abuse of token by legitimate resource
server or client . . . . . . . . . . . . . . . . . . . 46
4.6.6. Threat: Leak of confidential data in HTTP-Proxies . . 47
4.6.7. Threat: Token leakage via logfiles and HTTP
referrers . . . . . . . . . . . . . . . . . . . . . . 47
5. Security Considerations . . . . . . . . . . . . . . . . . . . 48
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.1. Ensure confidentiality of requests . . . . . . . . . . 48
5.1.2. Utiliize server authentication . . . . . . . . . . . . 48
5.1.3. Always keep the resource owner informed . . . . . . . 49
5.1.4. Credentials . . . . . . . . . . . . . . . . . . . . . 49
5.1.4.1. Enforce credential storage protection best
practices . . . . . . . . . . . . . . . . . . . . 50
5.1.4.2. Online attacks on secrets . . . . . . . . . . . . 51
5.1.5. Tokens (access, refresh, code) . . . . . . . . . . . . 52
5.1.5.1. Limit token scope . . . . . . . . . . . . . . . . 52
5.1.5.2. Expiration time . . . . . . . . . . . . . . . . . 52
5.1.5.3. Use short expiration time . . . . . . . . . . . . 53
5.1.5.4. Limit number of usages/ One time usage . . . . . . 53
5.1.5.5. Bind tokens to a particular resource server
(Audience) . . . . . . . . . . . . . . . . . . . . 54
5.1.5.6. Use endpoint address as token audience . . . . . . 54
5.1.5.7. Audience and Token scopes . . . . . . . . . . . . 54
5.1.5.8. Bind token to client id . . . . . . . . . . . . . 54
5.1.5.9. Signed tokens . . . . . . . . . . . . . . . . . . 55
5.1.5.10. Encryption of token content . . . . . . . . . . . 55
5.1.5.11. Assertion formats . . . . . . . . . . . . . . . . 55
5.1.6. Access tokens . . . . . . . . . . . . . . . . . . . . 55
5.2. Authorization Server . . . . . . . . . . . . . . . . . . . 55
5.2.1. Authorization Codes . . . . . . . . . . . . . . . . . 55
5.2.1.1. Automatic revocation of derived tokens if
abuse is detected . . . . . . . . . . . . . . . . 55
5.2.2. Refresh tokens . . . . . . . . . . . . . . . . . . . . 56
5.2.2.1. Restricted issuance of refresh tokens . . . . . . 56
5.2.2.2. Binding of refresh token to client_id . . . . . . 56
5.2.2.3. Refresh Token Rotation . . . . . . . . . . . . . . 56
5.2.2.4. Revoke refresh tokens . . . . . . . . . . . . . . 57
5.2.2.5. Device identification . . . . . . . . . . . . . . 57
5.2.2.6. X-FRAME-OPTION header . . . . . . . . . . . . . . 57
5.2.3. Client authentication and authorization . . . . . . . 57
5.2.3.1. Don't issue secrets to client with
inappropriate security policy . . . . . . . . . . 58
Lodderstedt, et al. Expires April 9, 2013 [Page 4]
Internet-Draft OAuth 2.0 Security October 2012
5.2.3.2. Require user consent for public clients
without secret . . . . . . . . . . . . . . . . . . 59
5.2.3.3. Client_id only in combination with redirect_uri . 59
5.2.3.4. Installation-specific client secrets . . . . . . . 59
5.2.3.5. Validation of pre-registered redirect_uri . . . . 60
5.2.3.6. Revoke client secrets . . . . . . . . . . . . . . 61
5.2.3.7. Use strong client authentication (e.g.
client_assertion / client_token) . . . . . . . . . 61
5.2.4. End-user authorization . . . . . . . . . . . . . . . . 61
5.2.4.1. Automatic processing of repeated
authorizations requires client validation . . . . 61
5.2.4.2. Informed decisions based on transparency . . . . . 62
5.2.4.3. Validation of client properties by end-user . . . 62
5.2.4.4. Binding of authorization code to client_id . . . . 62
5.2.4.5. Binding of authorization code to redirect_uri . . 62
5.3. Client App Security . . . . . . . . . . . . . . . . . . . 63
5.3.1. Don't store credentials in code or resources
bundled with software packages . . . . . . . . . . . . 63
5.3.2. Standard web server protection measures (for
config files and databases) . . . . . . . . . . . . . 63
5.3.3. Store secrets in a secure storage . . . . . . . . . . 63
5.3.4. Utilize device lock to prevent unauthorized device
access . . . . . . . . . . . . . . . . . . . . . . . . 64
5.3.5. Link state parameter to user agent session . . . . . . 64
5.4. Resource Servers . . . . . . . . . . . . . . . . . . . . . 64
5.4.1. Authorization headers . . . . . . . . . . . . . . . . 64
5.4.2. Authenticated requests . . . . . . . . . . . . . . . . 64
5.4.3. Signed requests . . . . . . . . . . . . . . . . . . . 65
5.5. A Word on User Interaction and User-Installed Apps . . . . 65
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 67
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 67
8.1. Informative References . . . . . . . . . . . . . . . . . . 67
8.2. Informative References . . . . . . . . . . . . . . . . . . 67
Appendix A. Document History . . . . . . . . . . . . . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 71
Lodderstedt, et al. Expires April 9, 2013 [Page 5]
Internet-Draft OAuth 2.0 Security October 2012
1. 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 [I-D.ietf-oauth-v2]. It
contains the following content:
o Documents any assumptions and scope considered when creating the
threat model.
o Describes the security features in-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 counter measures 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 aid
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 nor the risk
associated with a particular threat because those aspects strongly
depend on the particular application and deployment OAuth is used to
protect. Similar, 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, itdoes not
consider proposed extensions, such as client registration or
discovery, many of which are still under discussion.
2. Overview
2.1. Scope
The security considerations document only considers clients bound to
a particular deployment as supported by [I-D.ietf-oauth-v2]. Such
deployments have the following characteristics:
Lodderstedt, et al. Expires April 9, 2013 [Page 6]
Internet-Draft OAuth 2.0 Security October 2012
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: Since registration of clients is out of scope
of the current core spec, 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 authorization server and resource server
o Token formats
o Except for "Resource Owner Password Credentials" (see
[I-D.ietf-oauth-v2], 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:
o It is assumed 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 authorization and resource server.
o It is assumed an attacker has unlimited resources to mount an
attack.
o It is assumed that 2 of the 3 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
Lodderstedt, et al. Expires April 9, 2013 [Page 7]
Internet-Draft OAuth 2.0 Security October 2012
to resources.
2.3. Architectural assumptions
This section documents the assumptions about the features,
limitations, and design options of the different entities of a OAuth
deployment along with the security-sensitive data-elements managed by
those entity. These assumptions are the foundation of the threat
analysis.
The OAuth protocol leaves deployments with a certain degree of
freedom 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 later is
typically the case for multi-service providers with a single
authentication and authorization system, and are more typical in
middleware architectures.
2.3.1. Authorization Servers
The following data elements are stored or accessible on the
authorization server:
o user names and passwords
o client ids and secrets
o client-specific refresh tokens
o client-specific access tokens (in case of handle-based design -
see Section 3.1)
o HTTPS certificate/key
o per-authorization process (in 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
Lodderstedt, et al. Expires April 9, 2013 [Page 8]
Internet-Draft OAuth 2.0 Security October 2012
o authorization server credentials (handle-based design - see
Section 3.1), or
o 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 [I-D.ietf-oauth-v2], 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 CA certificates (HTTPS)
o per-authorization process: redirect_uri, authorization code
3. Security Features
These are some of the security features which have been built into
the OAuth 2.0 protocol to mitigate attacks and security issues.
3.1. Tokens
OAuth makes extensive use many kinds of tokens (access tokens,
refresh tokens, authorization codes). The information content of a
token can be represented in two ways as follows:
Lodderstedt, et al. Expires April 9, 2013 [Page 9]
Internet-Draft OAuth 2.0 Security October 2012
Handle (or artifact) 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, 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 issuing and
consuming entity (e.g. authorization and resource server) in order
to validate the token and obtain token-bound data. This
communication might have an 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.
Assertions (aka self-contained token) 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 SAML assertions
[OASIS.saml-core-2.0-os] and Kerberos tickets [RFC4120].
Assertions can typically directly be validated and used by a
resource server without interactions with the authorization
server. This results in better performance and scalability in
deployment where issuing and consuming entity 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.
[I-D.ietf-oauth-v2-bearer]). Because mere possession is enough to
use the token it is important that communication between end-
points be secured to ensure that only authorized end-points may
capture the token. The bearer token is convenient to 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 tokens, which require the
client to digitally sign the resource request with a secret
corresponding to the particular token send with the request
Lodderstedt, et al. Expires April 9, 2013 [Page 10]
Internet-Draft OAuth 2.0 Security October 2012
(e.g.[I-D.ietf-oauth-v2-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 these parties deem
less secure or trustworthy. Optionally, the client can request the
scope to apply to the token but only for 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-living tokens to
OAuth clients 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 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
Lodderstedt, et al. Expires April 9, 2013 [Page 11]
Internet-Draft OAuth 2.0 Security October 2012
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 which originally requested the authorization and
representing 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 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 rollover 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 token. Authorization codes are sent to
the client's redirection 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 client and authorization server.
2. It is much simpler to authenticate clients during the direct
request between client and authorization server than in the
context of the indirect authorization request. The latter would
require digital signatures.
Lodderstedt, et al. Expires April 9, 2013 [Page 12]
Internet-Draft OAuth 2.0 Security October 2012
3.5. Redirection URI
A redirection 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
redirection 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 implicit grant type to pre-register their
redirect URIs and validate against the registered redirection 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
users 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 Identitifier
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 request 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 authorization)
This identifier may also be used by the authorization server to
display relevant registration information to a user when requesting
consent for scope requested by a particular client. The client
Lodderstedt, et al. Expires April 9, 2013 [Page 13]
Internet-Draft OAuth 2.0 Security October 2012
identifier may be used to limit the number of request 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
redicrection URI can be used to prevent delivering 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 [I-D.ietf-oauth-v2],
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 application 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 secret. Revocation will
affect ALL deployments.
Lodderstedt, et al. Expires April 9, 2013 [Page 14]
Internet-Draft OAuth 2.0 Security October 2012
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 redirection URI,
website URL, web site name, 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.
4. Threat Model
This section gives a comprehensive threat model of OAuth 2.0.
Threats are grouped first by attacks directed against an OAuth
component, which are client, authorization server, and resource
server. Subsequently, they are grouped by flow, e.g. obtain token or
access protected resources. Every countermeasure description refers
to a detailed description in Section 5.
4.1. Clients
This section describes possible threats directed to OAuth clients.
4.1.1. Threat: Obtain Client Secrets
The attacker could try to get access to the secret of a particular
client in order to:
Lodderstedt, et al. Expires April 9, 2013 [Page 15]
Internet-Draft OAuth 2.0 Security October 2012
o replay its refresh tokens and authorization codes, or
o obtain tokens on behalf of the attacked client with the privileges
of that client_id acting as an instance of the client.
The resulting impact would be:
o Client authentication of access to authorization server can be
bypassed
o Stolen refresh tokens or authorization codes can be replayed
Depending on the client category, the following attacks could be
utilized to obtain the client secret.
Attack: Obtain Secret From Source Code or Binary:
This applies for all client types. For open source projects, secrets
can be extracted directly from source code in their public
repositories. Secrets can be extracted from application binaries
just as easily when published source is not available to the
attacker. Even if an application takes significant measures to
obfuscate secrets in their application distribution one should
consider that the secret can still be reverse-engineered by anyone
with access to a complete functioning application bundle or binary.
Countermeasures:
o Don't issue secrets to public clients or clients with
inappropriate security policy - Section 5.2.3.1
o Require user consent for public clients- Section 5.2.3.2
o Use deployment-specific client secrets - Section 5.2.3.4
o Revoke client secrets - Section 5.2.3.6
Attack: Obtain a Deployment-Specific Secret:
An attacker may try to obtain the secret from a client installation,
either from a web site (web server) or a particular devices (native
application).
Countermeasures:
Lodderstedt, et al. Expires April 9, 2013 [Page 16]
Internet-Draft OAuth 2.0 Security October 2012
o Web server: apply standard web server protection measures (for
config files and databases) - Section 5.3.2
o Native applications: Store secrets in a secure local storage -
Section 5.3.3
o Revoke client secrets - Section 5.2.3.6
4.1.2. Threat: Obtain Refresh Tokens
Depending on the client type, there are different ways refresh tokens
may be revealed to an attacker. The following sub-sections give a
more detailed description of the different attacks with respect to
different client types and further specialized countermeasures.
Before detailing those threats, here are some generally applicable
countermeasures:
o The authorization server should validate the client id associated
with the particular refresh token with every refresh request-
Section 5.2.2.2
o Limit token scope - Section 5.1.5.1
o Revoke refresh tokens - Section 5.2.2.4
o Revoke client secrets - Section 5.2.3.6
o Refresh tokens can automatically be replaced in order to detect
unauthorized token usage by another party (Refresh Token Rotation)
- Section 5.2.2.3
Attack: Obtain Refresh Token from Web application:
An attacker may obtain the refresh tokens issued to a web application
by way of overcoming the web server's security controls. Impact:
Since a web application manages the user accounts of a certain site,
such an attack would result in an exposure of all refresh tokens on
that site to the attacker.
Countermeasures:
o Standard web server protection measures - Section 5.3.2
o Use strong client authentication (e.g. client_assertion /
client_token), so the attacker cannot obtain the client secret
required to exchange the tokens - Section 5.2.3.7
Lodderstedt, et al. Expires April 9, 2013 [Page 17]
Internet-Draft OAuth 2.0 Security October 2012
Attack: Obtain Refresh Token from Native clients:
On native clients, leakage of a refresh token typically affects a
single user, only.
Read from local file system: The attacker could try get file system
access on the device and read the refresh tokens. The attacker could
utilize a malicious application for that purpose.
Countermeasures:
o Store secrets in a secure storage - Section 5.3.3
o Utilize device lock to prevent unauthorized device access -
Section 5.3.4
Attack: Steal device:
The host device (e.g. mobile phone) may be stolen. In that case, the
attacker gets access to all applications under the identity of the
legitimate user.
Countermeasures:
o Utilize device lock to prevent unauthorized device access -
Section 5.3.4
o Where a user knows the device has been stolen, they can revoke the
affected tokens - Section 5.2.2.4
Attack: Clone Device:
All device data and applications are copied to another device.
Applications are used as-is on the target device.
Countermeasures:
o Utilize device lock to prevent unauthorized device access -
Section 5.3.4
o Combine refresh token request with device identification -
Section 5.2.2.5
o Refresh Token Rotation - Section 5.2.2.3
Lodderstedt, et al. Expires April 9, 2013 [Page 18]
Internet-Draft OAuth 2.0 Security October 2012
o Where a user knows the device has been cloned, they can use this
countermeasure - Refresh Token Revocation - Section 5.2.2.4
4.1.3. Threat: Obtain Access Tokens
Depending on the client type, there are different ways access tokens
may be revealed to an attacker. Access tokens could be stolen from
the device if the application stores them in a storage, which is
accessible to other applications.
Impact: Where the token is a bearer token and no additional mechanism
is used to identify the client, the attacker can access all resources
associated with the token and its scope.
Countermeasures:
o Keep access tokens in transient memory and limit grants:
Section 5.1.6
o Limit token scope - Section 5.1.5.1
o Keep access tokens in private memory or apply same protection
means as for refresh tokens - Section 5.2.2
o Keep access token lifetime short - Section 5.1.5.3
4.1.4. Threat: End-user credentials phished using compromised or
embedded browser
A malicious application could attempt to phish end-user passwords by
misusing an embedded browser in the end-user authorization process,
or by presenting its own user-interface instead of allowing trusted
system browser to render the authorization user interface. By doing
so, the usual visual trust mechanisms may be bypassed (e.g. TLS
confirmation, web site mechanisms). By using an embedded or internal
client application user interface, the client application has access
to additional information it should not have access to (e.g. uid/
password).
Impact: If the client application or the communication is
compromised, the user would not be aware and all information in the
authorization exchange could be captured such as username and
password.
Countermeasures:
Lodderstedt, et al. Expires April 9, 2013 [Page 19]
Internet-Draft OAuth 2.0 Security October 2012
o The OAuth flow is designed so that client applications never need
to know user passwords. Client applications should avoid directly
asking users for the their credentials. In addition, end users
could be educated about phishing attacks and best practices, such
as only accessing trusted clients, as OAuth does not provide any
protection against malicious applications and the end user is
solely responsible for the trustworthiness of any native
application installed.
o Client applications could be validated prior to publication in an
application market for users to access. That validation is out of
scope for OAuth but could include validating that the client
application handles user authentication in an appropriate way.
o Client developers should not write client applications that
collect authentication information directly from users and should
instead delegate this task to a trusted system component, e.g. the
system-browser.
4.1.5. Threat: Open Redirectors on client
An open redirector is an endpoint using a parameter to automatically
redirect a user-agent to the location specified by the parameter
value without any validation. If the authorization server allows the
client to register only part of the redirection URI, an attacker can
use an open redirector operated by the client to construct a
redirection URI that will pass the authorization server validation
but will send the authorization code or access token to an endpoint
under the control of the attacker.
Impact: An attacker could gain access to authorization codes or
access tokens
Countermeasure
o require clients to register full redirection URI Section 5.2.3.5
4.2. Authorization Endpoint
4.2.1. Threat: Password phishing by counterfeit authorization server
OAuth makes no attempt to verify the authenticity of the
Authorization Server. A hostile party could take advantage of this
by intercepting the Client's requests and returning misleading or
otherwise incorrect responses. This could be achieved using DNS or
ARP spoofing. Wide deployment of OAuth and similar protocols may
cause users to become inured to the practice of being redirected to
websites where they are asked to enter their passwords. If users are
Lodderstedt, et al. Expires April 9, 2013 [Page 20]
Internet-Draft OAuth 2.0 Security October 2012
not careful to verify the authenticity of these websites before
entering their credentials, it will be possible for attackers to
exploit this practice to steal Users' passwords.
Countermeasures:
o Authorization servers should consider such attacks when developing
services based on OAuth, and should require the use of transport-
layer security for any requests where the authenticity of the
authorization server or of request responses is an issue (see
Section 5.1.2).
o Authorization servers should attempt to educate Users about the
risks phishing attacks pose, and should provide mechanisms that
make it easy for users to confirm the authenticity of their sites.
4.2.2. Threat: User unintentionally grants too much access scope
When obtaining end user authorization, the end-user may not
understand the scope of the access being granted and to whom or they
may end up providing a client with access to resources which should
not be permitted.
Countermeasures:
o Explain the scope (resources and the permissions) the user is
about to grant in an understandable way - Section 5.2.4.2
o Narrow scope based on client - When obtaining end user
authorization and where the client requests scope, the
authorization server may want to consider whether to honour that
scope based on the client identifier. That decision is between
the client and authorization server and is outside the scope of
this spec. The authorization server may also want to consider
what scope to grant based on the client type, e.g. providing lower
scope to public clients. - Section 5.1.5.1
4.2.3. Threat: Malicious client obtains existing authorization by fraud
Authorization servers may wish to automatically process authorization
requests from clients which have been previously authorized by the
user. When the user is redirected to the authorization server's end-
user authorization endpoint to grant access, the authorization server
detects that the user has already granted access to that particular
client. Instead of prompting the user for approval, the
authorization server automatically redirects the user back to the
client.
Lodderstedt, et al. Expires April 9, 2013 [Page 21]
Internet-Draft OAuth 2.0 Security October 2012
A malicious client may exploit that feature and try to obtain such an
authorization code instead of the legitimate client.
Countermeasures:
o Authorization servers should not automatically process repeat
authorizations to public clients unless the client is validated
using a pre-registered redirect URI (Section 5.2.3.5 )
o Authorization servers can mitigate the risks associated with
automatic processing by limiting the scope of Access Tokens
obtained through automated approvals - Section 5.1.5.1
4.2.4. Threat: Open redirector
An attacker could use the end-user authorization endpoint and the
redirection URI parameter to abuse the authorization server as an
open redirector. An open redirector is an endpoint using a parameter
to automatically redirect a user-agent to the location specified by
the parameter value without any validation.
Impact: An attacker could utilize a user's trust in your
authorization server to launch a phishing attack.
Countermeasure
o require clients to register full redirection URI Section 5.2.3.5
o don't redirect to redirection URI, if client identifier or
redirection URI can't be verified Section 5.2.3.5
4.3. Token endpoint
4.3.1. Threat: Eavesdropping access tokens
Attackers may attempt to eavesdrop access token in transit from the
authorization server to the client.
Impact: The attacker is able to access all resources with the
permissions covered by the scope of the particular access token.
Countermeasures:
o As per the core OAuth spec, the authorization servers must ensure
that these transmissions are protected using transport-layer
mechanisms such as TLS (see Section 5.1.1).
Lodderstedt, et al. Expires April 9, 2013 [Page 22]
Internet-Draft OAuth 2.0 Security October 2012
o If end-to-end confidentiality cannot be guaranteed, reducing scope
(see Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access
tokens can be used to reduce the damage in case of leaks.
4.3.2. Threat: Obtain access tokens from authorization server database
This threat is applicable if the authorization server stores access
tokens as handles in a database. An attacker may obtain access
tokens from the authorization server's database by gaining access to
the database or launching a SQL injection attack. Impact: disclosure
of all access tokens
Countermeasures:
o Enforce system security measures - Section 5.1.4.1.1
o Store access token hashes only - Section 5.1.4.1.3
o Enforce standard SQL injection Countermeasures - Section 5.1.4.1.2
4.3.3. Threat: Disclosure of client credentials during transmission
An attacker could attempt to eavesdrop the transmission of client
credentials between client and server during the client
authentication process or during OAuth token requests.
Impact: Revelation of a client credential enabling phishing or
impersonation of a client service.
Countermeasures:
o The transmission of client credentials must be protected using
transport-layer mechanisms such as TLS (see Section 5.1.1).
o Alternative authentication means, which do not require to send
plaintext credentials over the wire (e.g. Hash-based Message
Authentication Code)
4.3.4. Threat: Obtain client secret from authorization server database
An attacker may obtain valid client_id/secret combinations from the
authorization server's database by gaining access to the database or
launching a SQL injection attack. Impact: disclosure of all
client_id/secret combinations. This allows the attacker to act on
behalf of legitimate clients.
Countermeasures:
Lodderstedt, et al. Expires April 9, 2013 [Page 23]
Internet-Draft OAuth 2.0 Security October 2012
o Enforce system security measures - Section 5.1.4.1.1
o Enforce standard SQL injection Countermeasures - Section 5.1.4.1.2
o Ensure proper handling of credentials as per Enforce credential
storage protection best practices.
4.3.5. Threat: Obtain client secret by online guessing
An attacker may try to guess valid client_id/secret pairs. Impact:
disclosure of single client_id/secret pair.
Countermeasures:
o Use high entropy for secrets - Section 5.1.4.2.2
o Lock accounts - Section 5.1.4.2.3
o Use Strong Client Authentication - Section 5.2.3.7
4.4. Obtaining Authorization
This section covers threats which are specific to certain flows
utilized to obtain access tokens. Each flow is characterized by
response types and/or grant types on the end-user authorization and
token endpoint, respectively.
4.4.1. Authorization Code
4.4.1.1. Threat: Eavesdropping or leaking authorization codes
An attacker could try to eavesdrop transmission of the authorization
code between authorization server and client. Furthermore,
authorization codes are passed via the browser which may
unintentionally leak those codes to untrusted web sites and attackers
in different ways:
o Referrer headers: browsers frequently pass a "referer" header when
a web page embeds content, or when a user travels from one web
page to another web page. These referrer headers may be sent even
when the origin site does not trust the destination site. The
referrer header is commonly logged for traffic analysis purposes.
o Request logs: web server request logs commonly include query
parameters on requests.
o Open redirectors: web sites sometimes need to send users to
another destination via a redirector. Open redirectors pose a
Lodderstedt, et al. Expires April 9, 2013 [Page 24]
Internet-Draft OAuth 2.0 Security October 2012
particular risk to web-based delegation protocols because the
redirector can leak verification codes to untrusted destination
sites.
o Browser history: web browsers commonly record visited URLs in the
browser history. Another user of the same web browser may be able
to view URLs that were visited by previous users.
Note: A description of a similar attacks on the SAML protocol can be
found at [OASIS.sstc-saml-bindings-1.1], Section 4.1.1.9.1,
[gross-sec-analysis], and
[OASIS.sstc-gross-sec-analysis-response-01].
Countermeasures:
o As per the core OAuth spec, the authorization server as well as
the client must ensure that these transmissions are protected
using transport-layer mechanisms such as TLS (see Section 5.1.1).
o The authorization server will require the client to authenticate
wherever possible, so the binding of the authorization code to a
certain client can be validated in a reliable way (see
Section 5.2.4.4).
o Use short expiry time for authorization codes - Section 5.1.5.3
o The authorization server should enforce a one time usage
restriction (see Section 5.1.5.4).
o If an Authorization Server observes multiple attempts to redeem an
authorization code, the Authorization Server may want to revoke
all tokens granted based on the authorization code (see
Section 5.2.1.1).
o In the absence of these countermeasures, reducing scope
(Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access
tokens can be used to reduce the damage in case of leaks.
o The client server may reload the target page of the redirection
URI in order to automatically cleanup the browser cache.
4.4.1.2. Threat: Obtain authorization codes from authorization server
database
This threat is applicable if the authorization server stores
authorization codes as handles in a database. An attacker may obtain
authorization codes from the authorization server's database by
gaining access to the database or launching a SQL injection attack.
Lodderstedt, et al. Expires April 9, 2013 [Page 25]
Internet-Draft OAuth 2.0 Security October 2012
Impact: disclosure of all authorization codes, most likely along with
the respective redirect_uri and client_id values.
Countermeasures:
o Best practices for credential storage protection should be
employed - Section 5.1.4.1
o Enforce system security measures - Section 5.1.4.1.1
o Store access token hashes only - Section 5.1.4.1.3
o Standard SQL injection countermeasures - Section 5.1.4.1.2
4.4.1.3. Threat: Online guessing of authorization codes
An attacker may try to guess valid authorization code values and send
it using the grant type "code" in order to obtain a valid access
token.
Impact: disclosure of single access token, probably also associated
refresh token.
Countermeasures:
o Handle-based tokens must use high entropy: Section 5.1.4.2.2
o Assertion-based tokens should be signed: Section 5.1.5.9
o Authenticate the client, ad