One document matched: draft-lodderstedt-oauth-security-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="2"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="yes"?>
<rfc category="std" docName="draft-lodderstedt-oauth-security-01"
ipr="trust200902">
<front>
<title abbrev="OAuth 2.0 Security">OAuth 2.0 Threat Model and Security
Considerations</title>
<author fullname="Dr.-Ing. 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="14" month="March" year="2011" />
<area>Applications Area</area>
<workgroup>Open Authentication Protocol</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" />. It contains the following content:<list
style="symbols">
<t>Documents any assumptions and scope considered when creating the
threat model</t>
<t>Describe the security features in-built into the OAuth protocol
and how they are intended to thwart attacks</t>
<t>Give 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 client
profile or all threats for protecting the resource server.</t>
</section>
<section title="Overview">
<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" />. 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" />, 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 are not bound to a specific deployment: An example
could by a mail client with support for contact list access via
the portable contacts API (see <xref
target="portable-contacts" />). Such clients cannot be registered
upfront with a particular deployment and must dynamically discover
the URLs relevant for the Oauth protocol.</t>
</list>
</t>
</section>
<section anchor="" 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 service provider and may eaves drop on any
communications between the two.</t>
<t>It is assumed an attacker has unlimited resources to mount an
attack.</t>
<t>It is assumed that 2 parties involved in the OAuth 3 legged
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 treat
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
an 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 MAY be 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 MAY be stored or accessible on the
authorization server:</t>
<t><list style="symbols">
<t>user data (out of scope)</t>
<t>HTTPS certificate/key</t>
<t>authz server credentials (handle-based design), or</t>
<t>authz 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>The following data elements are stored or accessible on the
authorization server:</t>
<t>
<list style="symbols">
<t>client id (and secret)</t>
<t>refresh tokens (persistent) access tokens (transient)</t>
<t>trusted CA certs (HTTPS)</t>
<t>per authorization process: redirect_uri, authorization
code</t>
</list>
</t>
<section title="Web Server">
<t>Such clients typically represent a web site with its own user
management and login mechanism and have the following
characteristics:</t>
<t><list style="symbols">
<t>Tokens are bound to a single user identity at the site</t>
<t>Web servers are able to protect client secrets</t>
<t>The potential number of tokens affected by a security
breach depends on number of site users.</t>
</list>Such clients are implemented using the authorization code
flow (see <xref target="code_flow" />).</t>
</section>
<section title="Native Applications">
<t>This class of OAuth clients represent apps running on a
user-controlled device, such as a notebook, PC, Tablet,
Smartphone, or Gaming Console.</t>
<t>Massively distributed applications such as these cannot
reliably keep secrets confidential, which are issued per software
package. This is because such secrets would need to be transferred
to the user device as part of the installation process. An
attacker could reverse engineer any secret from the binary or
accompanying resources. Native Applications are able to protect
per installation/instance secrets (e.g. refresh tokens) to some
extent.</t>
<t>Device platforms typically allow users to lock the device with
a pin and to segregate different apps or users (multi-user
operation systems).</t>
<t>Some devices can be identified/authenticated (to varying
degrees of assurance):</t>
<t><list style="symbols">
<t>Handsets and smart phones by its International Mobile
Equipment Identity (IMEI)</t>
<t>Set top boxes, gaming consoles, others by using
certificates and TPM module - Note: This does not help to
identify client apps but may be used to bound tokens to
devices and to detect token theft</t>
</list>Mobile devices, such as handsets or smart phones have the
following special characteristics:</t>
<t><list style="symbols">
<t>Limited input capabilities, therefore such clients
typically obtain a refresh token in order to provide automatic
login for sub-sequent application sessions</t>
<t>As mobile and small devices, they can get cloned, stolen or
lost easier than other devices.</t>
<t>Security breach will affect single user (or a few users)
only.</t>
</list>For the purposes of this document, the scenario of
attackers who control a smartphone device entirely is out of
scope.</t>
<t>There are several implementation options for native
applications:</t>
<t><list style="symbols">
<t>The authorization code flow in combination with an embedded
or external browser (<xref target="code_flow" />)</t>
<t>The implicte grant flow in combination with an embedded or
external browser (<xref target="implicite_flow" />)</t>
<t>The resource owner password credentials flow can be used as
well (<xref target="pwd_flow" />)</t>
</list>Different threats exists for those implementation
options, which are discussed in the respective sections of the
threat model.</t>
</section>
<section title="User Agent">
<t>[TBD]</t>
<t>Such client are implemented using the implicite grant flow
(<xref target="implicite_flow" />).</t>
</section>
<section title="Autonomous">
<t>Autonomous clients access service providers using rights grants
by client credentials only. Thus the autonomous client becomes the
„user“. Authenticating autonomous clients is
conceptually similar to end-user authentication since the issued
tokens refer to the client's identity. Autonomous clients shall
always be required to use a secret or some other form of
authentication (e.g. client assertion in the form of a SAML
assertion or STS token) acceptable to the authorization/token
services. The client must ensure the confidentiality of
client_secret or other credential.</t>
</section>
</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 of tokens. Tokens can be implemented in 2
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 typically require a communication between
resource server and token server in order to validate the token
and obtain token-bound data. Handles enable simple revocation and
do not require cryptographic mechanisms to protected token content
from being modified. As a disadvantage, they require additional
resource/token server communication impacting on performance and
scalability. An authorization code (OAuth Section 4.1.2) is an
example of a 'handle' token. An access token may also be
implemented as a handle token. 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. Implementing token revocation is more difficult with
assertions than with handles.</t>
</list>Tokens can be sent to resource server in two ways:</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 (cf. <xref
target="I-D.ietf-oauth-v2-bearer" /> . Because mere possession is
enough to use the token it is important that communication between
end-points be secured to ensure that only authorized end-points
may capture the token. The bearer token is convenient to client
applications as it does not require them to do anything to use
them (such as a proof of identity). Bearer tokens have similar
characteristics to web 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 (mutual
authentication) and HoK (holder-of-key) tokens (cf. <xref
target="I-D.hammer-oauth-v2-mac-token" />.</t>
</list>
</t>
</section>
<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 title="Authorization Code">
<t>An Authorization Code represents the intermediary 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 redirect_uri instead of tokens for two purposes.</t>
</section>
<section title="Redirect-URI">
<t>A Redirect-uri helps to identify clients and prevents phishing
attacks from other clients attempting to trick the user into believing
the phisher is the client. The redirect URI is pre-registered as
requests with authorization code or token will be directed to that
URI. Moreover, the value of the actual redirect_uri has to be
presented and is verified when an authorization code is exchanged for
tokens. This helps to prevent session fixation attacks.</t>
</section>
<section title="Access Token">
<t>An Access Token is used by a client to access a resource. An access
token must be acquired using a HTTP POST operation to ensure no
logging or caching of requests. 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.</t>
<t>The short lifespan of an access token enables the possibility of
revocation by requiring the client to refresh their access token at
regular intervals.</t>
</section>
<section title="Refresh Token">
<t>A Refresh Token is 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 must always be 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>
</section>
<section title="Client Authentication">
<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 security level in delegated
authorization scenarios and because the client will be able to act
without the user's presence. By authenticating a client when
requesting an access token, the token service is able to assess
whether a given client and authorization code meets appropriate
security requirements and binds the authorization code approved by the
user to the client making the request.</t>
<t>OAuth uses the <spanx style="emph">client_id</spanx> 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 tokens endpoint to exchange the
authorization code for tokens or</t>
<t>the initial authorization and issuance of a tokens by an
end-user to a particular client and sub-sequent requests by this
client to obtain tokens w/o 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 (e.g. in server log files)
between accesses by end-user, and delegated accesses by client on
behalf of a user.</t>
<t>The <spanx style="emph">client_secret</spanx> is used to verify the
client identifier. This should only be used where the client is
capable of keeping its secret confidential. The client identity can
also be verified using the <spanx style="emph">redirect_uri</spanx> or
by the <spanx style="emph">end-user</spanx>.</t>
<t>Clients (and the trustworthiness of its identity) can be classifed
by using the following parameters:</t>
<t><list style="symbols">
<t>Deployment-specific or -independent client_id (Note: for native
apps, every installation of a particular app on a certain device
is considered a deployment.)</t>
<t>Validated properties, such as app name or redirect_uri</t>
<t>Client_secret available</t>
</list>Typical client categories are:</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 apps
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_secre">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 (cf. <xref target="ObtainClientSecrets" />). Due to
its security weaknesses, such client identities have the same
trustlevel 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 insures the validation of the client's
properties, such as redirect_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 app is
conducted by an administrator, who validates the clients
authenticity, or the process from validating the app to the
installation of the app on the device and the creation of the
client credentials is controlled end-to-end by a single entity
(e.g. app 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). 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 apps. Revocation
will affect a single deployment only.</t>
</list>Use of the client secret is considered a relatively weak form
of credential for the client. Use of stronger mechanisms such as a
client assertion (e.g. SAML), key cryptography, are preferred.</t>
</section>
</section>
<section title="Security Threat Model">
<t>This sections gives a comprehensive threat model of OAuth 2.0.
Threats are grouped first by attackes 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" />.</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 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, there are the following
approaches an attacker could utilize to obtain the client
secret.</t>
<t><spanx style="strong">Attack: Obtain Secret From Source Code or
Binary.</spanx> This applies for all client profiles and especially
for open source projects, where the source code is public
accessible. Even if the attacker does not has access to the source
code, it could reverse engineer secrets from the binary of native
apps.</t>
<t>
<spanx>Countermeasures:</spanx>
</t>
<t>
<list style="symbols">
<t>Don't issue secrets to clients with inappropriate security
policy - <xref target="dont_issue" /></t>
<t>Client_id only in combination with forced user consent -
<xref target="forced_user_consent" /></t>
<t>Deployment-specific client secrets - <xref
target="depl_specific_secretes" /></t>
<t>Client secret revocation - <xref
target="client_secret_revocation" /></t>
</list>
<spanx xml:space="default" />
</t>
<t><spanx style="strong" xml:space="default">Attack: Obtain a
Deployment-Specific Secret.</spanx> An attacker may try to obtain
the secret from a client installation, either from a web site (web
server) or a particular devices (native app).</t>
<t>
<spanx>Countermeasures:</spanx>
</t>
<t>
<list style="symbols">
<t>Web server: apply standard web server protection measures
(for config files and databases) - <xref target="std_web" /></t>
<t>Native apps: Store secrets in a secure local storage - <xref
target="secure_storage" /></t>
<t>Client secret revocation - <xref
target="client_secret_revocation" /></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. Some generally applicable countermeasure to
mitigate such attacks shall be given in advance:</t>
<t>
<list style="symbols">
<t>The authorization server must validate the client id
associated with the particular refresh token with every refresh
request - <xref target="binding_refresh_client_id" /></t>
<t>Limited scope tokens - <xref target="limit_scope" /></t>
<t>Refresh token revocation - <xref
target="refresh_revocation" /></t>
<t>Client secret revocation - <xref
target="client_secret_revocation" /></t>
<t>Refresh tokens can automatically be replaced in order to
detect unauthorized token usage by another party (Refresh Token
Replacement) - <xref target="refresh_replace" /></t>
</list>
<spanx style="strong" />
</t>
<t><spanx style="strong">Attack: Obtain Refresh Token from Web
application.</spanx> An attack may obtain the refresh tokens issued
to a web server client. Impact: Exposure of all refresh tokens on
that side.</t>
<t>
<spanx style="emph">Countermeasures:</spanx>
<list style="symbols">
<t>Standard web server protection measures - <xref
target="std_web" /></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" /></t>
</list>
<spanx style="strong" />
</t>
<t><spanx style="strong">Attack: Obtain Refresh Token from Native
clients.</spanx> On native clients, leakage of a refresh token
typically affects a single user, only.</t>
<t><spanx style="emph">Read from local filesystem:</spanx> The
attacker could try get file system access on the device and read the
refresh tokens. The attacker could utilize a malicious app for that
purpose.</t>
<t>
<spanx style="emph">Countermeasures:</spanx>
</t>
<t>
<list style="symbols">
<t>Store secrets in a secure storage - <xref
target="secure_storage" /></t>
<t>Utilize device lock to prevent unauthorized device access -
<xref target="device_lock" /></t>
</list>
<spanx style="emph" />
</t>
<t><spanx style="emph">Steal device</spanx>: The host device (e.g.
mobile phone) may be stolen. In that case, the attacker gets access
to all apps under the identity of the legitimate user.</t>
<t>
<spanx style="emph">Countermeasures:</spanx>
</t>
<t>
<list style="symbols">
<t>Utilize device lock to prevent unauthorized device access -
<xref format="default" target="device_lock" /></t>
<t>Where a user knows the device has been cloned, they can use
this countermeasure (Refresh Token Revocation) - <xref
target="refresh_revocation" /></t>
</list>
<spanx style="emph" />
</t>
<t><spanx style="emph">Clone device: </spanx>All device data and
applications are copied to another device. Applications are used
as-is on the target device.</t>
<t>
<spanx style="emph">Countermeasures:</spanx>
</t>
<t>
<list style="symbols">
<t>Combine refresh token request with device identification -
<xref target="device_id" /></t>
<t>Combine refresh token requests with user-provided secret -
<xref target="user_secret" /></t>
<t>Refresh Token Replacement - <xref
target="refresh_replace" /></t>
<t>Where a user knows the device has been cloned, they can use
this countermeasure - Refresh Token Revocation - <xref
target="refresh_revocation" /></t>
</list>
<spanx style="emph" />
</t>
<t><spanx style="emph">Obtain refresh tokens from backup:</spanx> A
refresh token could be obtained from the backup of a client
application, or device.</t>
<t>
<spanx style="emph">Countermeasures:</spanx>
</t>
<t>
<list style="symbols">
<t>tbd</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 app 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.</t>
<t>Countermeasures:</t>
<t>
<list style="symbols">
<t>Keep access tokens in transient memory and limit grants:
<xref target="access_tokens" /></t>
<t>Limited scope tokens - <xref target="limit_scope" /></t>
<t>Combine refresh token requests with user-provided secret -
<xref target="user_secret" /></t>
<t>Client secret revocation - <xref
target="client_secret_revocation" /></t>
<t>Keep access tokens in private memory or apply same protection
means as for refresh tokens - <xref
target="refresh_tokens" /></t>
<t>Keep access token lifetime short - <xref
target="short_exp_time" /></t>
</list>
</t>
</section>
<section title="Threat: End-user credentials phished using compromised or embedded browser">
<t>A malicious app 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 UI. 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 app UI, the client app has access to additional information
it should not have access to (e.g. uid/password).</t>
<t>Impact: If the client app 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>Client developers and end-user can be educated to trust an
external System-Browser only.</t>
<t>Client apps could be validated prior publication in a app
market.</t>
<t>Client developers should not collect authentication
information directly from users and should instead use redirects
to and back from a trusted external system-browser.</t>
</list>
</t>
</section>
</section>
<section title="Authorization Endpoint">
<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>Service providers should consider such attacks when
developing services based on OAuth, and should require
transport-layer security for any requests where the authenticity
of the Service Provider or of request responses is an issue (see
<xref target="server_authn" />).</t>
<t>Service Providers 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 authenticaton, 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" /></t>
<t>Narrow scope based on client-specific policy - When obtaining
end user authorization and where the client requests scope, the
service provider may want to consider whether to honour that
scope based on who the client is. That decision is between the
client and service provider and is outside the scope of this
spec. The service provider may also want to consider what scope
to grant based on the profile used, e.g. providing lower scope
where no client secret is provided from a native application. -
<xref target="limit_scope" /></t>
</list>
</t>
</section>
<section 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 Provider.</t>
<t>A malicious client may exploit that feature and try to obtain
such an authorization code instead of the legimate client.</t>
<t>Countermeasures:</t>
<t>
<list style="symbols">
<t>Service providers 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 certs (see <xref
target="strong_client_authn" />) or validation of a
pre-registered redirect uri (<xref target="val_redirect" />
)</t>
<t>Service Providers can mitigate the risks associated with
automatic processing by limiting the scope of Access Tokens
obtained through automated approvals - <xref
target="limit_scope" /></t>
</list>
</t>
</section>
<section title="Threat: Open redirector">
<t>An attacker could use the end-user authorization endpoint and the
redirect_uri parameter to abuse the authorization server as
redirector.</t>
<t>Impact?</t>
<t>Countermeasure</t>
<t>
<list style="symbols">
<t>don't redirect to redirect_uri, if client identity or
redirect_uri could not be verified</t>
</list>
</t>
</section>
</section>
<section title="Token endpoint">
<t />
<section title="Threat: Eavesdropping access tokens">
<t>The OAuth specification does not describe any mechanism for
protecting Tokens from eavesdroppers when they are transmitted from
the Service Provider to the Client.</t>
<t>Countermeasures:</t>
<t>
<list style="symbols">
<t>Service Providers MUST ensure that these transmissions are
protected using transport-layer mechanisms such as TLS or SSL
(see <xref target="conf_requests" />).</t>
<t>If end-to-end confidentiality cannot be guaranteed, reducing
scope (see <xref target="limit_scope" />) and expiry time (<xref
target="short_exp_time" />) 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" /></t>
<t>Store access token hashes only - <xref
target="noclear" /></t>
<t>Standard SQL inj. Countermeasures - <xref
target="std_sql" /></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 immitation of a client service.</t>
<t>Countermeasures:</t>
<t>
<list style="symbols">
<t>Implement transport security through <xref format="title"
target="conf_requests" /></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" />.</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" /></t>
<t>Lock accounts - <xref target="lock_accounts" /></t>
</list>
</t>
</section>
<section title="DoS on dynamic client secret creation">
<t>If a Service Provider includes a nontrivial amount of entropy in
client secrets and if the service provider automatically grants
them, an attacker could exhaust the pool by repeatedly applying for
them.</t>
<t>Countermeasures:</t>
<t>
<list style="symbols">
<t>The service provider should consider some verification step
for new clients. The service provider 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>
<t />
<section anchor="code_flow" title="Authorization Code">
<t />
<section title="Threat: Malicious client obtains authorization">
<t>Attacker abuses valid client id</t>
<t>countermeasures</t>
<t>
<list style="symbols">
<t>client validation</t>
<t>client authentication</t>
<t>user consent</t>
</list>
</t>
</section>
<section title="Threat: Eavesdropping authorization codes">
<t>The OAuth specification does not describe any mechanism for
protecting authorization codes from eavesdroppers when they are
transmitted from the Service Provider to the Client and where the
Service Provider Grants an Access Token.</t>
<t>Note: A description of a similar attack 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).</t>
<t>Countermeasures:</t>
<t>
<list style="symbols">
<t>The authorization server SHOULD enforce a one time usage
restriction (see <xref target="one_time_usage" />).</t>
<t>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" />).</t>
<t>The authorization server shall 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" />).</t>
<t>Limited duration of authorization codes - <xref
target="short_exp_time" /></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" />).</t>
<t>In the absence of these countermeasures, reducing scope
(<xref target="limit_scope" />) and expiry time (<xref
target="short_exp_time" />) for access tokens can be used to
reduce the damage in case of leaks.</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>Credential storage protection can be employed - <xref
target="cred_storage_prot" /></t>
<t>System security measures - <xref target="std_sys" /></t>
<t>Store access token hashes only - <xref
target="noclear" /></t>
<t>Standard SQL inj. Countermeasures - <xref
target="std_sql" /></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. Impact: disclosure of single access
token (+probably refresh token)</t>
<t>Countermeasures:</t>
<t>
<list style="symbols">
<t>For handle-based designs: <xref
target="random_entropy" /></t>
<t>For assertion-based designs: <xref
target="signed_tokens" /></t>
<t>Binding of authorization code to client_id, adds another
value the attacker has to guess - <xref
target="bind_code_client_id" /></t>
<t>Binding of authorization code to redirect_uri, adds another
value the attacker has to guess - <xref
target="bind_code_redirect" /></t>
<t>Short expiration time - <xref
target="short_exp_time" /></t>
</list>
</t>
</section>
<section title="Threat: Authorization code leaks when requesting access token">
<t>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>Referer headers: browsers frequently pass a
“referer” header when a web page embeds content,
or when a user travels from one web page to another web page.
These referer headers may be sent even when the origin site
does not trust the destination site. The referer 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>Similar attacks on the SAML protocol are discussed in:
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>The authorization server shall 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" />).</t>
<t>Authorization codes must be time-limited (see <xref
target="short_exp_time" />)</t>
<t>Authorization codes should be single-use tokens (<xref
target="one_time_usage" />)</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" />)</t>
<t>The resource server may reload the target page of the
redirect_uri in order to automatically cleanup the browser
cache.</t>
</list>
</t>
</section>
<section title="Threat: Authorization code phishing">
<t>A hostile party could act as the client web server and get
access to the authorization code. This could be achieved using DNS
or ARP spoofing. </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>
<list style="symbols">
<t>The browser shall be utilized to authenticate the
redirect_uri of the client using server authentication - <xref
target="server_authn" /></t>
<t>The authorization server shall require the client to
authenticate with a secret, 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" />).</t>
</list>
</t>
</section>
<section title="Threat: Session fixation">
<t>The session fixation attack leverages the 3-legged OAuth flow
in an attempt to get another user to log-in and authorize access
on behalf of the attacker. 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>In this attack, the attacker is using a known client
application (consumer site), and a target OAuth resource provider.
The attack depends on the victim expecting the consumer site to
request access to the resource provider.</t>
<t>The attacker utilizes the following flow:</t>
<t>The attacker initiates browser access to the consumer site, and
initates access to data from the resource provider. The consumer
site, initiates an authorization request and receives a
redirect_uri back from the resource provider's authorization
server. Instead of following the link, the attacker stops the
process and saves the redirect_uri. The attacker modifies the
redirect_uri to allow control to be returned to the attacker
site.</t>
<t>The attacker tricks another user (the victim) to open that
redirect_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 consumer site to have access.</t>
<t>The authorization server redirects the user agent to the
attackers web site instead of the original target web site.</t>
<t>The attacker obtains the authorization code from its web site,
constructs a redirect_uri to the target web site (or app) based on
the original authorization request's redirect_uri and the newly
obtained authorization code and directs its user agent to this
URL.</t>
<t>The web 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>Countermeasures:</t>
<t>
<list style="symbols">
<t>The attacker must use another redirect_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 redirect_uri of a
particular end-user authorization, such a change (and with
that such an attack) can be detected - see <xref
target="bind_code_client_id" /></t>
<t>The authorization server may also enforce the usage and
validation of pre-registered redirect Uris (see <xref
target="val_redirect" />).</t>
<t>For native apps, one could also consider to use
deployment-specific client ids and secrets (see <xref
target="depl_specific_secretes" />, along with the binding of
authorization code to client_id (see <xref
target="bind_code_client_id" />), to detect a session fixation
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 to use other flows, which are not
vulnerable to session fixation attacks (see <xref
target="implicite_flow" /> or <xref target="pwd_flow" />).</t>
</list>
</t>
</section>
<section title="Threat: DoS, Exhaustion of resources attacks">
<t>If a Service Provider 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 service provider should consider limiting the number of
access tokens granted per user. The service provider should
include a nontrivial amount of entropy in authorization
codes.</t>
</list>
</t>
</section>
</section>
<section anchor="implicite_flow" title="Implicit Grant">
<t />
<section title="Threat: Access token leak in transport/end-points">
<t>Description: the access token is directly returned to the
client as part of the redirect URL. This token might be
eavesdropped by an attacker. The token is sent from server to
client via a URI fragment of the redirect_uri. If the
communication is not secured or the end-point is not secured, the
token could be leaked by parsing the returned URI. Impact: the
attacker would be able to assume the same rights granted by the
token.</t>
<t>Countermeasures:</t>
<t>
<list style="symbols">
<t>Confidentiality of Requests - <xref
target="conf_requests" /></t>
<t>Bind token to client id - <xref
target="bind_token_client_id" /></t>
</list>
</t>
</section>
<section title="Threat: Access token leak in browser history">
<t>An attacker could obtain the token from the browsers
history.</t>
<t>Countermeasures:</t>
<t>
<list style="symbols">
<t>Shorten token duration (see <xref
target="short_exp_time" />) and reduced scope of the token may
reduce the impact of that attack (see <xref
target="limit_scope" />).</t>
<t>Make these requests non-cachable</t>
<t>Native apps can directly embedd a browser widget and
therewith gain full control of the cache. So the app can
cleanup browser history after authorization process.</t>
</list>
</t>
</section>
<section title="Threat: Malicious client obtains authorization">
<t>An malicious client could attempt to obtain a token by fraud.
Client secrets are not an effective countermeasure in this
case.</t>
<t>The following countermeasures are advisable:</t>
<t>
<list style="symbols">
<t>Always require user consent and let end-user validate
client identity - <xref target="validation_end_user" /></t>
<t>No automatic processing of repeated authorizations - <xref
target="automatic_processing" /></t>
</list>
</t>
</section>
</section>
<section anchor="pwd_flow" title="Resource Owner Password Credentials">
<t>The “password” grant type (see OAuth Core 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. The “password” 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 must validate the client id
associated with the particular refresh token with every refresh
request - <xref target="binding_refresh_client_id" /></t>
<t>Service Providers MUST ensure that these transmissions are
protected using transport-layer mechanisms such as TLS or SSL
(see <xref target="conf_requests" />).</t>
</list>
</t>
<section title="Threat: Accidental exposure of passwords at client site">
<t>If an authorization server does not provide enough protection,
an attacker or disgruntled employee could retrieve the passwords
for a client</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" />) 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 permission for
client using this flow shall be.</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" />).</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" />). If the particular client is
trustworthy and can be authenticated in a reliable way (cf.
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" />).</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" /></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 service providers domain 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" /></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" /></t>
<t>Lock accounts - <xref target="lock_accounts" /></t>
<t>Tar pit - <xref target="tar_pit" /></t>
<t>CAPTCHA - <xref target="captchas" /></t>
<t>Abandon on grant type „password“</t>
<t>Client authentication (see <xref target="client_aa" />)
will provide another authentication factor and thus hinder the
attack.</t>
</list>
</t>
</section>
</section>
<section title="Client Credentials">
<t>[TBD]</t>
</section>
</section>
<section title="Refreshing an Access Token">
<t />
<section title="Threat: Eavesdropping refresh tokens from authorization server">
<t>The OAuth specification does not describe any mechanism for
protecting Tokens from eavesdroppers when they are transmitted from
the Service Provider to the Client.</t>
<t>Countermeasures:</t>
<t>
<list style="symbols">
<t>Service Providers MUST ensure that these transmissions are
protected using transport-layer mechanisms such as TLS or SSL
(see <xref target="conf_requests" />).</t>
<t>If end-to-end confidentiality cannot be guaranteed, reducing
scope (see <xref target="limit_scope" />) and expiry time (see
<xref target="short_exp_time" />) 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" /></t>
<t>Bind token to client id, if the attacker cannot obtain the
required id and secret - <xref
target="bind_token_client_id" /></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" /></t>
<t>For assertion-based designs - <xref
target="signed_tokens" /></t>
<t>Bind token to client id, because the attacker would guess the
matching client id, too - <xref
target="bind_token_client_id" /></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 suceed.</t>
<t>Countermeasures:</t>
<t>
<list style="symbols">
<t>Server authentication (as described in <xref
target="server_authn" />)</t>
</list>
</t>
</section>
</section>
<section title="Accessing Protected Resources">
<t />
<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 MUST by
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. Instead transport protection
means shall be utilized to prevent eavesdropping by an attacker
(see <xref target="conf_requests" />).</t>
<t>A short lifetime reduces impact in case tokens are
compromised (see <xref target="short_exp_time" />).</t>
<t>The access token can be bound to a client's identity and
require the client to authenticate with the resource server (see
<xref target="authn_requests" />). Client authentication MUST be
performed without exposing the required secret to the transport
channel.</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" />). This would prevent the attacker from
capturing valid requests.</t>
<t>Alternatively, the resource server could employ signed
requests (see <xref target="signed_requests" />) along with
nounces and timestamps in order to uniquely identify requests.
The resource server MUST 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" />) in order to make guessing a valid
token value difficult.</t>
<t>Assertion (or self-contained token ) tokens contents SHALL be
protected by a digital signature (see <xref
target="signed_tokens" />).</t>
<t>Security can be further strengthened by using a short access
token duration (see <xref target="exp_time" /> and <xref
target="short_exp_time" />).</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" />).</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" />).</t>
<t>Restrict the token scope (see <xref target="limit_scope" />)
and or limit the token to a certain resource server (<xref
target="bind_token_rs" />).</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. Similarily, 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" />).</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>Service Providers not using the HTTP Authorization scheme
(OAuth HTTP Authorization Scheme - see <xref
target="authz_header" />) should take care to use other
mechanisms, such as the Cache-Control header, to ensure that
authenticated content is protected.</t>
<t>Reducing scope (see <xref target="limit_scope" />) and expiry
time (<xref target="short_exp_time" />) 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" />).</t>
<t>Set logging configuration appropriately</t>
<t>Prevent unauthorized persons from access to system log files
(see <xref target="std_sys" />)</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" />).</t>
<t>The impact of token leakage may be reduced by limiting scope
(see <xref target="limit_scope" />) and duration (see <xref
target="short_exp_time" />) and enforcing one time token usage
(see <xref target="one_time_usage" />).</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>
<t />
<section title="General">
<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 attacks through using content of request, e.g.
secrets or tokens, or mount replay attacks.</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 MUST validate the binding of the server to its domain
name. If the server fails to prove that binding, it is condered a
men-in-the-middle. 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 conterfeit 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 shall 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 apps or portals</t>
</list>
</t>
</section>
<section title="Credentials">
<t>This sections describes countermeasures used to protect all kind
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 />
<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>
<t />
</section>
<section anchor="std_sql"
title="Standard SQL inj. Countermeasures">
<t>[TBD]</t>
</section>
<section anchor="noclear"
title="No cleartext storage of credentials">
<t>The authorization server may consider to 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>[TBD]</t>
</section>
<section title="Use of asymmetric cryptography">
<t>Usage of asymmetric cryptography will free the authorization
server of the obligation to manage credentials. Nevertheless, it
MUST ensure the integrity of the respective public keys.</t>
</section>
</section>
<section anchor="online_secrets" title="Online attacks on secrets">
<t />
<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 MUST include a
reasonable level of entropy in order to mitigate the risk of
guessing attacks.</t>
<t>The token value MUST 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 MUST 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 attackes 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 programms from automatically checkinga
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)">
<t />
<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 unauthenticated 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
gran 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 likelyhood of sucessful 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 request,
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 likelyhood of sucessful online guessing</t>
</list>Additionally, 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.</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 to issue tokens with different content to different
resource servers and to explicitely indicate in the token the
target server a token is intended to be sent to (cf. Audience in
SAML Assertions). This countermeasure can be used in the following
situations:</t>
<t>
<list style="symbols">
<t>It reduce 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 reduce the impact of a leakage of a valid token to a
conterfeit 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 to use only tokens with explicitely
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 match must 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 shall 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 MUST
include a reasonable level of entropy in order to mitigate the
risk of guessing attacks. The token value MUST 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 MUST be less
than or equal to 2^(-128) and SHOULD be less than or equal to
2^(-160).</t>
</section>
</section>
<section anchor="access_tokens" title="Access tokens">
<t>
<list style="symbols">
<t>keep them in transient memory (accessible by the client app
only)</t>
<t>exposure to 3rd parties (malicious app)</t>
<t>limit number of access tokens granted to a user</t>
</list>
</t>
</section>
</section>
<section title="Authorization Server">
<t />
<section title="Authorization Codes">
<t />
<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
a authorization code, the Authorization Server may want to revoke
all tokens granted based on the authorization code.</t>
</section>
</section>
<section anchor="refresh_tokens" title="Refresh tokens">
<t />
<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 areo 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 MUST 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.
This measure is a countermeasure against refresh token theft or
leakage.</t>
<t>Note: This binding MUST be protected from unauthorized
modifications.</t>
</section>
<section anchor="refresh_replace" title="Refresh Token Replacement">
<t>Refresh token replacement 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
explicitely request the invalidation of refresh tokens.</t>
<t>This is a countermeasure againts:</t>
<t>
<list style="symbols">
<t>device theft</t>
<t>...</t>
</list>
</t>
</section>
<section anchor="user_secret"
title="Combine refresh token requests with user-provided secret">
<t>The exchange of a refresh token can be bound to the presence of
a certain user-provided secret, such as a PIN, a password or a SIM
card. This is a kind of multi-factor authentication on the tokens
endpoint, since an attacker must possess both factors in order to
be able to obtain an access token.</t>
</section>
<section anchor="device_id" title="Device identification">
<t>The authorization server may require to bind authentication
credentials to a device identifier or token assigned to that
device. As the IMEI can be spoofed, that is not suitable, For
mobile phones, a registration process can be used to assign a
unique token to the device using an sms message. That token or
identifer can then be validated with when authenticating user
credentials.</t>
<t>This is a countermeasure against the following threats:</t>
<t>
<list style="symbols">
<t>phishing attacks</t>
<t>...</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 capababilities and characterictics of
the different client types, there are different ways to support
achieve objectives, which will be described in this section.
Generally spoken, 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
extrem, 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 clients with inappropriate security policy">
<t>Authorization servers should not issue secrets to clients, if
these cannot sufficiently protect it. This prevents the server
from overestimating the value of a sucessful 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
app. First of all, this secret must be somehow transmitted from
the developer via the respective distribution channel, e.g. an app
market, to all installations of the app on end-user devices. So
the secret is typically burned into the source code of the app or
a associated resource bundle, which cannot be entirely protected
from reverse engineering. Second, effectively such secrets cannot
be revoked since this would immediatly 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="Client_id only in combination with forced user consent">
<t>The authorization may issue a client id, but only accept
authorization request, which are approved by the end-user. This
measure precludes automatic authorization processes. This is a
countermeasure for clients without secret against the following
threats:</t>
<t>
<list style="symbols">
<t>...</t>
<t>...</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, but bind this
client_id to a certain pre-configured redirect_uri. So any
authorization request with another redirect_uri is refused
automatically. Alternatively, the authorization server may not
accept any dynamic redirect_uri for such a client_id and instead
always redirect to the well-known pre-configured redirect_uri.
This is a countermeasure for clients of LOA 2 against the
following threats:</t>
<t>
<list style="symbols">
<t>...</t>
<t>...</t>
</list>
</t>
</section>
<section anchor="depl_specific_secretes"
title="Deployment-specific client secrets">
<t>A authorization server may issue separate client ids and
corresponding secrets to the different deployments of a
client.</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 redirect_uri, address, and whatever proofs
useful. The web site provider has to ensure the security of the
client secret on the site. As a result, such client could reach
LOA 7.</t>
<t>For native applications, things are more complicated because
every installation of the app 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 app 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 LOA 7, whereas the
second option does not allow to validate properties of the client
thus can achieve at most LOA 6. 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. This is a countermeasure
against the following threats:</t>
<t>
<list style="symbols">
<t>...</t>
<t>...</t>
</list>
</t>
</section>
<section anchor="val_redirect"
title="Validation of pre-registered redirect_uri">
<t>An authorization server may require clients to register their
redirect_uri or a pattern (TBD: make definition more precise)
thereof. The way this registration is performed is out of scope of
this document. Every actual redirect_uri sent with the respective
client_id to the end-user authorization endpoint must comply with
that pattern. Otherwise the authorization server must assume the
inbound GET request has been sent by an attacker and refuse
it.</t>
<t>Note: the authorization server MUST NOT redirect the user agent
back to the redirect_uri of the authorization request.</t>
<t><list style="symbols">
<t>Session fixation: allows to detect session fixation
attempts already after first redirect to end-user
authorization endpoint</t>
<t>For clients of LOA 2/5/7, this measure also helps to detect
malicious apps early in the end-user authorization process.
This reduces the need for a interactive validation by the
user.</t>
</list>The underlying assumption of this measure is that an
attacker must use another redirect_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. This is a countermeasure against
the following threats:</t>
<t><list style="symbols">
<t>session fixation</t>
<t>malicious apps (for deployment-specific clients with
secret)</t>
</list>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
feasable.</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>...</t>
<t>...</t>
</list>
</t>
</section>
<section anchor="strong_client_authn"
title="Use strong client authentication (e.g. client_assertion / client_token)">
<t>Assumption: prevents an attacker from obtaining a client secret
because this secret is kept in some hardware security module?</t>
</section>
</section>
<section title="End-user authorization">
<t />
<section anchor="automatic_processing"
title="Automatic processing of repeated authorizations requires client validation">
<t>Service providers 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 certs (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 redirect_uri ).</t>
</section>
<section anchor="informed_decisions"
title="Informed decisions based on transparency">
<t>The authorization server shall intelligible explain to the
end-user what happens in the authorization process and what the
consequences are. For example, the user shall understand what
access he is about to grant to which client for what duration. It
shall 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-users can be involed
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 app 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 app</t>
<t>...</t>
</list>
</t>
</section>
<section anchor="bind_code_client_id"
title="Binding of authorization code to client_id">
<t>The authorization server MUST 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>Session fixation 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 MUST be protected from unauthorized
modifications.</t>
</section>
<section anchor="bind_code_redirect"
title="Binding of authorization code to redirect_uri">
<t>The authorization server MAY bind every authorization code to
the redirect_uri used as redirect target of the client in the
end-user authorization process. This binding MUST be validated
when the client attempts to exchange the respective authorization
code for an access token. This measure is a countermeasure against
session fixation since an attacker cannot use another redirect_uri
to exchange an authorization code into a token.</t>
<t />
</section>
</section>
</section>
<section title="Client App Security">
<t />
<section anchor="cred_software"
title="Don't store credentials in code or resources bundled with software packages">
<t>[Anything more to say ? :-)]</t>
</section>
<section anchor="std_web"
title="Standard web server protection measures (for config files and databases)">
<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 seggregate the personal storage
of the different system users. Moreover, most modern smartphone
operating systems even support to store app-specific data in separat
areas of the file systems and protect it from access by other apps.
Additionally, apps 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 must ensure that confidential data are kept
confidential even after readin from secure storage, which typically
means to keep this data in the local memory of the app.</t>
</section>
<section anchor="device_lock"
title="Utilize device lock to prevent unauthorized device access">
<t />
</section>
<section title="Platform security measures">
<t>
<list style="symbols">
<t>Validation process</t>
<t>software package signatures</t>
<t>Remote removal</t>
<t />
</list>
</t>
</section>
</section>
<section title="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
identitiy 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 must be uniquly identifiable and
must 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 Francisco Corella for his feedback.</t>
</section>
<appendix title="Document History">
<t>[[ to be removed by RFC editor before publication as an RFC ]]</t>
<t>-1</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 redirect_uri
of the client"</t>
</list>
</t>
</appendix>
</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.hammer-oauth-v2-mac-token.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>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:27:26 |