tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6819

 
 
 

OAuth 2.0 Threat Model and Security Considerations

Part 2 of 3, p. 15 to 44
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 15 
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.

Top      Up      ToC       Page 16 
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).

Top      Up      ToC       Page 17 
   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.

Top      Up      ToC       Page 18 
   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.

Top      Up      ToC       Page 19 
   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).

Top      Up      ToC       Page 20 
   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).

Top      Up      ToC       Page 21 
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).

Top      Up      ToC       Page 22 
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).

Top      Up      ToC       Page 23 
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.

Top      Up      ToC       Page 24 
   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).

Top      Up      ToC       Page 25 
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].

Top      Up      ToC       Page 26 
   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).

Top      Up      ToC       Page 27 
   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.

Top      Up      ToC       Page 28 
   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).

Top      Up      ToC       Page 29 
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.

Top      Up      ToC       Page 30 
   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.

Top      Up      ToC       Page 31 
   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".

Top      Up      ToC       Page 32 
   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.

Top      Up      ToC       Page 33 
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.

Top      Up      ToC       Page 34 
   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.

Top      Up      ToC       Page 35 
   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

Top      Up      ToC       Page 36 
       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

Top      Up      ToC       Page 37 
   "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.

Top      Up      ToC       Page 38 
   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).

Top      Up      ToC       Page 39 
   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.

Top      Up      ToC       Page 40 
   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

Top      Up      ToC       Page 41 
   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.

Top      Up      ToC       Page 42 
   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

Top      Up      ToC       Page 43 
      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.

Top      Up      ToC       Page 44 
   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)

Next RFC Part