One document matched: draft-ietf-oauth-v2-threatmodel-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<rfc category="info" docName="draft-ietf-oauth-v2-threatmodel-02"
ipr="trust200902">
<front>
<title abbrev="OAuth 2.0 Security">OAuth 2.0 Threat Model and Security
Considerations</title>
<author fullname="Torsten Lodderstedt" initials="T." role="editor"
surname="Lodderstedt">
<organization>Deutsche Telekom AG</organization>
<address>
<email>torsten@lodderstedt.net</email>
</address>
</author>
<author fullname="Mark McGloin" initials="M." surname="McGloin">
<organization>IBM</organization>
<address>
<email>mark.mcgloin@ie.ibm.com</email>
</address>
</author>
<author fullname="Phil Hunt" initials="P." surname="Hunt">
<organization>Oracle Corporation</organization>
<address>
<email>phil.hunt@yahoo.com</email>
</address>
</author>
<date day="19" month="February" year="2012" />
<area>Security Area</area>
<workgroup>Web Authorization Protocol (oauth)</workgroup>
<keyword>security</keyword>
<keyword>oauth 2.0</keyword>
<keyword>threat model</keyword>
<abstract>
<t>This document gives security considerations based on a comprehensive
threat model for the OAuth 2.0 Protocol.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>This document gives security considerations based on a comprehensive
threat model for the OAuth 2.0 Protocol <xref
target="I-D.ietf-oauth-v2"></xref>. It contains the following
content:<list style="symbols">
<t>Documents any assumptions and scope considered when creating the
threat model.</t>
<t>Describes the security features in-built into the OAuth protocol
and how they are intended to thwart attacks.</t>
<t>Gives a comprehensive threat model for OAuth and describes the
respective counter measures to thwart those threats.</t>
</list>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.</t>
</section>
<section title="Overview">
<t></t>
<section title="Scope">
<t>The security considerations document only considers clients bound
to a particular deployment as supported by <xref
target="I-D.ietf-oauth-v2"></xref>. Such deployments have the
following characteristics:</t>
<t><list style="symbols">
<t>Resource server URLs are static and well-known at development
time, authorization server URLs can be static or discovered.</t>
<t>Token scope values (e.g. applicable URLs and methods) are
well-known at development time.</t>
<t>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.</t>
</list>The following are considered out of scope :</t>
<t><list style="symbols">
<t>Communication between authorization server and resource
server</t>
<t>Token formats</t>
<t>Except for „Resource Owner Password Credentials“
(see <xref target="I-D.ietf-oauth-v2"></xref>, section 4.3), the
mechanism used by authorization servers to authenticate the
user</t>
<t>Mechanism by which a user obtained an assertion and any
resulting attacks mounted as a result of the assertion being
false.</t>
<t>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 <xref
target="portable-contacts"></xref>). Such clients cannot be
registered upfront with a particular deployment and should
dynamically discover the URLs relevant for the OAuth protocol.</t>
</list></t>
</section>
<section title="Attack Assumptions">
<t>The following assumptions relate to an attacker and resources
available to an attacker:</t>
<t><list style="symbols">
<t>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.</t>
<t>It is assumed an attacker has unlimited resources to mount an
attack.</t>
<t>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 to
resources.</t>
</list></t>
</section>
<section title="Architectural assumptions">
<t>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.</t>
<t>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.</t>
<section title="Authorization Servers">
<t>The following data elements are stored or accessible on the
authorization server:</t>
<t><list style="symbols">
<t>user names and passwords</t>
<t>client ids and secrets</t>
<t>client-specific refresh tokens</t>
<t>client-specific access tokens (in case of handle-based
design)</t>
<t>HTTPS certificate/key</t>
<t>per-authorization process (in case of handle-based design):
redirect_uri, client_id, authorization code</t>
</list></t>
</section>
<section title="Resource Server">
<t>The following data elements are stored or accessible on the
resource server:</t>
<t><list style="symbols">
<t>user data (out of scope)</t>
<t>HTTPS certificate/key</t>
<t>authorization server credentials (handle-based design),
or</t>
<t>authorization server shared secret/public key
(assertion-based design)</t>
<t>access tokens (per request)</t>
</list> It is assumed that a resource server has no knowledge of
refresh tokens, user passwords, or client secrets.</t>
</section>
<section title="Client">
<t>A full definition of different client types and profiles is given
in <xref target="I-D.ietf-oauth-v2"></xref>, Section 2.1.</t>
<t>The following data elements are stored or accessible on the
client:</t>
<t><list style="symbols">
<t>client id (and client secret or corresponding client
credential)</t>
<t>one or more refresh tokens (persistent) and access tokens
(transient) per end-user or other security-context or delegation
context</t>
<t>trusted CA certificates (HTTPS)</t>
<t>per-authorization process: redirect_uri, authorization
code</t>
</list></t>
</section>
</section>
</section>
<section title="Security Features">
<t>These are some of the security features which have been built into
the OAuth 2.0 protocol to mitigate attacks and security issues.</t>
<section title="Tokens">
<t>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:</t>
<t><list style="hanging">
<t hangText="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.</t>
<t hangText="Assertions (aka self-contained token)">a parseable
token. An assertion typically has a duration, an audience, and is
digitally signed containing information about the user and the
client. Examples of assertion formats are SAML assertions and
Kerberos tickets. 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.</t>
</list>Tokens can be used in two ways to invoke requests on resource
servers as follows:</t>
<t><list style="hanging">
<t hangText="bearer token">A 'bearer token' is a token that can be
used by any client who has received the token (e.g. <xref
target="I-D.ietf-oauth-v2-bearer"></xref>). 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.</t>
<t hangText="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 (e.g.<xref
target="I-D.ietf-oauth-v2-http-mac"></xref>).</t>
</list></t>
<section title="Scope">
<t>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.</t>
</section>
<section title="Expires_In">
<t>Expires_In allows an authorization server (based on its policies
or on behalf of the end-user) to limit the lifetime of the access
token. This mechanisms 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.</t>
</section>
</section>
<section title="Access Token">
<t>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.</t>
</section>
<section title="Refresh Token">
<t>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.</t>
<t>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.</t>
<t>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:</t>
<t><list style="numbers">
<t>The resource owner and user-agent safely deliver the
authorization code to the client instance in first place.</t>
<t>The client uses it immediately in secure transport-level
communications to the authorization server and then securely
stores the long-lived refresh token.</t>
<t>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).</t>
</list>So as long as the confidentiality of the particular token can
be ensured by the client, a refresh tokens can also be used as an
alternative mean to authenticate the client instance itself.</t>
</section>
<section title="Authorization Code">
<t>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.</t>
<t><list style="numbers">
<t>Instead of (longer-lasting) tokens, the short-lived
authorization code is exposed to potential attackers via URI query
parameters (HTTP referrer), browser cache, or log file
entries.</t>
<t>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 later would
require digital signatures.</t>
</list></t>
</section>
<section title="Redirection URI">
<t>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.</t>
</section>
<section title="State parameter">
<t>The state parameter is used to link requests and callbacks to
prevent CSRF attacks 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</t>
</section>
<section title="Client Identity">
<t>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.</t>
<t>OAuth uses the client identifier to collate associated request to
the same originator, such as</t>
<t><list style="symbols">
<t>a particular end-user authorization process and the
corresponding request on the token's endpoint to exchange the
authorization code for tokens or</t>
<t>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)</t>
</list>The client identity 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 identity may be used to limit the number of request for a
particular client or to charge the client per request. Client Identity
may furthermore be useful to differentiate access by different
clients, e.g. in server log files.</t>
<t>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.</t>
<t>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 identity.</t>
<t>Clients can be categorized as follows based on the client type,
profile (e.g. native vs web application) and deployment model:</t>
<t><list style="hanging">
<t
hangText="Deployment-independent client_id with pre-registered redirect_uri and without client_secret">Such
an identity is used by multiple installations of the same software
package. The identity 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 such an identity
will affect ALL deployments of the respective software.</t>
<t
hangText="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 <xref target="ObtainClientSecrets"></xref>).
Due to its security weaknesses, such client identities have the
same trust level as deployment-independent clients without secret.
Revocation will affect ALL deployments.</t>
<t
hangText="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 address, web site
name, contacts. Such a client identity 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.</t>
<t
hangText="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.</t>
</list></t>
</section>
</section>
<section title="Security Threat Model">
<t>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 <xref target="security_considerations"></xref>.</t>
<section title="Clients">
<t>This section describes possible threats directed to OAuth
clients.</t>
<section anchor="ObtainClientSecrets"
title="Threat: Obtain Client Secrets">
<t>The attacker could try to get access to the secret of a
particular client in order to:</t>
<t><list style="symbols">
<t>replay its refresh tokens and authorization codes, or</t>
<t>obtain tokens on behalf of the attacked client with the
privileges of that client.</t>
</list>The resulting impact would be:</t>
<t><list style="symbols">
<t>Client authentication of access to authorization server can
be bypassed</t>
<t>Stolen refresh tokens or authorization codes can be
replayed</t>
</list>Depending on the client category, the following attacks
could be utilized to obtain the client secret.</t>
<t><vspace blankLines="1" />Attack: Obtain Secret From Source Code
or Binary:</t>
<t>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.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Don't issue secrets to public clients or clients with
inappropriate security policy - <xref
target="dont_issue"></xref></t>
<t>Public clients require user consent - <xref
target="forced_user_consent"></xref></t>
<t>Use deployment-specific client secrets - <xref
target="depl_specific_secretes"></xref></t>
<t>Client secret revocation - <xref
target="client_secret_revocation"></xref></t>
</list></t>
<t><vspace blankLines="1" />Attack: Obtain a Deployment-Specific
Secret:</t>
<t>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).</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Web server: apply standard web server protection measures
(for config files and databases) - <xref
target="std_web"></xref></t>
<t>Native applications: Store secrets in a secure local storage
- <xref target="secure_storage"></xref></t>
<t>Client secret revocation - <xref
target="client_secret_revocation"></xref></t>
</list></t>
</section>
<section title="Threat: Obtain Refresh Tokens">
<t>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:</t>
<t><list style="symbols">
<t>The authorization server should validate the client id
associated with the particular refresh token with every refresh
request- <xref target="binding_refresh_client_id"></xref></t>
<t>Limited scope tokens - <xref target="limit_scope"></xref></t>
<t>Refresh token revocation - <xref
target="refresh_revocation"></xref></t>
<t>Client secret revocation - <xref
target="client_secret_revocation"></xref></t>
<t>Refresh tokens can automatically be replaced in order to
detect unauthorized token usage by another party (Refresh Token
Rotation) - <xref target="refresh_replace"></xref></t>
</list></t>
<t><vspace blankLines="1" />Attack: Obtain Refresh Token from Web
application:</t>
<t>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 side to the attacker.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Standard web server protection measures - <xref
target="std_web"></xref></t>
<t>Use strong client authentication (e.g. client_assertion /
client_token), so the attacker cannot obtain the client secret
required to exchange the tokens - <xref
target="strong_client_authn"></xref></t>
</list></t>
<t><vspace blankLines="1" />Attack: Obtain Refresh Token from Native
clients:</t>
<t>On native clients, leakage of a refresh token typically affects a
single user, only.</t>
<t>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.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Store secrets in a secure storage - <xref
target="secure_storage"></xref></t>
<t>Utilize device lock to prevent unauthorized device access -
<xref target="device_lock"></xref></t>
</list></t>
<t><vspace blankLines="1" />Attack: Steal device:</t>
<t>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.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Utilize device lock to prevent unauthorized device access -
<xref format="default" target="device_lock"></xref></t>
<t>Where a user knows the device has been stolen, they can
revoke the affected tokens - <xref
target="refresh_revocation"></xref></t>
</list></t>
<t><vspace blankLines="1" />Attack: Clone Device:</t>
<t>All device data and applications are copied to another device.
Applications are used as-is on the target device.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Utilize device lock to prevent unauthorized device access -
<xref format="default" target="device_lock"></xref></t>
<t>Combine refresh token request with device identification -
<xref target="device_id"></xref></t>
<t>Refresh Token Rotation - <xref
target="refresh_replace"></xref></t>
<t>Where a user knows the device has been cloned, they can use
this countermeasure - Refresh Token Revocation - <xref
target="refresh_revocation"></xref></t>
</list></t>
</section>
<section title="Threat: Obtain Access Tokens">
<t>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.</t>
<t>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.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Keep access tokens in transient memory and limit grants:
<xref target="access_tokens"></xref></t>
<t>Limited scope tokens - <xref target="limit_scope"></xref></t>
<t>Keep access tokens in private memory or apply same protection
means as for refresh tokens - <xref
target="refresh_tokens"></xref></t>
<t>Keep access token lifetime short - <xref
target="short_exp_time"></xref></t>
</list></t>
</section>
<section title="Threat: End-user credentials phished using compromised or embedded browser">
<t>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).</t>
<t>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.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
</section>
<section anchor="open_redirector_client"
title="Threat: Open Redirectors on client">
<t>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.</t>
<t>Impact: An attacker could gain access to authorization codes or
access tokens</t>
<t>Countermeasure</t>
<t><list style="symbols">
<t>require clients to register full redirection URI <xref
target="val_redirect"></xref></t>
</list></t>
</section>
</section>
<section title="Authorization Endpoint">
<t></t>
<section title="Threat: Password phishing by counterfeit authorization server">
<t>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
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.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Authorization servers should consider such attacks when
developing services based on OAuth, and should require
transport-layer security for any requests where the authenticity
of the authorization server or of request responses is an issue
(see <xref target="server_authn"></xref>).</t>
<t>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.</t>
</list></t>
</section>
<section title="Threat: User unintentionally grants too much access scope">
<t>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.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Explain the scope (resources and the permissions) the user is
about to grant in a understandable way - <xref
target="informed_decisions"></xref></t>
<t>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 who the client is. 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. - <xref
target="limit_scope"></xref></t>
</list></t>
</section>
<section anchor="mal_client3"
title="Threat: Malicious client obtains existing authorization by fraud">
<t>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.</t>
<t>A malicious client may exploit that feature and try to obtain
such an authorization code instead of the legitimate client.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Authorization servers should not automatically process repeat
authorizations to public clients or unless the client is
validated using a pre-registered redirect URI (<xref
target="val_redirect"></xref> )</t>
<t>Authorization servers can mitigate the risks associated with
automatic processing by limiting the scope of Access Tokens
obtained through automated approvals - <xref
target="limit_scope"></xref></t>
</list></t>
</section>
<section anchor="open_redirector" title="Threat: Open redirector">
<t>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.</t>
<t>Impact: An attacker could utilize a user's trust in your
authorization server to launch a phishing attack.</t>
<t>Countermeasure</t>
<t><list style="symbols">
<t>require clients to register full redirection URI <xref
target="val_redirect"></xref></t>
<t>don't redirect to redirection URI, if client identity or
redirection URI can't be verified <xref
target="val_redirect"></xref></t>
</list></t>
</section>
</section>
<section title="Token endpoint">
<t></t>
<section title="Threat: Eavesdropping access tokens">
<t>Attackers may attempts to eavesdrop access token on transit from
the authorization server to the client.</t>
<t>Impact: The attacker is able to access all resources with the
permissions covered by the scope of the particular access token.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>As per the core OAuth spec, the authorization servers must
ensure that these transmissions are protected using
transport-layer mechanisms such as TLS or SSL (see <xref
target="conf_requests"></xref>).</t>
<t>If end-to-end confidentiality cannot be guaranteed, reducing
scope (see <xref target="limit_scope"></xref>) and expiry time
(<xref target="short_exp_time"></xref>) for access tokens can be
used to reduce the damage in case of leaks.</t>
</list></t>
</section>
<section title="Threat: Obtain access tokens from authorization server database">
<t>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</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>System security measures - <xref target="std_sys"></xref></t>
<t>Store access token hashes only - <xref
target="noclear"></xref></t>
<t>Standard SQL injection Countermeasures - <xref
target="std_sql"></xref></t>
</list></t>
</section>
<section title="Threat: Obtain client credentials over non secure transport">
<t>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 the possibility for
phishing or imitation of a client service.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Implement transport security through - <xref
target="conf_requests"></xref></t>
<t>Alternative authentication means, which do not require to
send plaintext credentials over the wire (Examples: Digest
authentication)</t>
</list></t>
</section>
<section title="Threat: Obtain client secret from authorization server database">
<t>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.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Ensure proper handling of credentials as per <xref
format="title" target="cred_storage_prot"></xref>.</t>
</list></t>
</section>
<section title="Threat: Obtain client secret by online guessing">
<t>An attacker may try to guess valid client_id/secret pairs.
Impact: disclosure of single client_id/secret pair.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>High entropy of secrets - <xref
target="high_entropy"></xref></t>
<t>Lock accounts - <xref target="lock_accounts"></xref></t>
<t>Use Strong Client Authentication - <xref
target="strong_client_authn"></xref></t>
</list></t>
</section>
<section title="Threat: DoS on dynamic client secret creation">
<t>If an authorization servers includes a nontrivial amount of
entropy in client secrets and if the authorization server
automatically grants them, an attacker could exhaust the pool by
repeatedly applying for them.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>The authorization server should consider some verification
step for new clients. The authorization server should include a
nontrivial amount of entropy in client secrets.</t>
</list></t>
</section>
</section>
<section title="Obtaining Authorization">
<t>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
tokens endpoint, respectively.</t>
<section anchor="code_flow" title="Authorization Code">
<section anchor="eavesdropping"
title="Threat: Eavesdropping or leaking authorization codes">
<t>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 by different ways:</t>
<t><list style="symbols">
<t>Referrer headers: browsers frequently pass a
“referrer” 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.</t>
<t>Request logs: web server request logs commonly include
query parameters on requests.</t>
<t>Open redirectors: web sites sometimes need to send users to
another destination via a redirector. Open redirectors pose a
particular risk to web-based delegation protocols because the
redirector can leak verification codes to untrusted
destination sites.</t>
<t>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.</t>
</list>Note: A description of a similar attacks on the SAML
protocol can be found at
http://www.oasis-open.org/committees/download.php/3405/oasis-sstc-saml-bindings-1.1.pdf
(§4.1.1.9.1),
http://www.thomasgross.net/publications/papers/GroPfi2006-SAML2_Analysis_Janus.WSSS_06.pdf
and
http://www.oasis-open.org/committees/download.php/11191/sstc-gross-sec-analysis-response-01.pdf.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>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 or SSL
(see <xref target="conf_requests"></xref>).</t>
<t>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 <xref
target="bind_code_client_id"></xref>).</t>
<t>Limited duration of authorization codes - <xref
target="short_exp_time"></xref></t>
<t>The authorization server should enforce a one time usage
restriction (see <xref target="one_time_usage"></xref>).</t>
<t>If an Authorization Server observes multiple attempts to
redeem a authorization code, the Authorization Server may want
to revoke all tokens granted based on the authorization code
(see <xref target="automatic_code_revocation"></xref>).</t>
<t>In the absence of these countermeasures, reducing scope
(<xref target="limit_scope"></xref>) and expiry time (<xref
target="short_exp_time"></xref>) for access tokens can be used
to reduce the damage in case of leaks.</t>
<t>The client server may reload the target page of the
redirection URI in order to automatically cleanup the browser
cache.</t>
</list></t>
</section>
<section title="Threat: Obtain authorization codes from authorization server database">
<t>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. Impact: disclosure of all authorization codes,
most likely along with the respective redirect_uri and client_id
values.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Best practices for credential storage protection should be
employed - <xref target="cred_storage_prot"></xref></t>
<t>System security measures - <xref
target="std_sys"></xref></t>
<t>Store access token hashes only - <xref
target="noclear"></xref></t>
<t>Standard SQL injection countermeasures - <xref
target="std_sql"></xref></t>
</list></t>
</section>
<section title="Threat: Online guessing of authorization codes">
<t>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.</t>
<t>Impact: disclosure of single access token, probably also
associated refresh token.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Handle-based tokens must use high entropy: <xref
target="random_entropy"></xref></t>
<t>Assertion-based tokens should be signed: <xref
target="signed_tokens"></xref></t>
<t>Authenticate the client, adds another value the attacker
has to guess - <xref
target="depl_specific_secretes"></xref></t>
<t>Binding of authorization code to redirection URI, adds
another value the attacker has to guess - <xref
target="bind_code_redirect"></xref></t>
<t>Short expiration time - <xref
target="short_exp_time"></xref></t>
</list></t>
</section>
<section anchor="mal_client"
title="Threat: Malicious client obtains authorization">
<t>A malicious client could counterfeit a valid client and obtain
an access authorization that way. The malicious client could even
utilize screen scraping techniques in order to simulate the user
consent in the authorization flow.</t>
<t>Assumption: It is not the task of the authorization server to
protect the end-user's device from malicious software. This is the
responsibility of the platform running on the particular device
probably in cooperation with other components of the respective
ecosystem (e.g. an application management infrastructure). The
sole responsibility of the authorization server is to control
access to the end-user's resources living in resource servers and
to prevent unauthorized access to them. Based on this assumption,
the following countermeasures are available to cope with the
threat.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>The authorization server should authenticate the client, if
possible (see <xref target="depl_specific_secretes"></xref>).
Note: the authentication takes place after the end-user has
authorized the access.</t>
<t>The authorization server should validate the client's
redirection URI against the pre-registered redirection URI, if
one exists (see <xref target="val_redirect"></xref>). Note: An
invalid redirect URI indicates an invalid client whereas a
valid redirect URI not neccesserily indicates a valid client.
The level of confidence depends on the client type. For web
applications, the confidence is high since the redirect URI
refers to the globally unique network endpoint of this
application whose address is also validated using HTTPS server
authentication by the user agent. In contrast for native
clients, the redirect URI typically refers to device local
resources, e.g. a custom scheme. So a malicious client on a
particular device can use the valid redirect URI the
legitimate client uses on all other devices.</t>
<t>After authenticating the end-user, the authorization server
should ask him/her for consent. In this context, the user
should be explained the purpose, scope, and duration of the
authorization. Moreover, the authorization server should show
the user any identity information it has for that client. It
is up to the user to validate the binding of this data to the
particular application (e.g. Name) and to approve the
authorization request. (see <xref
target="validation_end_user"></xref>).</t>
<t>The authorization server should not perform automatic
re-authorizations for clients it is unable to reliably
authenticate or validate (see <xref
target="automatic_processing"></xref>).</t>
<t>If the authorization server automatically authenticates the
end-user, it may nevertheless require some user input in order
to prevent screen scraping. Examples are CAPTCHAs or
user-specific secrets like PIN codes.</t>
<t>The authorization server may also limit the scope of tokens
it issues to clients it cannot reliably authenticate (see
<xref target="limit_scope"></xref>).</t>
</list></t>
</section>
<section title="Threat: Authorization code phishing">
<t>A hostile party could impersonate the client site and get
access to the authorization code. This could be achieved using DNS
or ARP spoofing. This applies to clients, which are web
applications, thus the redirect URI is not local to the host where
the user's browser is running.</t>
<t>Impact: This affects web applications and may lead to a
disclosure of authorization codes and, potentially, the
corresponding access and refresh tokens.</t>
<t>Countermeasures:</t>
<t>It is strongly recommended that one of the following
countermeasures is utilized in order to prevent this attack:</t>
<t><list style="symbols">
<t>The redirection URI of the client should point to a HTTPS
protected endpoint and the browser should be utilized to
authenticate this redirection URI using server authentication
(see <xref target="server_authn"></xref>).</t>
<t>The authorization server should require the client to be
authenticated, i.e. confidential client, so the binding of the
authorization code to a certain client can be validated in a
reliable way (see <xref
target="bind_code_client_id"></xref>).</t>
</list></t>
</section>
<section title="Threat: User session impersonation">
<t>A hostile party could impersonate the client site and
impersonate the user's session on this client. This could be
achieved using DNS or ARP spoofing. This applies to clients, which
are web applications, thus the redirect URI is not local to the
host where the user's browser is running.</t>
<t>Impact: An attacker who intercepts the authorization code as it
is sent by the browser to the callback endpoint can gain access to
protected resources by submitting the authorization code to the
client. The client will exchange the authorization code for an
access token and use the access token to access protected
resources for the benefit of the attacker, delivering protected
resources to the attacker, or modifying protected resources as
directed by the attacker. If OAuth is used by the client to
delegate authentication to a social site (e.g. as in the
implementation of the "Facebook Login" button), the attacker can
use the intercepted authorization code to log in to the client as
the user.</t>
<t>Note: Authenticating the client during authorization code
exchange will not help to detect such an attack as it is the
legitimate client that obtains the tokens.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>In order to prevent an attacker from impersonating the
end-users session, the redirection URI of the client should
point to a HTTPS protected endpoint and the browser should be
utilized to authenticate this redirection URI using server
authentication (see <xref target="server_authn"></xref>)</t>
</list></t>
</section>
<section anchor="authz_code_leakage"
title="Threat: Authorization code leakage through counterfeit client">
<t>The attack leverages the authorization code grant type in an
attempt to get another user (victim) to log-in, authorize access
to his/her resources, and subsequently obtain the authorization
code and inject it into a client application using the attacker's
account. The goal is to associate an access authorization for
resources of the victim with the user account of the attacker on a
client site.</t>
<t>The attacker abuses an existing client application and combines
it with his own counterfeit client web site. The attack depends on
the victim expecting the client application to request access to a
certain resource server. The victim, seeing only a normal request
from an expected application, approves the request. The attacker
then uses the victim's authorization to gain access to the
information unknowingly authorized by the victim.</t>
<t>The attacker conducts the following flow:</t>
<t><list style="numbers">
<t>The attacker accesses the client web site (or application)
and initiates data access to a particular resource server. The
client web site in turn initiates an authorization request to
the resource server's authorization server. Instead of
proceeding with the authorization process, the attacker
modifies the authorization server end-user authorization URL
as constructed by the client to include a redirection URI
parameter referring to a web site under his control
(attacker's web site).</t>
<t>The attacker tricks another user (the victim) to open that
modified end-user authorization URI and to authorize access
(e.g. an email link, or blog link). The way the attacker
achieve that goal is out of scope.</t>
<t>Having clicked the link, the victim is requested to
authenticate and authorize the client site to have access.</t>
<t>After completion of the authorization process, the
authorization server redirects the user agent to the
attacker's web site instead of the original client web
site.</t>
<t>The attacker obtains the authorization code from his web
site by means out of scope of this document.</t>
<t>He then constructs a redirection URI to the target web site
(or application) based on the original authorization request's
redirection URI and the newly obtained authorization code and
directs his user agent to this URL. The authorization code is
injected into the original client site (or application).</t>
<t>The client site uses the authorization code to fetch a
token from the authorization server and associates this token
with the attacker's user account on this site.</t>
<t>The attacker may now access the victims resources using the
client site.</t>
</list></t>
<t>Impact: The attackers gains access to the victim's resources as
associated with his account on the client site.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>The attacker will need to use another redirection URI for
its authorization process than the target web site because it
needs to intercept the flow. So if the authorization server
associates the authorization code with the redirection URI of
a particular end-user authorization and validates this
redirection URI with the redirection URI passed to the token's
endpoint, such an attack is detected (see <xref
target="bind_code_redirect"></xref>).</t>
<t>The authorization server may also enforce the usage and
validation of pre-registered redirect URIs (see <xref
target="val_redirect"></xref>). This will allow for an early
recognition of session fixation attempts.</t>
<t>For native applications, one could also consider to use
deployment-specific client ids and secrets (see <xref
target="depl_specific_secretes"></xref>, along with the
binding of authorization code to client_id (see <xref
target="bind_code_client_id"></xref>), to detect such an
attack because the attacker does not have access the
deployment-specific secret. Thus he will not be able to
exchange the authorization code.</t>
<t>The client may consider using other flows, which are not
vulnerable to this kind of attacks such as "Implicit Grant" or
"Resource Owner Password Credentials" (see <xref
target="implicite_flow"></xref> or <xref
target="pwd_flow"></xref>).</t>
</list></t>
</section>
<section title="Threat: CSRF attack against redirect-uri">
<t>Cross-Site Request Forgery (CSRF) is a web-based attack whereby
HTTP requests are transmitted from a user that the website trusts
or has authenticated (e.g., via HTTP redirects or HTML forms).
CSRF attacks on OAuth approvals can allow an attacker to obtain
authorization to OAuth protected resources without the consent of
the User.</t>
<t>This attack works against the redirection URI used in the
authorization code flow. An attacker could authorize an
authorization code to their own protected resources on an
authorization server. He then aborts the redirect flow back to the
client on his device and tricks the victim into executing the
redirect back to the client. The client receives the redirect,
fetches the token(s) from the authorization server and associates
the victim's client session with the resources accessible using
the token.</t>
<t>Impact: The user accesses resources on behalf of the attacker.
The effective impact depends on the type of resource accessed. For
example, the user may upload private items to an attacker's
resources. Or when using OAuth in 3rd party login scenarios, the
user may associate his client account with the attacker's identity
at the external identity provider. This way the attacker could
easily access the victim's data at the client by logging in from
another device with his credentials at the external identity
provider.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>The state parameter should be used to link the
authorization request with the redirection URI used to deliver
the access token. <xref
target="link_state_uasession"></xref></t>
<t>Client developers and end-user can be educated not follow
untrusted URLs.</t>
</list></t>
</section>
<section title="Threat: Clickjacking attack against authorization">
<t>With Clickjacking, a malicious site loads the target site in a
transparent iframe overlaid on top of a set of dummy buttons which
are carefully constructed to be placed directly under important
buttons on the target site. When a user clicks a visible button,
they are actually clicking a button (such as an "Authorize"
button) on the hidden page.</t>
<t>Impact: An attacker can steal a user's authentication
credentials and access their resources</t>
<t>Countermeasure</t>
<t><list style="symbols">
<t>Native applications should use external browsers instead of
embedding browsers in a web view when requesting end-user
authorization</t>
<t>For newer browsers, avoidance of iFrames can be enforced
server side by using the X-FRAME-OPTION header - <xref
target="clickjacking_xframe"></xref></t>
<t>For older browsers, javascript framebusting techniques can
be used but may not be effective in all browsers.</t>
</list></t>
</section>
<section title="Threat: Resource Owner Impersonation">
<t>When a client requests access to protected resources, the
authorization flow normally involves the resource owner's explicit
response to the access request, either granting or denying access
to the protected resources. A malicious client can exploit
knowledge of the structure of this flow in order to gain
authorization without the resource owner's consent, by
transmitting the necessary requests programmatically, and
simulating the flow against the authorization server. That way,
the client may gain access to the victims resources without her
approval. An authorization server will be vulnerable to this
threat, if it uses non-interactive authentication mechanisms or
split the authorization flow across multiple pages.</t>
<t>The malicious client might embed a hidden HTML user agent,
interpret the HTML forms sent by the authorization server, and
automatically answer with the corresponding form post requests. As
a pre-requisite, the attacker must be able to execute the
authorization process in the context of an already authenticated
session of the resource owner with the authorization server. There
are different ways to achieve this:</t>
<t><list style="symbols">
<t>The malicious client could abuse an existing session in an
external browser or cross-browser cookies on the particular
device.</t>
<t>It could also request authorization for a particular scope
and silently abuse the resulting session in his browser
instance to "silently" request another scope.</t>
<t>Alternatively, the attacker might exploit an authorization
server's ability to authenticate the resource owner
automatically and without user interactions, e.g. based on
certificates.</t>
</list> In all cases, such an attack is limited to clients
running on the victim's device, within the user agent or as native
app.</t>
<t>Please note: Such attacks cannot be prevented using CSRF
countermeasures, since the attacker just "executes" the URLs as
prepared by the authorization server including any nonce etc.</t>
<t>Countermeasures:</t>
<t>Authorization servers should decide, based on an analysis of
the risk associated with this threat, whether to assume, detect,
or to prevent this threat.</t>
<t>In order to prevent such an attack, the authorization server
may force an user interaction based on non-predictable input
values as part of the user consent approval. The authorization
server could</t>
<t><list style="symbols">
<t>combine password authentication and user consent in a
single form,</t>
<t>make use of CAPTCHAs, or</t>
<t>or use one-time secrets send out of bound to the resource
owner (e.g. via text or instance message).</t>
</list> Alternatively in order to allow the resource owner to
detect abuse, the authorization server could notify the resource
owner of any approval by appropriate means, e.g. text or instant
message or e-Mail.</t>
</section>
<section title="Threat: DoS, Exhaustion of resources attacks">
<t>If an authorization server includes a nontrivial amount of
entropy in authorization codes or access tokens (limiting the
number of possible codes/tokens) and automatically grants either
without user intervention and has no limit on code or access
tokens per user, an attacker could exhaust the pool by repeatedly
directing user(s) browser to request code or access tokens. This
is because more entropy means a larger number of tokens can be
issued.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>The authorization server should consider limiting the
number of access tokens granted per user. The authorization
server should include a nontrivial amount of entropy in
authorization codes.</t>
</list></t>
</section>
<section anchor="semi"
title="Threat: DoS using manufactured authorization codes"
toc="default">
<t>An attacker who owns a botnet can locate the redirect URIs of
clients that listen on HTTP, access them with random authorization
codes, and cause a large number of HTTPS connections to be
concentrated onto the authorization server. This can result in a
DoS attack on the authorization server.</t>
<t>This attack can still be effective even when CSRF defense/the
'state' parameter are deployed on the client side. With such a
defense, the attacker might need to incur an additional HTTP
request to obtain a valid CSRF code/ state parameter. This
apparently cuts down the effectiveness of the attack by a factor
of 2. However, if the HTTPS/HTTP cost ratio is higher than 2 (the
cost factor is estimated to be around 3.5x at <eref
target="http://www.semicomplete.com/blog/geekery/ssl-latency.html"></eref>)
the attacker still achieves a magnification of resource
utilization at the expense of the authorization server.</t>
<t>Impact: There are a few effects that the attacker can
accomplish with this OAuth flow that they cannot easily achieve
otherwise.</t>
<t><list style="numbers">
<t>Connection laundering: With the clients as the relay
between the attacker and the authorization server, the
authorization server learns little or no information about the
identity of the attacker. Defenses such rate limiting on the
offending attacker machines are less effective due to the
difficulty to identify the attacking machines. Although an
attacker could also launder its connections through an
anonymizing systems such as Tor, the effectiveness of that
approach depends on the capacity of the annoying system. On
the other hand, a potentially large number of OAuth clients
could be utilized for this attack.</t>
<t>Asymmetric resource utilization: The attacker incurs the
cost of an HTTP connection and causes an HTTPS connection to
be made on the authorization server; and the attacker can
co-ordinate the timing of such HTTPS connections across
multiple clients relatively easily. Although the attacker
could achieve something similar, say, by including an iframe
pointing to the HTTPS URL of the authorization server in an
HTTP web page and lure web users to visit that page, timing
attacks using such a scheme may be more difficult as it seems
nontrivial to synchronize a large number of users to
simultaneously visit a particular site under the attacker's
control.</t>
</list>Countermeasures</t>
<t><list style="symbols">
<t>Though not a complete countermeasure by themselves, CSRF
defense and the 'state' parameter created with secure random
codes should be deployed on the client side. The client should
forward the authorization code to the authorization server
only after both the CSRF token and the 'state' parameter are
validated.</t>
<t>If the client authenticates the user, either through a
single sign on protocol ( such as OpenID / Facebook Connect )
or through local authentication, the client should suspend the
access by a user account if the number of invalid
authorization codes submitted by this user exceeds a certain
threshold.</t>
<t>The authorization server should send an error response to
the client reporting an invalid authorization code and rate
limit or disallow connections from clients whose number of
invalid requests exceeds a threshold.</t>
<t>The authorization server may in addition sign the
authorization code using the public key from its SSL
certificate, and require the client to validate the signature.
To enhance interoperability between multiple clients and
authorization servers, a standard procedure to create and
validate the signature (including what attributes to sign) may
be developed and agreed between the clients and the
servers.</t>
</list></t>
</section>
</section>
<section anchor="implicite_flow" title="Implicit Grant">
<t>In the implicit grant type flow, the access token is directly
returned to the client as a fragment part of the redirection URI. It
is assumed that the token is not sent to the redirection URI target
as HTTP user agents do not send the fragment part of URIs to HTTP
servers. Thus an attacker cannot eavesdrop the access token on this
communication path and It cannot leak through HTTP referee
headers.</t>
<section title="Threat: Access token leak in transport/end-points">
<t>This token might be eavesdropped by an attacker. The token is
sent from server to client via a URI fragment of the redirection
URI. If the communication is not secured or the end-point is not
secured, the token could be leaked by parsing the returned
URI.</t>
<t>Impact: the attacker would be able to assume the same rights
granted by the token.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>The authorization server should ensure confidentiality of
the response from the authorization server to the client (see
<xref target="conf_requests"></xref>).</t>
</list></t>
</section>
<section title="Threat: Access token leak in browser history">
<t>An attacker could obtain the token from the browser's history.
Note this means the attacker needs access to the particular
device.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Shorten token duration (see <xref
target="short_exp_time"></xref>) and reduced scope of the
token may reduce the impact of that attack (see <xref
target="limit_scope"></xref>).</t>
<t>Make these requests non-cachable</t>
<t>Native applications can directly embed a browser widget and
therewith gain full control of the cache. So the application
can cleanup browser history after authorization process.</t>
</list></t>
</section>
<section anchor="mal_client2"
title="Threat: Malicious client obtains authorization">
<t>An malicious client could attempt to obtain a token by
fraud.</t>
<t>The same countermeasures as for <xref
target="mal_client"></xref> are applicable, except client
authentication.</t>
</section>
<section title="Threat: Manipulation of scripts">
<t>A hostile party could act as the client web server and replace
or modify the actual implementation of the client (script). This
could be achieved using DNS or ARP spoofing. This applies to
clients implemented within the Web Browser in a scripting
language.</t>
<t>Impact: The attacker could obtain user credential information
and assume the full identity of the user.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>The authorization server should authenticate the server
from which scripts are obtained (see <xref
target="server_authn"></xref>).</t>
<t>The client should ensure that scripts obtained have not
been altered in transport (see <xref
target="conf_requests"></xref>).</t>
<t>Introduce one time per-use secrets (e.g. client_secret)
values that can only be used by scripts in a small time window
once loaded from a server. The intention would be to reduce
the effectiveness of copying client-side scripts for re-use in
an attackers modified code.</t>
</list></t>
</section>
<section title="Threat: CSRF attack against redirect-uri">
<t>Cross-Site Request Forgery (CSRF) is a web-based attack whereby
HTTP requests are transmitted from a user that the website trusts
or has authenticated (e.g., via HTTP redirects or HTML forms).
CSRF attacks on OAuth approvals can allow an attacker to obtain
authorization to OAuth protected resources without the consent of
the User.</t>
<t>This attack works against the redirection URI used in the
implicit grant flow. An attacker could acquire an access token to
their own protected resources. He could then construct a
redirection URI and embed their access token in that URI. If he
can trick the user into following the redirection URI and the
client does not have protection against this attack, the user may
have the attacker's access token authorized within their
client.</t>
<t>Impact: The user accesses resources on behalf of the attacker.
The effective impact depends on the type of resource accessed. For
example, the user may upload private items to an attacker's
resources. Or when using OAuth in 3rd party login scenarios, the
user may associate his client account with the attacker's identity
at the external identity provider. This way the attacker could
easily access the victim's data at the client by logging in from
another device with his credentials at the external identity
provider.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>The state parameter should be used to link the
authorization request with the redirection URI used deliver
the access token. This will ensure the client is not tricked
into completing any redirect callback unless it is linked to
an authorization request the client initiated. The state
parameter should be unguessable and the client should be
capable of keeping the state parameter secret.</t>
<t>Client developers and end-user can be educated not follow
untrusted URLs.</t>
</list></t>
</section>
</section>
<section anchor="pwd_flow" title="Resource Owner Password Credentials">
<t>The “Resource Owner Password Credentials” grant type
(see <xref target="I-D.ietf-oauth-v2"></xref>, Section 4.3), often
used for legacy/migration reasons, allows a client to request an
access token using an end-users user-id and password along with its
own credential. This grant type has higher risk because it maintains
the uid/password anti-pattern. Additionally, because the user does
not have control over the authorization process, clients using this
grant type are not limited by scope, but instead have potentially
the same capabilities as the user themselves. As there is no
authorization step, the ability to offer token revocation is
bypassed.</t>
<t>Impact: The resource server can only differentiate scope based on
the access token being associated with a particular client. The
client could also acquire long-living tokens and pass them up to a
attacker web service for further abuse. The client, eavesdroppers,
or end-points could eavesdrop user id and password.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Except for migration reasons, minimize use of this grant
type</t>
<t>The authorization server should validate the client id
associated with the particular refresh token with every refresh
request - <xref target="binding_refresh_client_id"></xref></t>
<t>As per the core Oauth spec, the authorization server must
ensure that these transmissions are protected using
transport-layer mechanisms such as TLS or SSL (see <xref
target="conf_requests"></xref>).</t>
</list></t>
<section title="Threat: Accidental exposure of passwords at client site">
<t>If the client does not provide enough protection, an attacker
or disgruntled employee could retrieve the passwords for a
user.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Use other flows, which do not rely on the client's
cooperation for secure resource owner credential handling</t>
<t>Use digest authentication instead of plaintext credential
processing</t>
<t>Obfuscation of passwords in logs</t>
</list></t>
</section>
<section title="Threat: Client obtains scopes without end-user authorization">
<t>All interaction with the resource owner is performed by the
client. Thus it might, intentionally or unintentionally, happen
that the client obtains a token with scope unknown for or
unintended by the resource owner. For example, the resource owner
might think the client needs and acquires read-only access to its
media storage only but the client tries to acquire an access token
with full access permissions.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Use other flows, which do not rely on the client's
cooperation for resource owner interaction</t>
<t>The authorization server may generally restrict the scope
of access tokens (<xref target="limit_scope"></xref>) issued
by this flow. If the particular client is trustworthy and can
be authenticated in a reliable way, the authorization server
could relax that restriction. Resource owners may prescribe
(e.g. in their preferences) what the maximum scope is for
clients using this flow.</t>
<t>The authorization server could notify the resource owner by
an appropriate media, e.g. e-Mail, of the grant issued (see
<xref target="informed"></xref>).</t>
</list></t>
</section>
<section title="Threat: Client obtains refresh token through automatic authorization">
<t>All interaction with the resource owner is performed by the
client. Thus it might, intentionally or unintentionally, happen
that the client obtains a long-term authorization represented by a
refresh token even if the resource owner did not intend so.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Use other flows, which do not rely on the client's
cooperation for resource owner interaction</t>
<t>The authorization server may generally refuse to issue
refresh tokens in this flow (see <xref
target="restricted_refresh"></xref>). If the particular client
is trustworthy and can be authenticated in a reliable way (see
client authentication), the authorization server could relax
that restriction. Resource owners may allow or deny (e.g. in
their preferences) to issue refresh tokens using this flow as
well.</t>
<t>The authorization server could notify the resource owner by
an appropriate media, e.g. e-Mail, of the refresh token issued
(see <xref target="informed"></xref>).</t>
</list></t>
</section>
<section title="Threat: Obtain user passwords on transport">
<t>An attacker could attempt to eavesdrop the transmission of
end-user credentials with the grant type „password“
between client and server.</t>
<t>Impact: disclosure of a single end-users password.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Confidentiality of Requests - <xref
target="conf_requests"></xref></t>
<t>alternative authentication means, which do not require to
send plaintext credentials over the wire (Examples: Digest
authentication)</t>
</list></t>
</section>
<section title="Threat: Obtain user passwords from authorization server database">
<t>An attacker may obtain valid username/password combinations
from the authorization server's database by gaining access to the
database or launching a SQL injection attack.</t>
<t>Impact: disclosure of all username/password combinations. The
impact may exceed the domain of the authorization server since
many users tend to use the same credentials on different
services.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Credential storage protection can be employed - <xref
target="cred_storage_prot"></xref></t>
</list></t>
</section>
<section title="Threat: Online guessing">
<t>An attacker may try to guess valid username/password
combinations using the grant type „password“.</t>
<t>Impact: Revelation of a single username/password
combination.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Password policy - <xref target="pwd_policy"></xref></t>
<t>Lock accounts - <xref target="lock_accounts"></xref></t>
<t>Tar pit - <xref target="tar_pit"></xref></t>
<t>CAPTCHA - <xref target="captchas"></xref></t>
<t>Abandon on grant type „password“</t>
<t>Client authentication (see <xref
target="client_aa"></xref>) will provide another
authentication factor and thus hinder the attack.</t>
</list></t>
</section>
</section>
<section title="Client Credentials">
<t>Client credentials (see <xref target="I-D.ietf-oauth-v2"></xref>,
Section 3) consist of an identifier (not secret) combined with an
additional means (such as a matching client secret) of
authenticating a client. The threats to this grant type are similar
to <xref target="pwd_flow"></xref>.</t>
</section>
</section>
<section title="Refreshing an Access Token">
<section title="Threat: Eavesdropping refresh tokens from authorization server">
<t>An attacker may eavesdrop refresh tokens when they are
transmitted from the authorization server to the client.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>As per the core OAuth spec, the Authorization servers must
ensure that these transmissions are protected using
transport-layer mechanisms such as TLS or SSL (see <xref
target="conf_requests"></xref>).</t>
<t>If end-to-end confidentiality cannot be guaranteed, reducing
scope (see <xref target="limit_scope"></xref>) and expiry time
(see <xref target="short_exp_time"></xref>) for issued access
tokens can be used to reduce the damage in case of leaks.</t>
</list></t>
</section>
<section title="Threat: Obtaining refresh token from authorization server database">
<t>This threat is applicable if the authorization server stores
refresh tokens as handles in a database. An attacker may obtain
refresh tokens from the authorization server's database by gaining
access to the database or launching a SQL injection attack.</t>
<t>Impact: disclosure of all refresh tokens</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Credential storage protection - <xref
target="cred_storage_prot"></xref></t>
<t>Bind token to client id, if the attacker cannot obtain the
required id and secret - <xref
target="bind_token_client_id"></xref></t>
</list></t>
</section>
<section title="Threat: Obtain refresh token by online guessing">
<t>An attacker may try to guess valid refresh token values and send
it using the grant type „refresh_token“ in order to
obtain a valid access token.</t>
<t>Impact: exposure of single refresh token and derivable access
tokens.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>For handle-based designs - <xref
target="random_entropy"></xref></t>
<t>For assertion-based designs - <xref
target="signed_tokens"></xref></t>
<t>Bind token to client id, because the attacker would guess the
matching client id, too (see <xref
target="bind_token_client_id"></xref>)</t>
<t>Authenticate the client, adds another element the attacker
has to guess (see <xref
target="depl_specific_secretes"></xref>)</t>
</list></t>
</section>
<section title="Threat: Obtain refresh token phishing by counterfeit authorization server">
<t>An attacker could try to obtain valid refresh tokens by proxying
requests to the authorization server. Given the assumption that the
authorization server URL is well-known at development time or can at
least be obtained from a well-known resource server, the attacker
must utilize some kind of spoofing in order to succeed.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Server authentication (as described in <xref
target="server_authn"></xref>)</t>
</list></t>
</section>
</section>
<section title="Accessing Protected Resources">
<section title="Threat: Eavesdropping access tokens on transport">
<t>An attacker could try to obtain a valid access token on transport
between client and resource server. As access tokens are shared
secrets between authorization and resource server, they should be
treated with the same care as other credentials (e.g. end-user
passwords).</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Access tokens sent as bearer tokens, should not be sent in
the clear over an insecure channel. As per the core OAuth spec,
transmission of access tokens must be protected using
transport-layer mechanisms such as TLS or SSL (see <xref
target="conf_requests"></xref>).</t>
<t>A short lifetime reduces impact in case tokens are
compromised (see <xref target="short_exp_time"></xref>).</t>
<t>The access token can be bound to a client's identity and
require the client to prove legitimate ownership of the token to
the resource server (see <xref
target="authn_requests"></xref>).</t>
</list></t>
</section>
<section title="Threat: Replay authorized resource server requests">
<t>An attacker could attempt to replay valid requests in order to
obtain or to modify/destroy user data.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>The resource server should utilize transport security measure
in order to prevent such attacks (see <xref
target="conf_requests"></xref>). This would prevent the attacker
from capturing valid requests.</t>
<t>Alternatively, the resource server could employ signed
requests (see <xref target="signed_requests"></xref>) along with
nounces and timestamps in order to uniquely identify requests.
The resource server should detect and refuse every replayed
request.</t>
</list></t>
</section>
<section title="Threat: Guessing access tokens">
<t>Where the token is a handle, the attacker may use attempt to
guess the access token values based on knowledge they have from
other access tokens.</t>
<t>Impact: Access to a single user's data.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Handle Tokens should have a reasonable entropy (see <xref
target="random_entropy"></xref>) in order to make guessing a
valid token value difficult.</t>
<t>Assertion (or self-contained token ) tokens contents should
be protected by a digital signature (see <xref
target="signed_tokens"></xref>).</t>
<t>Security can be further strengthened by using a short access
token duration (see <xref target="exp_time"></xref> and <xref
target="short_exp_time"></xref>).</t>
</list></t>
</section>
<section title="Threat: Access token phishing by counterfeit resource server">
<t>An attacker may pretend to be a particular resource server and to
accept tokens from a particular authorization server. If the client
sends a valid access tokens to this counterfeit resource server, the
server in turn may use that token to access other services on behalf
of the resource owner.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Clients should not make authenticated requests with an access
token to unfamiliar resource servers, regardless of the presence
of a secure channel. If the resource server address is
well-known to the client, it may authenticate the resource
servers (see <xref target="server_authn"></xref>).</t>
<t>Associate the endpoint address of the resource server the
client talked to with the access token (e.g. in an audience
field) and validate association at legitimate resource server.
The endpoint address validation policy may be strict (exact
match) or more relaxed (e.g. same host). This would require to
tell the authorization server the resource server endpoint
address in the authorization process.</t>
<t>Associate an access token with a client and authenticate the
client with resource server requests (typically via signature in
order to not disclose secret to a potential attacker). This
prevents the attack because the counterfeit server is assumed to
miss the capabilities to correctly authenticate on behalf of the
legitimate client to the resource server (<xref
target="authn_requests"></xref>).</t>
<t>Restrict the token scope (see <xref
target="limit_scope"></xref>) and or limit the token to a
certain resource server (<xref
target="bind_token_rs"></xref>).</t>
</list></t>
</section>
<section title="Threat: Abuse of token by legitimate resource server or client">
<t>A legitimate resource server could attempt to use an access token
to access another resource servers. Similarly, a client could try to
use a token obtained for one server on another resource server.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Tokens should be restricted to particular resource servers
(see <xref target="bind_token_rs"></xref>).</t>
</list></t>
</section>
<section title="Threat: Leak of confidential data in HTTP-Proxies">
<t>The HTTP Authorization scheme (OAuth HTTP Authorization Scheme)
is optional. However, [RFC2616](Fielding, R., Gettys, J., Mogul, J.,
Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee,
“Hypertext Transfer Protocol -- HTTP/1.1,” .) relies on
the Authorization and WWW-Authenticate headers to distinguish
authenticated content so that it can be protected. Proxies and
caches, in particular, may fail to adequately protect requests not
using these headers. For example, private authenticated content may
be stored in (and thus retrievable from) publicly-accessible
caches.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Resource servers not using the HTTP Authorization scheme
(OAuth HTTP Authorization Scheme - see <xref
target="authz_header"></xref>) should take care to use other
mechanisms, such as the Cache-Control header, to minimize the
risk that authenticated content is not protected.</t>
<t>Reducing scope (see <xref target="limit_scope"></xref>) and
expiry time (<xref target="short_exp_time"></xref>) for access
tokens can be used to reduce the damage in case of leaks.</t>
</list></t>
</section>
<section title="Threat: Token leakage via logfiles and HTTP referrers">
<t>If access tokens are sent via URI query parameters, such tokens
may leak to log files and HTTP referrers.</t>
<t>Countermeasures:</t>
<t><list style="symbols">
<t>Use authorization headers or POST parameters instead of URI
request parameters (see <xref
target="authz_header"></xref>).</t>
<t>Set logging configuration appropriately</t>
<t>Prevent unauthorized persons from access to system log files
(see <xref target="std_sys"></xref>)</t>
<t>HTTP referrers can be prevented by reloading the target page
again without URI parameters</t>
<t>Abuse of leaked access tokens can be prevented by enforcing
authenticated requests (see <xref
target="authn_requests"></xref>).</t>
<t>The impact of token leakage may be reduced by limiting scope
(see <xref target="limit_scope"></xref>) and duration (see <xref
target="short_exp_time"></xref>) and enforcing one time token
usage (see <xref target="one_time_usage"></xref>).</t>
</list></t>
</section>
</section>
</section>
<section anchor="security_considerations" title="Security Considerations">
<t>This section describes the countermeasures as recommended to mitigate
the threats as described in Section 4.</t>
<section title="General">
<t>The general section covers consideratios that apply generally
across all OAuth components (client, resource server, token server,
and user-agents).</t>
<section anchor="conf_requests" title="Confidentiality of Requests">
<t>This is applicable to all requests sent from client to
authorization server or resource server. While OAuth provides a
mechanism for verifying the integrity of requests, it provides no
guarantee of request confidentiality. Unless further precautions are
taken, eavesdroppers will have full access to request content and
may be able to mount interception or replay attacks through using
content of request, e.g. secrets or tokens.</t>
<t>Attacks can be mitigated by using transport-layer mechanisms such
as TLS or SSL. VPN may considered as well.</t>
<t>This is a countermeasure against the following threats:</t>
<t><list style="symbols">
<t>Replay of access tokens obtained on tokens endpoint or
resource server's endpoint</t>
<t>Replay of refresh tokens obtained on tokens endpoint</t>
<t>Replay of authorization codes obtained on tokens endpoint
(redirect?)</t>
<t>Replay of user passwords and client secrets</t>
</list></t>
</section>
<section anchor="server_authn" title="Server authentication">
<t>HTTPS server authentication or similar means can be used to
authenticate the identity of a server. The goal is to reliably bind
the DNS name of the server to the public key presented by the server
during connection establishment.</t>
<t>The client should validate the binding of the server to its
domain name. If the server fails to prove that binding, it is
considered a man-in-the-middle attack. The security measure depends
on the certification authorities the client trusts for that purpose.
Clients should carefully select those trusted CAs and protect the
storage for trusted CA certificates from modifications.</t>
<t>This is a countermeasure against the following threats:</t>
<t><list style="symbols">
<t>Spoofing</t>
<t>Proxying</t>
<t>Phishing by counterfeit servers</t>
</list></t>
</section>
<section anchor="informed"
title="Always keep the resource owner informed">
<t>Transparency to the resource owner is a key element of the OAuth
protocol. The user should always be in control of the authorization
processes and get the necessary information to meet informed
decisions. Moreover, user involvement is a further security
countermeasure. The user can probably recognize certain kinds of
attacks better than the authorization server. Information can be
presented/exchanged during the authorization process, after the
authorization process, and every time the user wishes to get
informed by using techniques such as:</t>
<t><list style="symbols">
<t>User consent forms</t>
<t>Notification messages (e-Mail, SMS, …)</t>
<t>Activity/Event logs</t>
<t>User self-care applications or portals</t>
</list></t>
</section>
<section title="Credentials">
<t>This sections describes countermeasures used to protect all kinds
of credentials from unauthorized access and abuse. Credentials are
long term secrets, such as client secrets and user passwords as well
as all kinds of tokens (refresh and access token) or authorization
codes.</t>
<section anchor="cred_storage_prot"
title="Credential Storage Protection">
<t>Administrators should undertake industry best practices to
protect the storage of credentials. Such practices may include but
are not limited to the following sub-sections.</t>
<section anchor="std_sys" title="Standard System Security Means">
<t>A server system may be locked down so that no attacker may
get access to sensible configuration files and databases.</t>
</section>
<section anchor="std_sql"
title="Standard SQL Injection Countermeasures">
<t>If a client identifier or other authentication component is
queried or compared against a SQL Database it may become
possible for an injection attack to occur if parameters received
are not validated before submission to the database.</t>
<t><list style="symbols">
<t>Ensure that server code is using the minimum database
privileges possible to reduce the "surface" of possible
attacks.</t>
<t>Avoid dynamic SQL using concatenated input. If possible,
use static SQL.</t>
<t>When using dynamic SQL, parameterize queries using bind
arguments. Bind arguments eliminate possibility of SQL
injections.</t>
<t>Filter and sanitize the input. For example, if an
identifier has a known format, ensure that the supplied
value matches the identifier syntax rules.</t>
</list></t>
</section>
<section anchor="noclear"
title="No cleartext storage of credentials">
<t>The authorization server should not store credential in clear
text. Typical approaches are to store hashes instead. If the
credential lacks a reasonable entropy level (because it is a
user password) an additional salt will harden the storage to
prevent offline dictionary attacks. Note: Some authentication
protocols require the authorization server to have access to the
secret in the clear. Those protocols cannot be implemented if
the server only has access to hashes.</t>
</section>
<section title="Encryption of credentials">
<t>For client applications, insecurely persisted client
credentials are easy targets for attackers to obtain. Store
client credentials using an encrypted persistence mechanism such
as a keystore or database. Note that compiling client
credentials directly into client code makes client applications
vulnerable to scanning as well as difficult to administer should
client credentials change over time.</t>
</section>
<section title="Use of asymmetric cryptography">
<t>Usage of asymmetric cryptography will free the authorization
server of the obligation to manage credentials.</t>
</section>
</section>
<section anchor="online_secrets" title="Online attacks on secrets">
<section anchor="pwd_policy" title="Password policy">
<t>The authorization server may decide to enforce a complex user
password policy in order to increase the user passwords'
entropy. This will hinder online password attacks.</t>
</section>
<section anchor="high_entropy" title="High entropy of secrets">
<t>When creating token handles or other secrets not intended for
usage by human users, the authorization server should include a
reasonable level of entropy in order to mitigate the risk of
guessing attacks.</t>
<t>The token value should be constructed from a
cryptographically strong random or pseudo-random number sequence
[RFC1750] generated by the Authorization Server. The probability
of any two Authorization Code values being identical should be
less than or equal to 2^(-128) and should be less than or equal
to 2^(-160).</t>
</section>
<section anchor="lock_accounts" title="Lock accounts">
<t>Online attacks on passwords can be mitigated by locking the
respective accounts after a certain number of failed
attempts.</t>
<t>Note: This measure can be abused to lock down legitimate
service users.</t>
</section>
<section anchor="tar_pit" title="Tar pit">
<t>The authorization server may react on failed attempts to
authenticate by username/password by temporarily locking the
respective account and delaying the response for a certain
duration. This duration may increase with the number of failed
attempts. The objective is to slow the attackers attempts on a
certain username down.</t>
<t>Note: this may require a more complex and stateful design of
the authorization server.</t>
</section>
<section anchor="captchas" title="Usage of CAPTCHAs">
<t>The idea is to prevent programs from automatically checking
huge number of passwords by requiring human interaction.</t>
<t>Note: this has a negative impact on user experience.</t>
</section>
</section>
</section>
<section title="Tokens (access, refresh, code)">
<section anchor="limit_scope" title="Limit token scope">
<t>The authorization server may decide to reduce or limit the
scope associated with a token. Basis of this decision is out of
scope, examples are:</t>
<t><list style="symbols">
<t>a client-specific policy, e.g. issue only less powerful
tokens to public clients,</t>
<t>a service-specific policy, e.g. it a very sensible
service,</t>
<t>a resource-owner specific setting, or</t>
<t>combinations of such policies and preferences.</t>
</list>The authorization server may allow different scopes
dependent on the grant type. For example, end-user authorization
via direct interaction with the end-user (authorization code)
might be considered more reliable than direct authorization via
grant type username/password. This means will reduce the impact of
the following threats:</t>
<t><list style="symbols">
<t>token leakage</t>
<t>token issuance to malicious software</t>
<t>unintended issuance of to powerful tokens with resource
owner credentials flow</t>
</list></t>
</section>
<section anchor="exp_time" title="Expiration time">
<t>Tokens should generally expire after a reasonable duration.
This complements and strengthens other security measures (such as
signatures) and reduces the impact of all kinds of token
leaks.</t>
</section>
<section anchor="short_exp_time" title="Short expiration time">
<t>A short expiration time for tokens is a protection means
against the following threats:</t>
<t><list style="symbols">
<t>replay</t>
<t>reduce impact of token leak</t>
<t>reduce likelihood of successful online guessing</t>
</list>Note: Short token duration requires preciser clock
synchronisation between authorization server and resource server.
Furthermore, shorter duration may require more token refreshments
(access token) or repeated end-user authorization processes
(authorization code and refresh token).</t>
</section>
<section anchor="one_time_usage"
title="Limit number of usages/ One time usage">
<t>The authorization server may restrict the number of requests or
operations which can be performed with a certain token. This
mechanism can be used to mitigate the following threats:</t>
<t><list style="symbols">
<t>replay of tokens</t>
<t>reduce likelihood of successful online guessing</t>
</list>For example, if an Authorization Server observes more
than one attempt to redeem a authorization code, the Authorization
Server may want to revoke all access tokens granted based on the
authorization code as well as reject the current request.</t>
<t>As with the authorization code, access tokens may also have a
limited number of operations. This forces client applications to
either re-authenticate and use a refresh token to obtain a fresh
access token, or it forces the client to re-authorize the access
token by involving the user.</t>
</section>
<section anchor="bind_token_rs"
title="Bind tokens to a particular resource server (Audience)">
<t>Authorization servers in multi-service environments may
consider issuing tokens with different content to different
resource servers and to explicitly indicate in the token the
target server a token is intended to be sent to (see Audience in
SAML Assertions). This countermeasure can be used in the following
situations:</t>
<t><list style="symbols">
<t>It reduces the impact of a successful replay attempt, since
the token is applicable to a single resource server, only.</t>
<t>It prevents abuse of a token by a rough resource server or
client, since the token can only be used on that server. It is
rejected by other servers.</t>
<t>It reduces the impact of a leakage of a valid token to a
counterfeit resource server.</t>
</list></t>
</section>
<section anchor="endpoint_audience"
title="Use endpoint address as token audience">
<t>This may be used to indicate to a resource server, which
endpoint address has been used to obtain the token. This measure
will allow to detect requests from a counterfeit resource server,
since such token will contain the endpoint address of that
server.</t>
</section>
<section anchor="audience_token_scope"
title="Audience and Token scopes">
<t>Deployments may consider only using tokens with explicitly
defined scope, where every scope is associated with a particular
resource server. This approach can be used to mitigate attacks,
where a resource server or client uses a token for a different
then the intended purpose.</t>
</section>
<section anchor="bind_token_client_id"
title="Bind token to client id">
<t>An authorization server may bind a token to a certain client
identity. This identity should be validated for every request with
that token. This means can be used, to</t>
<t><list style="symbols">
<t>detect token leakage and</t>
<t>prevent token abuse.</t>
</list>Note: Validating the client identity may require the
target server to authenticate the client's identity. This
authentication can be based on secrets managed independent of the
token (e.g. pre-registered client id/secret on authorization
server) or sent with the token itself (e.g. as part of the
encrypted token content).</t>
</section>
<section anchor="signed_tokens" title="Signed tokens">
<t>Self-contained tokens should be signed in order to detect any
attempt to modify or produce faked tokens.</t>
</section>
<section anchor="enc_token" title="Encryption of token content">
<t>Self-contained may be encrypted for privacy reasons or to
protect system internal data.</t>
</section>
<section anchor="random_entropy"
title="Random token value with high entropy">
<t>When creating token handles, the authorization server should
include a reasonable level of entropy in order to mitigate the
risk of guessing attacks. The token value should be constructed
from a cryptographically strong random or pseudo-random number
sequence [RFC1750] generated by the Authorization Server. The
probability of any two token values being identical should be less
than or equal to 2^(-128) and should be less than or equal to
2^(-160).</t>
</section>
<section title="Assertion formats">
<t>For service providers intending to implement an assertion-based
token design it is highly recommended to adopt a standard
assertion format (such as SAML or JWT) that implements
[draft-ietf-oauth-assertions].</t>
</section>
</section>
<section anchor="access_tokens" title="Access tokens">
<t>The following measures should be used to protect access
tokens</t>
<t><list style="symbols">
<t>keep them in transient memory (accessible by the client
application only)</t>
<t>protect from exposure to 3rd parties (malicious
application)</t>
<t>limit number of access tokens granted to a user</t>
</list></t>
</section>
</section>
<section title="Authorization Server">
<t>This section describes considerations related to the OAuth
Authorization Server end-point.</t>
<section title="Authorization Codes">
<section anchor="automatic_code_revocation"
title="Automatic revocation of derived tokens if abuse is detected">
<t>If an Authorization Server observes multiple attempts to redeem
an authorization grant (e.g. such as an authorization code), the
Authorization Server may want to revoke all tokens granted based
on the authorization grant.</t>
</section>
</section>
<section anchor="refresh_tokens" title="Refresh tokens">
<section anchor="restricted_refresh"
title="Restricted issuance of refresh tokens">
<t>The authorization server may decide based on an appropriate
policy not to issue refresh tokens. Since refresh tokens are long
term credentials, they may be subject theft. For example, if the
authorization server does not trust a client to securely store
such tokens, it may refuse to issue such a client a refresh
token.</t>
</section>
<section anchor="binding_refresh_client_id"
title="Binding of refresh token to client_id">
<t>The authorization server should bind every refresh token to the
id of the client such a token was originally issued to and
validate this binding for every request to refresh that token. If
possible (e.g. confidential clients), the authorization server
should authenticate the respective client.</t>
<t>This is a countermeasure against refresh token theft or
leakage.</t>
<t>Note: This binding should be protected from unauthorized
modifications.</t>
</section>
<section anchor="refresh_replace" title="Refresh Token Rotation">
<t>Refresh token rotation is intended to automatically detect and
prevent attempts to use the same refresh token in parallel from
different apps/devices. This happens if a token gets stolen from
the client and is subsequently used by the attacker and the
legitimate client. The basic idea is to change the refresh token
value with every refresh request in order to detect attempts to
obtain access tokens using old refresh tokens. Since the
authorization server cannot determine whether the attacker or the
legitimate client is trying to access, in case of such an access
attempt the valid refresh token and the access authorization
associated with it are both revoked.</t>
<t>The OAuth specification supports this measure in that the
tokens response allows the authorization server to return a new
refresh token even for requests with grant type
"refresh_token“.</t>
<t>Note: this measure may cause problems in clustered environments
since usage of the currently valid refresh token must be ensured.
In such an environment, other measures might be more
appropriate.</t>
</section>
<section anchor="refresh_revocation"
title="Refresh Token Revocation">
<t>The authorization server may allow clients or end-users to
explicitly request the invalidation of refresh tokens.</t>
<t>This is a countermeasure against:</t>
<t><list style="symbols">
<t>device theft,</t>
<t>impersonation of resource owner, or</t>
<t>suspected compromised client applications.</t>
</list></t>
</section>
<section anchor="device_id" title="Device identification">
<t>The authorization server may require to bind authentication
credentials to a device identifier. The IMEI is one example of
such an identifier, there are also operating system specific
identifiers. The authorization server could include such an
identifier when authenticating user credentials in order to detect
token theft from a particular device.</t>
</section>
<section anchor="clickjacking_xframe" title="X-FRAME-OPTION header">
<t>For newer browsers, avoidance of iFrames can be enforced server
side by using the X-FRAME-OPTION header. This header can have two
values, deny and same origin, which will block any framing or
framing by sites with a different origin, respectively.</t>
<t>This is a countermeasure against the following threats:</t>
<t><list style="symbols">
<t>Clickjacking attacks</t>
</list></t>
</section>
</section>
<section anchor="client_aa"
title="Client authentication and authorization">
<t>As described in Section 3 (Security Features), clients are
identified, authenticated and authorized for several purposes, such
as a</t>
<t><list style="symbols">
<t>Collate sub-sequent requests to the same client,</t>
<t>Indicate the trustworthiness of a particular client to the
end-user,</t>
<t>Authorize access of clients to certain features on the
authorization or resource server, and</t>
<t>Log a client identity to log files for analysis or
statics.</t>
</list>Due to the different capabilities and characteristics of
the different client types, there are different ways to support
achieve objectives, which will be described in this section.
Authorization server providers should be aware of the security
policy and deployment of a particular clients and adapt its
treatment accordingly. For example, one approach could be to treat
all clients as less trustworthy and unsecure. On the other extreme,
a service provider could activate every client installation by hand
of an administrator and that way gain confidence in the identity of
the software package and the security of the environment the client
is installed in. And there are several approaches in between.</t>
<section anchor="dont_issue"
title="Don't issue secrets to public clients or clients with inappropriate security policy">
<t>Authorization servers should not issue secrets to "public"
clients that cannot protect secrets. This prevents the server from
overestimating the value of a successful authentication of the
client.</t>
<t>For example, it is of limited benefit to create a single client
id and secret which is shared by all installations of a native
application. Such a scenario requires that this secret must be
transmitted from the developer via the respective distribution
channel, e.g. an application market, to all installations of the
application on end-user devices. A secret, burned into the source
code of the application or a associated resource bundle, cannot be
entirely protected from reverse engineering. Secondly, such
secrets cannot be revoked since this would immediately put all
installations out of work. Moreover, since the authorization
server cannot really trust on the client's identity, it would be
dangerous to indicate to end-users the trustworthiness of the
client.</t>
<t>There are other ways to achieve a reasonable security level, as
described in the following sections.</t>
</section>
<section anchor="forced_user_consent"
title="Public clients without secret require user consent">
<t>Authorization servers should not allow automatic authorization
for public clients. The authorization may issue a client id, but
should require that all authorizations are approved by the
end-user. This is a countermeasure for clients without secret
against the following threats:</t>
<t><list style="symbols">
<t>Impersonation of public client applications</t>
</list></t>
</section>
<section anchor="client_id_redirect"
title="Client_id only in combination with redirect_uri">
<t>The authorization may issue a client_id and bind the client_id
to a certain pre-configured redirect_uri. Any authorization
request with another redirection URI is refused automatically.
Alternatively, the authorization server should not accept any
dynamic redirection URI for such a client_id and instead always
redirect to the well-known pre-configured redirection URI. This is
a countermeasure for clients without secrets against the following
threats:</t>
<t><list style="symbols">
<t>Cross-site scripting attacks</t>
<t>Impersonation of public client applications</t>
</list></t>
</section>
<section anchor="depl_specific_secretes"
title="Deployment-specific client secrets">
<t>A authorization server may issue separate client identifiers
and corresponding secrets to the different deployments of a
client. The effect of such an approach would be to turn otherwise
"public" clients back into "confidential" clients.</t>
<t>For web applications, this could mean to create one client_id
and client_secret per web site a software package is installed on.
So the provider of that particular site could request client id
and secret from the authorization server during setup of the web
site. This would also allow to validate some of the properties of
that web site, such as redirection URI, address, and whatever
proofs useful. The web site provider has to ensure the security of
the client secret on the site.</t>
<t>For native applications, things are more complicated because
every installation of the application on any device is another
deployment. Deployment specific secrets will require</t>
<t><list style="numbers">
<t>Either to obtain a client_id and client_secret during
download process from the application market, or</t>
<t>During installation on the device.</t>
</list>Either approach will require an automated mechanism for
issuing client ids and secrets, which is currently not defined by
OAuth.</t>
<t>The first approach would allow to achieve a level where the
client is authenticated and identified, whereas the second option
only allows to authenticate the client but not to validate
properties of the client. But this would at least help to prevent
several replay attacks. Moreover, deployment-specific client_id
and secret allow to selectively revoke all refresh tokens of a
specific deployment at once.</t>
</section>
<section anchor="val_redirect"
title="Validation of pre-registered redirect_uri">
<t>An authorization server should require all clients to register
their redirect_uri and the redirect_uri should be the full URI as
defined in <xref target="I-D.ietf-oauth-v2"></xref>. The way this
registration is performed is out of scope of this document. As per
the core spec, every actual redirection URI sent with the
respective client_id to the end-user authorization endpoint must
match the registered redirection URI. Where it does not match, the
authorization server should assume the inbound GET request has
been sent by an attacker and refuse it. Note: the authorization
server should not redirect the user agent back to the redirection
URI of such an authorization request.</t>
<t><list style="symbols">
<t>Authorization code leakage through counterfeit web site:
allows to detect attack attempts already after first redirect
to end-user authorization endpoint (<xref
target="authz_code_leakage"></xref>).</t>
<t>For clients with validated properties, this measure also
helps to detect malicious applications early in the end-user
authorization process. This reduces the need for a interactive
validation by the user (<xref target="mal_client"></xref>,
<xref target="mal_client2"></xref>).</t>
<t>Open Redirector attack via client redirection endpoint. (
<xref target="open_redirector_client"></xref>. )</t>
<t>Open Redirector phishing attack via authorization server
redirection endpoint ( <xref target="open_redirector"></xref>
)</t>
</list> The underlying assumption of this measure is that an
attacker will need to use another redirection URI in order to get
access to the authorization code. Deployments might consider the
possibility of an attacker using spoofing attacks to a victims
device to circumvent this security measure.</t>
<t>Note: Pre-registering clients might not scale in some
deployments (manual process) or require dynamic client
registration (not specified yet). With the lack of dynamic client
registration, it only works for clients bound to certain
deployments at development/configuration time. As soon as dynamic
resource server discovery gets involved, that's no longer
feasible.</t>
</section>
<section anchor="client_secret_revocation"
title="Client secret revocation">
<t>An authorization server may revoke a client's secret in order
to prevent abuse of a revealed secret.</t>
<t>Note: This measure will immediately invalidate any
authorization code or refresh token issued to the respective
client. This might be unintentionally for client identifiers and
secrets used across multiple deployments of a particular native or
web application.</t>
<t>This a countermeasure against:</t>
<t><list style="symbols">
<t>Abuse of revealed client secrets for private clients</t>
</list></t>
</section>
<section anchor="strong_client_authn"
title="Use strong client authentication (e.g. client_assertion / client_token)">
<t>By using an alternative form of authentication such as client
assertion [draft-ietf-oauth-assertions], the need to distribute
client_secret is eliminated. This may require the use of a secure
private key store or other supplemental authentication system as
specified by the client assertion issuer in its authentication
process.</t>
</section>
</section>
<section title="End-user authorization">
<t>This secion involves considerations for authorization flows
involving the end-user.</t>
<section anchor="automatic_processing"
title="Automatic processing of repeated authorizations requires client validation">
<t>Authorization servers should NOT automatically process repeat
authorizations where the client is not authenticated through a
client secret or some other authentication mechanism such as
signing with security certificates (5.7.2.7. Use strong client
authentication (e.g. client_assertion / client_token)) or
validation of a pre-registered redirect URI (5.7.2.5. Validation
of pre-registered redirection URI ).</t>
</section>
<section anchor="informed_decisions"
title="Informed decisions based on transparency">
<t>The authorization server should clearly explain to the end-user
what happens in the authorization process and what the
consequences are. For example, the user should understand what
access he is about to grant to which client for what duration. It
should also be obvious to the user, whether the server is able to
reliably certify certain client properties (web site address,
security policy).</t>
</section>
<section anchor="validation_end_user"
title="Validation of client properties by end-user">
<t>In the authorization process, the user is typically asked to
approve a client's request for authorization. This is an important
security mechanism by itself because the end-user can be involved
in the validation of client properties, such as whether the client
name known to the authorization server fits the name of the web
site or the application the end-user is using. This measure is
especially helpful in all situation where the authorization server
is unable to authenticate the client. It is a countermeasure
against:</t>
<t><list style="symbols">
<t>Malicious application</t>
<t>A client application masquerading as another client</t>
</list></t>
</section>
<section anchor="bind_code_client_id"
title="Binding of authorization code to client_id">
<t>The authorization server should bind every authorization code
to the id of the respective client which initiated the end-user
authorization process. This measure is a countermeasure
against:</t>
<t><list style="symbols">
<t>replay of authorization codes with different client
credentials since an attacker cannot use another client_id to
exchange an authorization code into a token</t>
<t>Online guessing of authorization codes</t>
</list>Note: This binding should be protected from unauthorized
modifications.</t>
</section>
<section anchor="bind_code_redirect"
title="Binding of authorization code to redirect_uri">
<t>The authorization server should bind every authorization code
to the actual redirection URI used as redirect target of the
client in the end-user authorization process. This binding should
be validated when the client attempts to exchange the respective
authorization code for an access token. This measure is a
countermeasure against authorization code leakage through
counterfeit web sites since an attacker cannot use another
redirection URI to exchange an authorization code into a
token.</t>
</section>
</section>
</section>
<section title="Client App Security">
<t>This section deals with considerations for client applications.</t>
<section anchor="cred_software"
title="Don't store credentials in code or resources bundled with software packages">
<t>Because of the numbers of copies of client software, there is
limited benefit to create a single client id and secret which is
shared by all installations of an application. Such an application
by itself would be considered a "public" client as it cannot be
presumed to be able to keep client secrets. A secret, burned into
the source code of the application or a associated resource bundle,
cannot be entirely protected from reverse engineering. Secondly,
such secrets cannot be revoked since this would immediately put all
installations out of work. Moreover, since the authorization server
cannot really trust on the client's identity, it would be dangerous
to indicate to end-users the trustworthiness of the client.</t>
</section>
<section anchor="std_web"
title="Standard web server protection measures (for config files and databases)">
<t>Use standard web server protection measures - <xref
target="std_web"></xref></t>
</section>
<section anchor="secure_storage"
title="Store secrets in a secure storage">
<t>The are different way to store secrets of all kinds (tokens,
client secrets) securely on a device or server.</t>
<t>Most multi-user operation systems segregate the personal storage
of the different system users. Moreover, most modern smartphone
operating systems even support to store app-specific data in
separate areas of the file systems and protect it from access by
other applications. Additionally, applications can implements
confidential data itself using a user-supplied secret, such as PIN
or password.</t>
<t>Another option is to swap refresh token storage to a trusted
backend server. This mean in turn requires a resilient
authentication mechanisms between client and backend server. Note:
Applications should ensure that confidential data is kept
confidential even after reading from secure storage, which typically
means to keep this data in the local memory of the application.</t>
</section>
<section anchor="device_lock"
title="Utilize device lock to prevent unauthorized device access">
<t>On a typical modern phone, there are many "device lock" options
which can be utilized to provide additional protection where a
device is stolen or misplaced. These include PINs, passwords and
other biomtric featres such as "face recognition". These are not
equal in their level of security they provide.</t>
</section>
<section title="Platform security measures">
<t><list style="symbols">
<t>Validation process</t>
<t>software package signatures</t>
<t>Remote removal</t>
</list></t>
</section>
<section anchor="link_state_uasession"
title="Link state parameter to user agent session">
<t>The state parameter is used to link client requests and prevent
CSRF attacks, for example against the redirection URI. An attacker
could inject their own authorization code or access token, which can
result in the client using an access token associated with the
attacker's protected resources rather than the victim's (e.g. save
the victim's bank account information to a protected resource
controlled by the attacker).</t>
<t>The client should utilize the "state" request parameter to send
the authorization server a value that binds the request to the
user-agent's authenticated state (e.g. a hash of the session cookie
used to authenticate the user-agent) when making an authorization
request. Once authorization has been obtained from the end-user, the
authorization server redirects the end-user's user-agent back to the
client with the required binding value contained in the "state"
parameter.</t>
<t>The binding value enables the client to verify the validity of
the request by matching the binding value to the user- agent's
authenticated state.</t>
</section>
</section>
<section title="Resource Servers">
<t>The following section details security considerations for resource
servers.</t>
<section anchor="authz_header" title="Authorization headers">
<t>Authorization headers are recognized and specially treated by
HTTP proxies and servers. Thus the usage of such headers for sending
access tokens to resource servers reduces the likelihood of leakage
or unintended storage of authenticated requests in general and
especially Authorization headers.</t>
</section>
<section anchor="authn_requests" title="Authenticated requests">
<t>An authorization server may bind tokens to a certain client
identity and encourage resource servers to validate that binding.
This will require the resource server to authenticate the originator
of a request as the legitimate owner of a particular token. There
are a couple of options to implement this countermeasure:</t>
<t><list style="symbols">
<t>The authorization server may associate the distinguished name
of the client with the token (either internally or in the
payload of an self-contained token). The client then uses client
certificate-based HTTP authentication on the resource server's
endpoint to authenticate its identity and the resource server
validates the name with the name referenced by the token.</t>
<t>same as before, but the client uses his private key to sign
the request to the resource server (public key is either
contained in the token or sent along with the request)</t>
<t>Alternatively, the authorization server may issue a
token-bound secret, which the client uses to sign the request.
The resource server obtains the secret either directly from the
authorization server or it is contained in an encrypted section
of the token. That way the resource server does not "know" the
client but is able to validate whether the authorization server
issued the token to that client</t>
</list>This mechanisms is a countermeasure against abuse of tokens
by counterfeit resource servers.</t>
</section>
<section anchor="signed_requests" title="Signed requests">
<t>A resource server may decide to accept signed requests only,
either to replace transport level security measures or to complement
such measures. Every signed request should be uniquely identifiable
and should not be processed twice by the resource server. This
countermeasure helps to mitigate:</t>
<t><list style="symbols">
<t>modifications of the message and</t>
<t>replay attempts</t>
</list></t>
</section>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>We would like to thank Hui-Lan Lu, Francisco Corella, Peifung E Lam,
Shane B Weeden, Skylar Woodward, Niv Steingarten, Tim Bray, and James H.
Manger for their comments and contributions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.I-D.ietf-oauth-v2.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.lodderstedt-oauth-revocation.xml"?>
<?rfc include="reference.I-D.ietf-oauth-v2-bearer.xml"?>
<?rfc include="reference.I-D.ietf-oauth-v2-http-mac.xml"?>
<reference anchor="portable-contacts">
<front>
<title>Portable Contacts 1.0 Draft C</title>
<author fullname="Joseph Smarr" initials="J." surname="Smarr">
<organization></organization>
</author>
<date day="5" month="August" year="2008" />
</front>
</reference>
</references>
<section title="Document History">
<t>[[ to be removed by RFC editor before publication as an RFC ]]</t>
<t>draft-lodderstedt-oauth-security-01</t>
<t><list style="symbols">
<t>section 4.4.1.2 - changed "resource server" to "client" in
countermeasures description.</t>
<t>section 4.4.1.6 - changed "client shall authenticate the server"
to "The browser shall be utilized to authenticate the redirection
URI of the client"</t>
<t>section 5 - general review and alignment with public/confidential
client terms</t>
<t>all sections - general clean-up and typo corrections</t>
</list></t>
<t>draft-ietf-oauth-v2-threatmodel-00</t>
<t><list style="symbols">
<t>section 3.4 - added the purposes for using authorization
codes.</t>
<t>extended section 4.4.1.1</t>
<t>merged 4.4.1.5 into 4.4.1.2</t>
<t>corrected some typos</t>
<t>reformulated "session fixation", renamed respective sections into
"authorization code disclosure through counterfeit client"</t>
<t>added new section "User session impersonation"</t>
<t>worked out or reworked sections 2.3.3, 4.4.2.4, 4.4.4, 5.1.4.1.2,
5.1.4.1.4, 5.2.3.5</t>
<t>added new threat "DoS using manufactured authorization codes" as
proposed by Peifung E Lam</t>
<t>added XSRF and clickjacking (incl. state parameter
explanation)</t>
<t>changed sub-section order in section 4.4.1</t>
<t>incorporated feedback from Skylar Woodward (client secrets) and
Shane B Weeden (refresh tokens as client instance secret)</t>
<t>aligned client section with core draft's client type
definition</t>
<t>converted I-D into WG document</t>
</list></t>
<t>draft-ietf-oauth-v2-threatmodel-01</t>
<t><list style="symbols">
<t>Alignment of terminology with core draft 22 (private/public
client, redirect URI validation policy, replaced definition of the
client categories by reference to respective core section)</t>
<t>Synchronisation with the core's security consideration section
(UPDATE 10.12 CSRF, NEW 10.14/15)</t>
<t>Added Resource Owner Impersonation</t>
<t>Improved section 5</t>
<t>Renamed Refresh Token Replacement to Refresh Token Rotation</t>
</list></t>
<t>draft-ietf-oauth-v2-threatmodel-02</t>
<t><list style="symbols">
<t>Incoporated Tim Bray's review comments (e.g. removed all
normative language)</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 21:01:06 |