RFC 6819
OAuth 2.0 Threat Model and Security Considerations
4. Threat Model
This section gives a comprehensive threat model of OAuth 2.0. Threats are grouped first by attacks directed against an OAuth component, which are the client, authorization server, and resource server. Subsequently, they are grouped by flow, e.g., obtain token or access protected resources. Every countermeasure description refers to a detailed description in Section 5.
4.1. Clients
This section describes possible threats directed to OAuth clients.4.1.1. Threat: Obtaining Client Secrets
The attacker could try to get access to the secret of a particular client in order to: o replay its refresh tokens and authorization "codes", or o obtain tokens on behalf of the attacked client with the privileges of that "client_id" acting as an instance of the client. The resulting impact would be the following: o Client authentication of access to the authorization server can be bypassed. o Stolen refresh tokens or authorization "codes" can be replayed. Depending on the client category, the following attacks could be utilized to obtain the client secret. Attack: Obtain Secret From Source Code or Binary: This applies for all client types. For open source projects, secrets can be extracted directly from source code in their public repositories. Secrets can be extracted from application binaries just as easily when the published source is not available to the attacker. Even if an application takes significant measures to obfuscate secrets in their application distribution, one should consider that the secret can still be reverse-engineered by anyone with access to a complete functioning application bundle or binary. Countermeasures: o Don't issue secrets to public clients or clients with inappropriate security policy (Section 5.2.3.1). o Require user consent for public clients (Section 5.2.3.2). o Use deployment-specific client secrets (Section 5.2.3.4). o Revoke client secrets (Section 5.2.3.6).
Attack: Obtain a Deployment-Specific Secret:
An attacker may try to obtain the secret from a client installation,
either from a web site (web server) or a particular device (native
application).
Countermeasures:
o Web server: Apply standard web server protection measures (for
config files and databases) (see Section 5.3.2).
o Native applications: Store secrets in secure local storage
(Section 5.3.3).
o Revoke client secrets (Section 5.2.3.6).
4.1.2. Threat: Obtaining Refresh Tokens
Depending on the client type, there are different ways that refresh
tokens may be revealed to an attacker. The following sub-sections
give a more detailed description of the different attacks with
respect to different client types and further specialized
countermeasures. Before detailing those threats, here are some
generally applicable countermeasures:
o The authorization server should validate the client id associated
with the particular refresh token with every refresh request
(Section 5.2.2.2).
o Limit token scope (Section 5.1.5.1).
o Revoke refresh tokens (Section 5.2.2.4).
o Revoke client secrets (Section 5.2.3.6).
o Refresh tokens can automatically be replaced in order to detect
unauthorized token usage by another party (see "Refresh Token
Rotation", Section 5.2.2.3).
Attack: Obtain Refresh Token from Web Application:
An attacker may obtain the refresh tokens issued to a web application
by way of overcoming the web server's security controls.
Impact: Since a web application manages the user accounts of a
certain site, such an attack would result in an exposure of all
refresh tokens on that site to the attacker.
Countermeasures: o Standard web server protection measures (Section 5.3.2). o Use strong client authentication (e.g., client_assertion/ client_token) so the attacker cannot obtain the client secret required to exchange the tokens (Section 5.2.3.7). Attack: Obtain Refresh Token from Native Clients: On native clients, leakage of a refresh token typically affects a single user only. Read from local file system: The attacker could try to get file system access on the device and read the refresh tokens. The attacker could utilize a malicious application for that purpose. Countermeasures: o Store secrets in secure storage (Section 5.3.3). o Utilize device lock to prevent unauthorized device access (Section 5.3.4). Attack: Steal Device: The host device (e.g., mobile phone) may be stolen. In that case, the attacker gets access to all applications under the identity of the legitimate user. Countermeasures: o Utilize device lock to prevent unauthorized device access (Section 5.3.4). o Where a user knows the device has been stolen, they can revoke the affected tokens (Section 5.2.2.4). Attack: Clone Device: All device data and applications are copied to another device. Applications are used as-is on the target device.
Countermeasures:
o Utilize device lock to prevent unauthorized device access
(Section 5.3.4).
o Combine refresh token request with device identification
(Section 5.2.2.5).
o Refresh token rotation (Section 5.2.2.3).
o Where a user knows the device has been cloned, they can use
refresh token revocation (Section 5.2.2.4).
4.1.3. Threat: Obtaining Access Tokens
Depending on the client type, there are different ways that access
tokens may be revealed to an attacker. Access tokens could be stolen
from the device if the application stores them in a storage device
that is accessible to other applications.
Impact: Where the token is a bearer token and no additional mechanism
is used to identify the client, the attacker can access all resources
associated with the token and its scope.
Countermeasures:
o Keep access tokens in transient memory and limit grants
(Section 5.1.6).
o Limit token scope (Section 5.1.5.1).
o Keep access tokens in private memory or apply same protection
means as for refresh tokens (Section 5.2.2).
o Keep access token lifetime short (Section 5.1.5.3).
4.1.4. Threat: End-User Credentials Phished Using Compromised or
Embedded Browser
A malicious application could attempt to phish end-user passwords by
misusing an embedded browser in the end-user authorization process,
or by presenting its own user interface instead of allowing a trusted
system browser to render the authorization user interface. By doing
so, the usual visual trust mechanisms may be bypassed (e.g.,
Transport Layer Security (TLS) confirmation, web site mechanisms).
By using an embedded or internal client application user interface,
the client application has access to additional information to which
it should not have access (e.g., UID/password).
Impact: If the client application or the communication is
compromised, the user would not be aware of this, and all information
in the authorization exchange, such as username and password, could
be captured.
Countermeasures:
o The OAuth flow is designed so that client applications never need
to know user passwords. Client applications should avoid directly
asking users for their credentials. In addition, end users could
be educated about phishing attacks and best practices, such as
only accessing trusted clients, as OAuth does not provide any
protection against malicious applications and the end user is
solely responsible for the trustworthiness of any native
application installed.
o Client applications could be validated prior to publication in an
application market for users to access. That validation is out of
scope for OAuth but could include validating that the client
application handles user authentication in an appropriate way.
o Client developers should not write client applications that
collect authentication information directly from users and should
instead delegate this task to a trusted system component, e.g.,
the system browser.
4.1.5. Threat: Open Redirectors on Client
An open redirector is an endpoint using a parameter to automatically
redirect a user agent to the location specified by the parameter
value without any validation. If the authorization server allows the
client to register only part of the redirect URI, an attacker can use
an open redirector operated by the client to construct a redirect URI
that will pass the authorization server validation but will send the
authorization "code" or access token to an endpoint under the control
of the attacker.
Impact: An attacker could gain access to authorization "codes" or
access tokens.
Countermeasures:
o Require clients to register full redirect URI (Section 5.2.3.5).
4.2. Authorization Endpoint
4.2.1. Threat: Password Phishing by Counterfeit Authorization Server
OAuth makes no attempt to verify the authenticity of the authorization server. A hostile party could take advantage of this by intercepting the client's requests and returning misleading or otherwise incorrect responses. This could be achieved using DNS or Address Resolution Protocol (ARP) spoofing. Wide deployment of OAuth and similar protocols may cause users to become inured to the practice of being redirected to web sites where they are asked to enter their passwords. If users are not careful to verify the authenticity of these web sites before entering their credentials, it will be possible for attackers to exploit this practice to steal users' passwords. Countermeasures: o Authorization servers should consider such attacks when developing services based on OAuth and should require the use of transport- layer security for any requests where the authenticity of the authorization server or of request responses is an issue (see Section 5.1.2). o Authorization servers should attempt to educate users about the risks posed by phishing attacks and should provide mechanisms that make it easy for users to confirm the authenticity of their sites.4.2.2. Threat: User Unintentionally Grants Too Much Access Scope
When obtaining end-user authorization, the end user may not understand the scope of the access being granted and to whom, or they may end up providing a client with access to resources that should not be permitted. Countermeasures: o Explain the scope (resources and the permissions) the user is about to grant in an understandable way (Section 5.2.4.2). o Narrow the scope, based on the client. When obtaining end-user authorization and where the client requests scope, the authorization server may want to consider whether to honor that scope based on the client identifier. That decision is between the client and authorization server and is outside the scope of this spec. The authorization server may also want to consider what scope to grant based on the client type, e.g., providing lower scope to public clients (Section 5.1.5.1).
4.2.3. Threat: Malicious Client Obtains Existing Authorization by Fraud
Authorization servers may wish to automatically process authorization requests from clients that have been previously authorized by the user. When the user is redirected to the authorization server's end- user authorization endpoint to grant access, the authorization server detects that the user has already granted access to that particular client. Instead of prompting the user for approval, the authorization server automatically redirects the user back to the client. A malicious client may exploit that feature and try to obtain such an authorization "code" instead of the legitimate client. Countermeasures: o Authorization servers should not automatically process repeat authorizations to public clients unless the client is validated using a pre-registered redirect URI (Section 5.2.3.5). o Authorization servers can mitigate the risks associated with automatic processing by limiting the scope of access tokens obtained through automated approvals (Section 5.1.5.1).4.2.4. Threat: Open Redirector
An attacker could use the end-user authorization endpoint and the redirect URI parameter to abuse the authorization server as an open redirector. An open redirector is an endpoint using a parameter to automatically redirect a user agent to the location specified by the parameter value without any validation. Impact: An attacker could utilize a user's trust in an authorization server to launch a phishing attack. Countermeasures: o Require clients to register any full redirect URIs (Section 5.2.3.5). o Don't redirect to a redirect URI if the client identifier or redirect URI can't be verified (Section 5.2.3.5).
4.3. Token Endpoint
4.3.1. Threat: Eavesdropping Access Tokens
Attackers may attempt to eavesdrop access tokens in transit from the authorization server to the client. Impact: The attacker is able to access all resources with the permissions covered by the scope of the particular access token. Countermeasures: o As per the core OAuth spec, the authorization servers must ensure that these transmissions are protected using transport-layer mechanisms such as TLS (see Section 5.1.1). o If end-to-end confidentiality cannot be guaranteed, reducing scope (see Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access tokens can be used to reduce the damage in case of leaks.4.3.2. Threat: Obtaining Access Tokens from Authorization Server Database
This threat is applicable if the authorization server stores access tokens as handles in a database. An attacker may obtain access tokens from the authorization server's database by gaining access to the database or launching a SQL injection attack. Impact: Disclosure of all access tokens. Countermeasures: o Enforce system security measures (Section 5.1.4.1.1). o Store access token hashes only (Section 5.1.4.1.3). o Enforce standard SQL injection countermeasures (Section 5.1.4.1.2).4.3.3. Threat: Disclosure of Client Credentials during Transmission
An attacker could attempt to eavesdrop the transmission of client credentials between the client and server during the client authentication process or during OAuth token requests. Impact: Revelation of a client credential enabling phishing or impersonation of a client service.
Countermeasures:
o The transmission of client credentials must be protected using
transport-layer mechanisms such as TLS (see Section 5.1.1).
o Use alternative authentication means that do not require the
sending of plaintext credentials over the wire (e.g., Hash-based
Message Authentication Code).
4.3.4. Threat: Obtaining Client Secret from Authorization Server
Database
An attacker may obtain valid "client_id"/secret combinations from the
authorization server's database by gaining access to the database or
launching a SQL injection attack.
Impact: Disclosure of all "client_id"/secret combinations. This
allows the attacker to act on behalf of legitimate clients.
Countermeasures:
o Enforce system security measures (Section 5.1.4.1.1).
o Enforce standard SQL injection countermeasures
(Section 5.1.4.1.2).
o Ensure proper handling of credentials as per "Enforce Credential
Storage Protection Best Practices" (Section 5.1.4.1).
4.3.5. Threat: Obtaining Client Secret by Online Guessing
An attacker may try to guess valid "client_id"/secret pairs.
Impact: Disclosure of a single "client_id"/secret pair.
Countermeasures:
o Use high entropy for secrets (Section 5.1.4.2.2).
o Lock accounts (Section 5.1.4.2.3).
o Use strong client authentication (Section 5.2.3.7).
4.4. Obtaining Authorization
This section covers threats that are specific to certain flows utilized to obtain access tokens. Each flow is characterized by response types and/or grant types on the end-user authorization and token endpoint, respectively.4.4.1. Authorization "code"
4.4.1.1. Threat: Eavesdropping or Leaking Authorization "codes"
An attacker could try to eavesdrop transmission of the authorization "code" between the authorization server and client. Furthermore, authorization "codes" are passed via the browser, which may unintentionally leak those codes to untrusted web sites and attackers in different ways: o Referrer headers: Browsers frequently pass a "referer" header when a web page embeds content, or when a user travels from one web page to another web page. These referrer headers may be sent even when the origin site does not trust the destination site. The referrer header is commonly logged for traffic analysis purposes. o Request logs: Web server request logs commonly include query parameters on requests. o Open redirectors: Web sites sometimes need to send users to another destination via a redirector. Open redirectors pose a particular risk to web-based delegation protocols because the redirector can leak verification codes to untrusted destination sites. o Browser history: Web browsers commonly record visited URLs in the browser history. Another user of the same web browser may be able to view URLs that were visited by previous users. Note: A description of similar attacks on the SAML protocol can be found at [OASIS.sstc-saml-bindings-1.1], Section 4.1.1.9.1; [Sec-Analysis]; and [OASIS.sstc-sec-analysis-response-01].
Countermeasures:
o As per the core OAuth spec, the authorization server as well as
the client must ensure that these transmissions are protected
using transport-layer mechanisms such as TLS (see Section 5.1.1).
o The authorization server will require the client to authenticate
wherever possible, so the binding of the authorization "code" to a
certain client can be validated in a reliable way (see
Section 5.2.4.4).
o Use short expiry time for authorization "codes" (Section 5.1.5.3).
o The authorization server should enforce a one-time usage
restriction (see Section 5.1.5.4).
o If an authorization server observes multiple attempts to redeem an
authorization "code", the authorization server may want to revoke
all tokens granted based on the authorization "code" (see
Section 5.2.1.1).
o In the absence of these countermeasures, reducing scope
(Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access
tokens can be used to reduce the damage in case of leaks.
o The client server may reload the target page of the redirect URI
in order to automatically clean up the browser cache.
4.4.1.2. Threat: Obtaining Authorization "codes" from Authorization
Server Database
This threat is applicable if the authorization server stores
authorization "codes" as handles in a database. An attacker may
obtain authorization "codes" from the authorization server's database
by gaining access to the database or launching a SQL injection
attack.
Impact: Disclosure of all authorization "codes", most likely along
with the respective "redirect_uri" and "client_id" values.
Countermeasures:
o Best practices for credential storage protection should be
employed (Section 5.1.4.1).
o Enforce system security measures (Section 5.1.4.1.1).
o Store access token hashes only (Section 5.1.4.1.3). o Enforce standard SQL injection countermeasures (Section 5.1.4.1.2).4.4.1.3. Threat: Online Guessing of Authorization "codes"
An attacker may try to guess valid authorization "code" values and send the guessed code value using the grant type "code" in order to obtain a valid access token. Impact: Disclosure of a single access token and probably also an associated refresh token. Countermeasures: o Handle-based tokens must use high entropy (Section 5.1.4.2.2). o Assertion-based tokens should be signed (Section 5.1.5.9). o Authenticate the client; this adds another value that the attacker has to guess (Section 5.2.3.4). o Bind the authorization "code" to the redirect URI; this adds another value that the attacker has to guess (Section 5.2.4.5). o Use short expiry time for tokens (Section 5.1.5.3).4.4.1.4. Threat: Malicious Client Obtains Authorization
A malicious client could pretend to be a valid client and obtain an access authorization in this way. The malicious client could even utilize screen-scraping techniques in order to simulate a user's consent in the authorization flow. Assumption: It is not the task of the authorization server to protect the end-user's device from malicious software. This is the responsibility of the platform running on the particular device, probably in cooperation with other components of the respective ecosystem (e.g., an application management infrastructure). The sole responsibility of the authorization server is to control access to the end-user's resources maintained in resource servers and to prevent unauthorized access to them via the OAuth protocol. Based on this assumption, the following countermeasures are available to cope with the threat.
Countermeasures:
o The authorization server should authenticate the client, if
possible (see Section 5.2.3.4). Note: The authentication takes
place after the end user has authorized the access.
o The authorization server should validate the client's redirect URI
against the pre-registered redirect URI, if one exists (see
Section 5.2.3.5). Note: An invalid redirect URI indicates an
invalid client, whereas a valid redirect URI does not necessarily
indicate a valid client. The level of confidence depends on the
client type. For web applications, the level of confidence is
high, since the redirect URI refers to the globally unique network
endpoint of this application, whose fully qualified domain name
(FQDN) is also validated using HTTPS server authentication by the
user agent. In contrast, for native clients, the redirect URI
typically refers to device local resources, e.g., a custom scheme.
So, a malicious client on a particular device can use the valid
redirect URI the legitimate client uses on all other devices.
o After authenticating the end user, the authorization server should
ask him/her for consent. In this context, the authorization
server should explain to the end user the purpose, scope, and
duration of the authorization the client asked for. Moreover, the
authorization server should show the user any identity information
it has for that client. It is up to the user to validate the
binding of this data to the particular application (e.g., Name)
and to approve the authorization request (see Section 5.2.4.3).
o The authorization server should not perform automatic
re-authorizations for clients it is unable to reliably
authenticate or validate (see Section 5.2.4.1).
o If the authorization server automatically authenticates the end
user, it may nevertheless require some user input in order to
prevent screen scraping. Examples are CAPTCHAs (Completely
Automated Public Turing tests to tell Computers and Humans Apart)
or other multi-factor authentication techniques such as random
questions, token code generators, etc.
o The authorization server may also limit the scope of tokens it
issues to clients it cannot reliably authenticate (see
Section 5.1.5.1).
4.4.1.5. Threat: Authorization "code" Phishing
A hostile party could impersonate the client site and get access to the authorization "code". This could be achieved using DNS or ARP spoofing. This applies to clients, which are web applications; thus, the redirect URI is not local to the host where the user's browser is running. Impact: This affects web applications and may lead to a disclosure of authorization "codes" and, potentially, the corresponding access and refresh tokens. Countermeasures: It is strongly recommended that one of the following countermeasures be utilized in order to prevent this attack: o The redirect URI of the client should point to an HTTPS-protected endpoint, and the browser should be utilized to authenticate this redirect URI using server authentication (see Section 5.1.2). o The authorization server should require that the client be authenticated, i.e., confidential client, so the binding of the authorization "code" to a certain client can be validated in a reliable way (see Section 5.2.4.4).4.4.1.6. Threat: User Session Impersonation
A hostile party could impersonate the client site and impersonate the user's session on this client. This could be achieved using DNS or ARP spoofing. This applies to clients, which are web applications; thus, the redirect URI is not local to the host where the user's browser is running. Impact: An attacker who intercepts the authorization "code" as it is sent by the browser to the callback endpoint can gain access to protected resources by submitting the authorization "code" to the client. The client will exchange the authorization "code" for an access token and use the access token to access protected resources for the benefit of the attacker, delivering protected resources to the attacker, or modifying protected resources as directed by the attacker. If OAuth is used by the client to delegate authentication to a social site (e.g., as in the implementation of a "Login" button on a third-party social network site), the attacker can use the intercepted authorization "code" to log into the client as the user.
Note: Authenticating the client during authorization "code" exchange
will not help to detect such an attack, as it is the legitimate
client that obtains the tokens.
Countermeasures:
o In order to prevent an attacker from impersonating the end-user's
session, the redirect URI of the client should point to an HTTPS
protected endpoint, and the browser should be utilized to
authenticate this redirect URI using server authentication (see
Section 5.1.2).
4.4.1.7. Threat: Authorization "code" Leakage through Counterfeit
Client
The attacker leverages the authorization "code" grant type in an
attempt to get another user (victim) to log in, authorize access to
his/her resources, and subsequently obtain the authorization "code"
and inject it into a client application using the attacker's account.
The goal is to associate an access authorization for resources of the
victim with the user account of the attacker on a client site.
The attacker abuses an existing client application and combines it
with his own counterfeit client web site. The attacker depends on
the victim expecting the client application to request access to a
certain resource server. The victim, seeing only a normal request
from an expected application, approves the request. The attacker
then uses the victim's authorization to gain access to the
information unknowingly authorized by the victim.
The attacker conducts the following flow:
1. The attacker accesses the client web site (or application) and
initiates data access to a particular resource server. The
client web site in turn initiates an authorization request to the
resource server's authorization server. Instead of proceeding
with the authorization process, the attacker modifies the
authorization server end-user authorization URL as constructed by
the client to include a redirect URI parameter referring to a web
site under his control (attacker's web site).
2. The attacker tricks another user (the victim) into opening that
modified end-user authorization URI and authorizing access (e.g.,
via an email link or blog link). The way the attacker achieves
this goal is out of scope.
3. Having clicked the link, the victim is requested to authenticate
and authorize the client site to have access.
4. After completion of the authorization process, the authorization
server redirects the user agent to the attacker's web site
instead of the original client web site.
5. The attacker obtains the authorization "code" from his web site
by means that are out of scope of this document.
6. He then constructs a redirect URI to the target web site (or
application) based on the original authorization request's
redirect URI and the newly obtained authorization "code", and
directs his user agent to this URL. The authorization "code" is
injected into the original client site (or application).
7. The client site uses the authorization "code" to fetch a token
from the authorization server and associates this token with the
attacker's user account on this site.
8. The attacker may now access the victim's resources using the
client site.
Impact: The attacker gains access to the victim's resources as
associated with his account on the client site.
Countermeasures:
o The attacker will need to use another redirect URI for its
authorization process rather 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 and validates this redirect URI
with the redirect URI passed to the token's endpoint, such an
attack is detected (see Section 5.2.4.5).
o The authorization server may also enforce the usage and validation
of pre-registered redirect URIs (see Section 5.2.3.5). This will
allow for early recognition of authorization "code" disclosure to
counterfeit clients.
o For native applications, one could also consider using deployment-
specific client ids and secrets (see Section 5.2.3.4), along with
the binding of authorization "codes" to "client_ids" (see
Section 5.2.4.4) to detect such an attack because the attacker
does not have access to the deployment-specific secret. Thus, he
will not be able to exchange the authorization "code".
o The client may consider using other flows that are not vulnerable
to this kind of attack, such as the implicit grant type (see
Section 4.4.2) or resource owner password credentials (see
Section 4.4.3).
4.4.1.8. Threat: CSRF Attack against redirect-uri
Cross-site request forgery (CSRF) is a web-based attack whereby HTTP
requests are transmitted from a user that the web site trusts or has
authenticated (e.g., via HTTP redirects or HTML forms). CSRF attacks
on OAuth approvals can allow an attacker to obtain authorization to
OAuth protected resources without the consent of the user.
This attack works against the redirect URI used in the authorization
"code" flow. An attacker could authorize an authorization "code" to
their own protected resources on an authorization server. He then
aborts the redirect flow back to the client on his device and tricks
the victim into executing the redirect back to the client. The
client receives the redirect, fetches the token(s) from the
authorization server, and associates the victim's client session with
the resources accessible using the token.
Impact: The user accesses resources on behalf of the attacker. The
effective impact depends on the type of resource accessed. For
example, the user may upload private items to an attacker's
resources. Or, when using OAuth in 3rd-party login scenarios, the
user may associate his client account with the attacker's identity at
the external Identity Provider. In this way, the attacker could
easily access the victim's data at the client by logging in from
another device with his credentials at the external Identity
Provider.
Countermeasures:
o The "state" parameter should be used to link the authorization
request with the redirect URI used to deliver the access token
(Section 5.3.5).
o Client developers and end users can be educated to not follow
untrusted URLs.
4.4.1.9. Threat: Clickjacking Attack against Authorization
With clickjacking, a malicious site loads the target site in a transparent iFrame (see [iFrame]) overlaid on top of a set of dummy buttons that are carefully constructed to be placed directly under important buttons on the target site. When a user clicks a visible button, they are actually clicking a button (such as an "Authorize" button) on the hidden page. Impact: An attacker can steal a user's authentication credentials and access their resources. Countermeasures: o For newer browsers, avoidance of iFrames during authorization can be enforced on the server side by using the X-FRAME-OPTIONS header (Section 5.2.2.6). o For older browsers, JavaScript frame-busting (see [Framebusting]) techniques can be used but may not be effective in all browsers.4.4.1.10. Threat: Resource Owner Impersonation
When a client requests access to protected resources, the authorization flow normally involves the resource owner's explicit response to the access request, either granting or denying access to the protected resources. A malicious client can exploit knowledge of the structure of this flow in order to gain authorization without the resource owner's consent, by transmitting the necessary requests programmatically and simulating the flow against the authorization server. That way, the client may gain access to the victim's resources without her approval. An authorization server will be vulnerable to this threat if it uses non-interactive authentication mechanisms or splits the authorization flow across multiple pages. The malicious client might embed a hidden HTML user agent, interpret the HTML forms sent by the authorization server, and automatically send the corresponding form HTTP POST requests. As a prerequisite, the attacker must be able to execute the authorization process in the context of an already-authenticated session of the resource owner with the authorization server. There are different ways to achieve this: o The malicious client could abuse an existing session in an external browser or cross-browser cookies on the particular device.
o The malicious client could also request authorization for an
initial scope acceptable to the user and then silently abuse the
resulting session in his browser instance to "silently" request
another scope.
o Alternatively, the attacker might exploit an authorization
server's ability to authenticate the resource owner automatically
and without user interactions, e.g., based on certificates.
In all cases, such an attack is limited to clients running on the
victim's device, either within the user agent or as a native app.
Please note: Such attacks cannot be prevented using CSRF
countermeasures, since the attacker just "executes" the URLs as
prepared by the authorization server including any nonce, etc.
Countermeasures:
Authorization servers should decide, based on an analysis of the risk
associated with this threat, whether to detect and prevent this
threat.
In order to prevent such an attack, the authorization server may
force a user interaction based on non-predictable input values as
part of the user consent approval. The authorization server could
o combine password authentication and user consent in a single form,
o make use of CAPTCHAs, or
o use one-time secrets sent out of band to the resource owner (e.g.,
via text or instant message).
Alternatively, in order to allow the resource owner to detect abuse,
the authorization server could notify the resource owner of any
approval by appropriate means, e.g., text or instant message, or
email.
4.4.1.11. Threat: DoS Attacks That Exhaust Resources
If an authorization server includes a nontrivial amount of entropy in
authorization "codes" or access tokens (limiting the number of
possible codes/tokens) and automatically grants either without user
intervention and has no limit on codes or access tokens per user, an
attacker could exhaust the pool of authorization "codes" by
repeatedly directing the user's browser to request authorization
"codes" or access tokens.
Countermeasures:
o The authorization server should consider limiting the number of
access tokens granted per user.
o The authorization server should include a nontrivial amount of
entropy in authorization "codes".
4.4.1.12. Threat: DoS Using Manufactured Authorization "codes"
An attacker who owns a botnet can locate the redirect URIs of clients
that listen on HTTP, access them with random authorization "codes",
and cause a large number of HTTPS connections to be concentrated onto
the authorization server. This can result in a denial-of-service
(DoS) attack on the authorization server.
This attack can still be effective even when CSRF defense/the "state"
parameter (see Section 4.4.1.8) is deployed on the client side. With
such a defense, the attacker might need to incur an additional HTTP
request to obtain a valid CSRF code/"state" parameter. This
apparently cuts down the effectiveness of the attack by a factor of
2. However, if the HTTPS/HTTP cost ratio is higher than 2 (the cost
factor is estimated to be around 3.5x at [SSL-Latency]), the attacker
still achieves a magnification of resource utilization at the expense
of the authorization server.
Impact: There are a few effects that the attacker can accomplish with
this OAuth flow that they cannot easily achieve otherwise.
1. Connection laundering: With the clients as the relay between the
attacker and the authorization server, the authorization server
learns little or no information about the identity of the
attacker. Defenses such as rate-limiting on the offending
attacker machines are less effective because it is difficult to
identify the attacking machines. Although an attacker could also
launder its connections through an anonymizing system such as
Tor, the effectiveness of that approach depends on the capacity
of the anonymizing system. On the other hand, a potentially
large number of OAuth clients could be utilized for this attack.
2. Asymmetric resource utilization: The attacker incurs the cost of
an HTTP connection and causes an HTTPS connection to be made on
the authorization server; the attacker can coordinate the timing
of such HTTPS connections across multiple clients relatively
easily. Although the attacker could achieve something similar,
say, by including an iFrame pointing to the HTTPS URL of the
authorization server in an HTTP web page and luring web users to
visit that page, timing attacks using such a scheme may be more
difficult, as it seems nontrivial to synchronize a large number
of users to simultaneously visit a particular site under the
attacker's control.
Countermeasures:
o Though not a complete countermeasure by themselves, CSRF defense
and the "state" parameter created with secure random codes should
be deployed on the client side. The client should forward the
authorization "code" to the authorization server only after both
the CSRF token and the "state" parameter are validated.
o If the client authenticates the user, either through a single-
sign-on protocol or through local authentication, the client
should suspend the access by a user account if the number of
invalid authorization "codes" submitted by this user exceeds a
certain threshold.
o The authorization server should send an error response to the
client reporting an invalid authorization "code" and rate-limit or
disallow connections from clients whose number of invalid requests
exceeds a threshold.
4.4.1.13. Threat: Code Substitution (OAuth Login)
An attacker could attempt to log into an application or web site
using a victim's identity. Applications relying on identity data
provided by an OAuth protected service API to login users are
vulnerable to this threat. This pattern can be found in so-called
"social login" scenarios.
As a prerequisite, a resource server offers an API to obtain personal
information about a user that could be interpreted as having obtained
a user identity. In this sense, the client is treating the resource
server API as an "identity" API. A client utilizes OAuth to obtain
an access token for the identity API. It then queries the identity
API for an identifier and uses it to look up its internal user
account data (login). The client assumes that, because it was able
to obtain information about the user, the user has been
authenticated.
If the client uses the grant type "code", the attacker needs to
gather a valid authorization "code" of the respective victim from the
same Identity Provider used by the target client application. The
attacker tricks the victim into logging into a malicious app (which
may appear to be legitimate to the Identity Provider) using the same
Identity Provider as the target application. This results in the
Identity Provider's authorization server issuing an authorization
"code" for the respective identity API. The malicious app then sends
this code to the attacker, which in turn triggers a login process
within the target application. The attacker now manipulates the
authorization response and substitutes their code (bound to their
identity) for the victim's code. This code is then exchanged by the
client for an access token, which in turn is accepted by the identity
API, since the audience, with respect to the resource server, is
correct. But since the identifier returned by the identity API is
determined by the identity in the access token (issued based on the
victim's code), the attacker is logged into the target application
under the victim's identity.
Impact: The attacker gains access to an application and user-specific
data within the application.
Countermeasures:
o All clients must indicate their client ids with every request to
exchange an authorization "code" for an access token. The
authorization server must validate whether the particular
authorization "code" has been issued to the particular client. If
possible, the client shall be authenticated beforehand.
o Clients should use an appropriate protocol, such as OpenID (cf.
[OPENID]) or SAML (cf. [OASIS.sstc-saml-bindings-1.1]) to
implement user login. Both support audience restrictions on
clients.
4.4.2. Implicit Grant
In the implicit grant type flow, the access token is directly
returned to the client as a fragment part of the redirect URI. It is
assumed that the token is not sent to the redirect URI target, as
HTTP user agents do not send the fragment part of URIs to HTTP
servers. Thus, an attacker cannot eavesdrop the access token on this
communication path, and the token cannot leak through HTTP referrer
headers.
4.4.2.1. Threat: Access Token Leak in Transport/Endpoints
This token might be eavesdropped by an attacker. The token is sent
from the server to the client via a URI fragment of the redirect URI.
If the communication is not secured or the endpoint 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.
Countermeasures:
o The authorization server should ensure confidentiality (e.g.,
using TLS) of the response from the authorization server to the
client (see Section 5.1.1).
4.4.2.2. Threat: Access Token Leak in Browser History
An attacker could obtain the token from the browser's history. Note
that this means the attacker needs access to the particular device.
Countermeasures:
o Use short expiry time for tokens (see Section 5.1.5.3). Reduced
scope of the token may reduce the impact of that attack (see
Section 5.1.5.1).
o Make responses non-cacheable.
4.4.2.3. Threat: Malicious Client Obtains Authorization
A malicious client could attempt to obtain a token by fraud.
The same countermeasures as for Section 4.4.1.4 are applicable,
except client authentication.
4.4.2.4. Threat: Manipulation of Scripts
A hostile party could act as the client web server and replace or
modify the actual implementation of the client (script). This could
be achieved using DNS or ARP spoofing. This applies to clients
implemented within the web browser in a scripting language.
Impact: The attacker could obtain user credential information and
assume the full identity of the user.
Countermeasures:
o The authorization server should authenticate the server from which
scripts are obtained (see Section 5.1.2).
o The client should ensure that scripts obtained have not been
altered in transport (see Section 5.1.1).
o Introduce one-time, per-use secrets (e.g., "client_secret") values
that can only be used by scripts in a small time window once
loaded from a server. The intention would be to reduce the
effectiveness of copying client-side scripts for re-use in an
attacker's modified code.
4.4.2.5. Threat: CSRF Attack against redirect-uri
CSRF attacks (see Section 4.4.1.8) also work against the redirect URI
used in the implicit grant flow. An attacker could acquire an access
token to their own protected resources. He could then construct a
redirect URI and embed their access token in that URI. If he can
trick the user into following the redirect URI and the client does
not have protection against this attack, the user may have the
attacker's access token authorized within their client.
Impact: The user accesses resources on behalf of the attacker. The
effective impact depends on the type of resource accessed. For
example, the user may upload private items to an attacker's
resources. Or, when using OAuth in 3rd-party login scenarios, the
user may associate his client account with the attacker's identity at
the external Identity Provider. In this way, the attacker could
easily access the victim's data at the client by logging in from
another device with his credentials at the external Identity
Provider.
Countermeasures:
o The "state" parameter should be used to link the authorization
request with the redirect URI used to deliver the access token.
This will ensure that the client is not tricked into completing
any redirect callback unless it is linked to an authorization
request initiated by the client. The "state" parameter should not
be guessable, and the client should be capable of keeping the
"state" parameter secret.
o Client developers and end users can be educated to not follow
untrusted URLs.
4.4.2.6. Threat: Token Substitution (OAuth Login)
An attacker could attempt to log into an application or web site
using a victim's identity. Applications relying on identity data
provided by an OAuth protected service API to login users are
vulnerable to this threat. This pattern can be found in so-called
"social login" scenarios.
As a prerequisite, a resource server offers an API to obtain personal
information about a user that could be interpreted as having obtained
a user identity. In this sense, the client is treating the resource
server API as an "identity" API. A client utilizes OAuth to obtain
an access token for the identity API. It then queries the identity
API for an identifier and uses it to look up its internal user
account data (login). The client assumes that, because it was able
to obtain information about the user, the user has been
authenticated.
To succeed, the attacker needs to gather a valid access token of the
respective victim from the same Identity Provider used by the target
client application. The attacker tricks the victim into logging into
a malicious app (which may appear to be legitimate to the Identity
Provider) using the same Identity Provider as the target application.
This results in the Identity Provider's authorization server issuing
an access token for the respective identity API. The malicious app
then sends this access token to the attacker, which in turn triggers
a login process within the target application. The attacker now
manipulates the authorization response and substitutes their access
token (bound to their identity) for the victim's access token. This
token is accepted by the identity API, since the audience, with
respect to the resource server, is correct. But since the identifier
returned by the identity API is determined by the identity in the
access token, the attacker is logged into the target application
under the victim's identity.
Impact: The attacker gains access to an application and user-specific
data within the application.
Countermeasures:
o Clients should use an appropriate protocol, such as OpenID (cf.
[OPENID]) or SAML (cf. [OASIS.sstc-saml-bindings-1.1]) to
implement user login. Both support audience restrictions on
clients.
4.4.3. Resource Owner Password Credentials
The resource owner password credentials grant type (see [RFC6749],
Section 4.3), often used for legacy/migration reasons, allows a
client to request an access token using an end-user's user id and
password along with its own credential. This grant type has higher
risk because it maintains the UID/password anti-pattern.
Additionally, because the user does not have control over the
authorization process, clients using this grant type are not limited
by scope but instead have potentially the same capabilities as the
user themselves. As there is no authorization step, the ability to
offer token revocation is bypassed.
Because passwords are often used for more than 1 service, this
anti-pattern may also put at risk whatever else is accessible with
the supplied credential. Additionally, any easily derived equivalent
(e.g., joe@example.com and joe@example.net) might easily allow
someone to guess that the same password can be used elsewhere.
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-lived tokens and pass them up to an
attacker's web service for further abuse. The client, eavesdroppers,
or endpoints could eavesdrop the user id and password.
Countermeasures:
o Except for migration reasons, minimize use of this grant type.
o The authorization server should validate the client id associated
with the particular refresh token with every refresh request
(Section 5.2.2.2).
o As per the core OAuth specification, the authorization server must
ensure that these transmissions are protected using transport-
layer mechanisms such as TLS (see Section 5.1.1).
o Rather than encouraging users to use a UID and password, service
providers should instead encourage users not to use the same
password for multiple services.
o Limit use of resource owner password credential grants to
scenarios where the client application and the authorizing service
are from the same organization.
4.4.3.1. Threat: Accidental Exposure of Passwords at Client Site
If the client does not provide enough protection, an attacker or
disgruntled employee could retrieve the passwords for a user.
Countermeasures:
o Use other flows that do not rely on the client's cooperation for
secure resource owner credential handling.
o Use digest authentication instead of plaintext credential
processing.
o Obfuscate passwords in logs.4.4.3.2. Threat: Client Obtains Scopes without End-User Authorization
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. Countermeasures: o Use other flows that do not rely on the client's cooperation for resource owner interaction. o The authorization server may generally restrict the scope of access tokens (Section 5.1.5.1) issued by this flow. If the particular client is trustworthy and can be authenticated in a reliable way, the authorization server could relax that restriction. Resource owners may prescribe (e.g., in their preferences) what the maximum scope is for clients using this flow. o The authorization server could notify the resource owner by an appropriate medium, e.g., email, of the grant issued (see Section 5.1.3).4.4.3.3. Threat: Client Obtains Refresh Token through Automatic Authorization
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. Countermeasures: o Use other flows that do not rely on the client's cooperation for resource owner interaction. o The authorization server may generally refuse to issue refresh tokens in this flow (see Section 5.2.2.1). If the particular client is trustworthy and can be authenticated in a reliable way (see client authentication), the authorization server could relax
that restriction. Resource owners may allow or deny (e.g., in
their preferences) the issuing of refresh tokens using this flow
as well.
o The authorization server could notify the resource owner by an
appropriate medium, e.g., email, of the refresh token issued (see
Section 5.1.3).
4.4.3.4. Threat: Obtaining User Passwords on Transport
An attacker could attempt to eavesdrop the transmission of end-user
credentials with the grant type "password" between the client and
server.
Impact: Disclosure of a single end-user's password.
Countermeasures:
o Ensure confidentiality of requests (Section 5.1.1).
o Use alternative authentication means that do not require the
sending of plaintext credentials over the wire (e.g., Hash-based
Message Authentication Code).
4.4.3.5. Threat: Obtaining User Passwords from Authorization Server
Database
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.
Impact: Disclosure of all username/password combinations. The impact
may exceed the domain of the authorization server, since many users
tend to use the same credentials on different services.
Countermeasures:
o Enforce credential storage protection best practices
(Section 5.1.4.1).
4.4.3.6. Threat: Online Guessing
An attacker may try to guess valid username/password combinations
using the grant type "password".
Impact: Revelation of a single username/password combination.
Countermeasures: o Utilize secure password policy (Section 5.1.4.2.1). o Lock accounts (Section 5.1.4.2.3). o Use tar pit (Section 5.1.4.2.4). o Use CAPTCHAs (Section 5.1.4.2.5). o Consider not using the grant type "password". o Client authentication (see Section 5.2.3) will provide another authentication factor and thus hinder the attack.4.4.4. Client Credentials
Client credentials (see [RFC6749], Section 3) consist of an identifier (not secret) combined with an additional means (such as a matching client secret) of authenticating a client. The threats to this grant type are similar to those described in Section 4.4.3.
(page 44 continued on part 3)
