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 3 of 3, p. 44 to 71
Prev RFC Part

 


prevText      Top      Up      ToC       Page 44 
4.5.  Refreshing an Access Token

4.5.1.  Threat: Eavesdropping Refresh Tokens from Authorization Server

   An attacker may eavesdrop refresh tokens when they are transmitted
   from the authorization server to the client.

   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 (see Section 5.1.5.3) for
      issued access tokens can be used to reduce the damage in case of
      leaks.

4.5.2.  Threat: Obtaining Refresh Token from Authorization Server
        Database

   This threat is applicable if the authorization server stores refresh
   tokens as handles in a database.  An attacker may obtain refresh
   tokens from the authorization server's database by gaining access to
   the database or launching a SQL injection attack.

Top      Up      ToC       Page 45 
   Impact: Disclosure of all refresh tokens.

   Countermeasures:

   o  Enforce credential storage protection best practices
      (Section 5.1.4.1).

   o  Bind token to client id, if the attacker cannot obtain the
      required id and secret (Section 5.1.5.8).

4.5.3.  Threat: Obtaining Refresh Token by Online Guessing

   An attacker may try to guess valid refresh token values and send it
   using the grant type "refresh_token" in order to obtain a valid
   access token.

   Impact: Exposure of a single refresh token and derivable access
   tokens.

   Countermeasures:

   o  For handle-based designs (Section 5.1.4.2.2).

   o  For assertion-based designs (Section 5.1.5.9).

   o  Bind token to client id, because the attacker would guess the
      matching client id, too (see Section 5.1.5.8).

   o  Authenticate the client; this adds another element that the
      attacker has to guess (see Section 5.2.3.4).

4.5.4.  Threat: Refresh Token Phishing by Counterfeit Authorization
        Server

   An attacker could try to obtain valid refresh tokens by proxying
   requests to the authorization server.  Given the assumption that the
   authorization server URL is well-known at development time or can at
   least be obtained from a well-known resource server, the attacker
   must utilize some kind of spoofing in order to succeed.

   Countermeasures:

   o  Utilize server authentication (as described in Section 5.1.2).

Top      Up      ToC       Page 46 
4.6.  Accessing Protected Resources

4.6.1.  Threat: Eavesdropping Access Tokens on Transport

   An attacker could try to obtain a valid access token on transport
   between the client and resource server.  As access tokens are shared
   secrets between the authorization server and resource server, they
   should be treated with the same care as other credentials (e.g., end-
   user passwords).

   Countermeasures:

   o  Access tokens sent as bearer tokens should not be sent in the
      clear over an insecure channel.  As per the core OAuth spec,
      transmission of access tokens must be protected using transport-
      layer mechanisms such as TLS (see Section 5.1.1).

   o  A short lifetime reduces impact in case tokens are compromised
      (see Section 5.1.5.3).

   o  The access token can be bound to a client's identifier and require
      the client to prove legitimate ownership of the token to the
      resource server (see Section 5.4.2).

4.6.2.  Threat: Replay of Authorized Resource Server Requests

   An attacker could attempt to replay valid requests in order to obtain
   or to modify/destroy user data.

   Countermeasures:

   o  The resource server should utilize transport security measures
      (e.g., TLS) in order to prevent such attacks (see Section 5.1.1).
      This would prevent the attacker from capturing valid requests.

   o  Alternatively, the resource server could employ signed requests
      (see Section 5.4.3) along with nonces and timestamps in order to
      uniquely identify requests.  The resource server should detect and
      refuse every replayed request.

4.6.3.  Threat: Guessing Access Tokens

   Where the token is a handle, the attacker may attempt to guess the
   access token values based on knowledge they have from other access
   tokens.

   Impact: Access to a single user's data.

Top      Up      ToC       Page 47 
   Countermeasures:

   o  Handle tokens should have a reasonable level of entropy (see
      Section 5.1.4.2.2) in order to make guessing a valid token value
      infeasible.

   o  Assertion (or self-contained token) token contents should be
      protected by a digital signature (see Section 5.1.5.9).

   o  Security can be further strengthened by using a short access token
      duration (see Sections 5.1.5.2 and 5.1.5.3).

4.6.4.  Threat: Access Token Phishing by Counterfeit Resource Server

   An attacker may pretend to be a particular resource server and to
   accept tokens from a particular authorization server.  If the client
   sends a valid access token to this counterfeit resource server, the
   server in turn may use that token to access other services on behalf
   of the resource owner.

   Countermeasures:

   o  Clients should not make authenticated requests with an access
      token to unfamiliar resource servers, regardless of the presence
      of a secure channel.  If the resource server URL is well-known to
      the client, it may authenticate the resource servers (see
      Section 5.1.2).

   o  Associate the endpoint URL of the resource server the client
      talked to with the access token (e.g., in an audience field) and
      validate the association at a legitimate resource server.  The
      endpoint URL validation policy may be strict (exact match) or more
      relaxed (e.g., same host).  This would require telling the
      authorization server about the resource server endpoint URL in the
      authorization process.

   o  Associate an access token with a client and authenticate the
      client with resource server requests (typically via a signature,
      in order to not disclose a secret to a potential attacker).  This
      prevents the attack because the counterfeit server is assumed to
      lack the capability to correctly authenticate on behalf of the
      legitimate client to the resource server (Section 5.4.2).

   o  Restrict the token scope (see Section 5.1.5.1) and/or limit the
      token to a certain resource server (Section 5.1.5.5).

Top      Up      ToC       Page 48 
4.6.5.  Threat: Abuse of Token by Legitimate Resource Server or Client

   A legitimate resource server could attempt to use an access token to
   access another resource server.  Similarly, a client could try to use
   a token obtained for one server on another resource server.

   Countermeasures:

   o  Tokens should be restricted to particular resource servers (see
      Section 5.1.5.5).

4.6.6.  Threat: Leak of Confidential Data in HTTP Proxies

   An OAuth HTTP authentication scheme as discussed in [RFC6749] is
   optional.  However, [RFC2616] relies on the Authorization and
   WWW-Authenticate headers to distinguish authenticated content so that
   it can be protected.  Proxies and caches, in particular, may fail to
   adequately protect requests not using these headers.  For example,
   private authenticated content may be stored in (and thus be
   retrievable from) publicly accessible caches.

   Countermeasures:

   o  Clients and resource servers not using an OAuth HTTP
      authentication scheme (see Section 5.4.1) should take care to use
      Cache-Control headers to minimize the risk that authenticated
      content is not protected.  Such clients should send a
      Cache-Control header containing the "no-store" option [RFC2616].
      Resource server success (2XX status) responses to these requests
      should contain a Cache-Control header with the "private" option
      [RFC2616].

   o  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.6.7.  Threat: Token Leakage via Log Files and HTTP Referrers

   If access tokens are sent via URI query parameters, such tokens may
   leak to log files and the HTTP "referer".

   Countermeasures:

   o  Use Authorization headers or POST parameters instead of URI
      request parameters (see Section 5.4.1).

   o  Set logging configuration appropriately.

Top      Up      ToC       Page 49 
   o  Prevent unauthorized persons from access to system log files (see
      Section 5.1.4.1.1).

   o  Abuse of leaked access tokens can be prevented by enforcing
      authenticated requests (see Section 5.4.2).

   o  The impact of token leakage may be reduced by limiting scope (see
      Section 5.1.5.1) and duration (see Section 5.1.5.3) and by
      enforcing one-time token usage (see Section 5.1.5.4).

5.  Security Considerations

   This section describes the countermeasures as recommended to mitigate
   the threats described in Section 4.

5.1.  General

   This section covers considerations that apply generally across all
   OAuth components (client, resource server, token server, and user
   agents).

5.1.1.  Ensure Confidentiality of Requests

   This is applicable to all requests sent from the client to the
   authorization server or resource server.  While OAuth provides a
   mechanism for verifying the integrity of requests, it provides no
   guarantee of request confidentiality.  Unless further precautions are
   taken, eavesdroppers will have full access to request content and may
   be able to mount interception or replay attacks by using the contents
   of requests, e.g., secrets or tokens.

   Attacks can be mitigated by using transport-layer mechanisms such as
   TLS [RFC5246].  A virtual private network (VPN), e.g., based on IPsec
   VPNs [RFC4301], may be considered as well.

   Note: This document assumes end-to-end TLS protected connections
   between the respective protocol entities.  Deployments deviating from
   this assumption by offloading TLS in between (e.g., on the data
   center edge) must refine this threat model in order to account for
   the additional (mainly insider) threat this may cause.

   This is a countermeasure against the following threats:

   o  Replay of access tokens obtained on the token's endpoint or the
      resource server's endpoint

   o  Replay of refresh tokens obtained on the token's endpoint

Top      Up      ToC       Page 50 
   o  Replay of authorization "codes" obtained on the token's endpoint
      (redirect?)

   o  Replay of user passwords and client secrets

5.1.2.  Utilize Server Authentication

   HTTPS server authentication or similar means can be used to
   authenticate the identity of a server.  The goal is to reliably bind
   the fully qualified domain name of the server to the public key
   presented by the server during connection establishment (see
   [RFC2818]).

   The client should validate the binding of the server to its domain
   name.  If the server fails to prove that binding, the communication
   is considered a man-in-the-middle attack.  This security measure
   depends on the certification authorities the client trusts for that
   purpose.  Clients should carefully select those trusted CAs and
   protect the storage for trusted CA certificates from modifications.

   This is a countermeasure against the following threats:

   o  Spoofing

   o  Proxying

   o  Phishing by counterfeit servers

5.1.3.  Always Keep the Resource Owner Informed

   Transparency to the resource owner is a key element of the OAuth
   protocol.  The user should always be in control of the authorization
   processes and get the necessary information to make informed
   decisions.  Moreover, user involvement is a further security
   countermeasure.  The user can probably recognize certain kinds of
   attacks better than the authorization server.  Information can be
   presented/exchanged during the authorization process, after the
   authorization process, and every time the user wishes to get informed
   by using techniques such as:

   o  User consent forms.

   o  Notification messages (e.g., email, SMS, ...).  Note that
      notifications can be a phishing vector.  Messages should be such
      that look-alike phishing messages cannot be derived from them.

Top      Up      ToC       Page 51 
   o  Activity/event logs.

   o  User self-care applications or portals.

5.1.4.  Credentials

   This section describes countermeasures used to protect all kinds of
   credentials from unauthorized access and abuse.  Credentials are
   long-term secrets, such as client secrets and user passwords as well
   as all kinds of tokens (refresh and access tokens) or authorization
   "codes".

5.1.4.1.  Enforce Credential Storage Protection Best Practices

   Administrators should undertake industry best practices to protect
   the storage of credentials (for example, see [OWASP]).  Such
   practices may include but are not limited to the following
   sub-sections.

5.1.4.1.1.  Enforce Standard System Security Means

   A server system may be locked down so that no attacker may get access
   to sensitive configuration files and databases.

5.1.4.1.2.  Enforce Standard SQL Injection Countermeasures

   If a client identifier or other authentication component is queried
   or compared against a SQL database, it may become possible for an
   injection attack to occur if parameters received are not validated
   before submission to the database.

   o  Ensure that server code is using the minimum database privileges
      possible to reduce the "surface" of possible attacks.

   o  Avoid dynamic SQL using concatenated input.  If possible, use
      static SQL.

   o  When using dynamic SQL, parameterize queries using bind arguments.
      Bind arguments eliminate the possibility of SQL injections.

   o  Filter and sanitize the input.  For example, if an identifier has
      a known format, ensure that the supplied value matches the
      identifier syntax rules.

Top      Up      ToC       Page 52 
5.1.4.1.3.  No Cleartext Storage of Credentials

   The authorization server should not store credentials in clear text.
   Typical approaches are to store hashes instead or to encrypt
   credentials.  If the credential lacks a reasonable entropy level
   (because it is a user password), an additional salt will harden the
   storage to make offline dictionary attacks more difficult.

   Note: Some authentication protocols require the authorization server
   to have access to the secret in the clear.  Those protocols cannot be
   implemented if the server only has access to hashes.  Credentials
   should be strongly encrypted in those cases.

5.1.4.1.4.  Encryption of Credentials

   For client applications, insecurely persisted client credentials are
   easy targets for attackers to obtain.  Store client credentials using
   an encrypted persistence mechanism such as a keystore or database.
   Note that compiling client credentials directly into client code
   makes client applications vulnerable to scanning as well as difficult
   to administer should client credentials change over time.

5.1.4.1.5.  Use of Asymmetric Cryptography

   Usage of asymmetric cryptography will free the authorization server
   of the obligation to manage credentials.

5.1.4.2.  Online Attacks on Secrets

5.1.4.2.1.  Utilize Secure Password Policy

   The authorization server may decide to enforce a complex user
   password policy in order to increase the user passwords' entropy to
   hinder online password attacks.  Note that too much complexity can
   increase the likelihood that users re-use passwords or write them
   down, or otherwise store them insecurely.

5.1.4.2.2.  Use High Entropy for Secrets

   When creating secrets not intended for usage by human users (e.g.,
   client secrets or token handles), the authorization server should
   include a reasonable level of entropy in order to mitigate the risk
   of guessing attacks.  The token value should be >=128 bits long and
   constructed from a cryptographically strong random or pseudo-random
   number sequence (see [RFC4086] for best current practice) generated
   by the authorization server.

Top      Up      ToC       Page 53 
5.1.4.2.3.  Lock Accounts

   Online attacks on passwords can be mitigated by locking the
   respective accounts after a certain number of failed attempts.

   Note: This measure can be abused to lock down legitimate service
   users.

5.1.4.2.4.  Use Tar Pit

   The authorization server may react on failed attempts to authenticate
   by username/password by temporarily locking the respective account
   and delaying the response for a certain duration.  This duration may
   increase with the number of failed attempts.  The objective is to
   slow the attacker's attempts on a certain username down.

   Note: This may require a more complex and stateful design of the
   authorization server.

5.1.4.2.5.  Use CAPTCHAs

   The idea is to prevent programs from automatically checking a huge
   number of passwords, by requiring human interaction.

   Note: This has a negative impact on user experience.

5.1.5.  Tokens (Access, Refresh, Code)

5.1.5.1.  Limit Token Scope

   The authorization server may decide to reduce or limit the scope
   associated with a token.  The basis of this decision is out of scope;
   examples are:

   o  a client-specific policy, e.g., issue only less powerful tokens to
      public clients,

   o  a service-specific policy, e.g., it is a very sensitive service,

   o  a resource-owner-specific setting, or

   o  combinations of such policies and preferences.

Top      Up      ToC       Page 54 
   The authorization server may allow different scopes dependent on the
   grant type.  For example, end-user authorization via direct
   interaction with the end user (authorization "code") might be
   considered more reliable than direct authorization via grant type
   "username"/"password".  This means will reduce the impact of the
   following threats:

   o  token leakage

   o  token issuance to malicious software

   o  unintended issuance of powerful tokens with resource owner
      credentials flow

5.1.5.2.  Determine Expiration Time

   Tokens should generally expire after a reasonable duration.  This
   complements and strengthens other security measures (such as
   signatures) and reduces the impact of all kinds of token leaks.
   Depending on the risk associated with token leakage, tokens may
   expire after a few minutes (e.g., for payment transactions) or stay
   valid for hours (e.g., read access to contacts).

   The expiration time is determined by several factors, including:

   o  risk associated with token leakage,

   o  duration of the underlying access grant,

   o  duration until the modification of an access grant should take
      effect, and

   o  time required for an attacker to guess or produce a valid token.

5.1.5.3.  Use Short Expiration Time

   A short expiration time for tokens is a means of protection against
   the following threats:

   o  replay

   o  token leak (a short expiration time will reduce impact)

   o  online guessing (a short expiration time will reduce the
      likelihood of success)

Top      Up      ToC       Page 55 
   Note: Short token duration requires more precise clock
   synchronization between the authorization server and resource server.
   Furthermore, shorter duration may require more token refreshes
   (access token) or repeated end-user authorization processes
   (authorization "code" and refresh token).

5.1.5.4.  Limit Number of Usages or One-Time Usage

   The authorization server may restrict the number of requests or
   operations that can be performed with a certain token.  This
   mechanism can be used to mitigate the following threats:

   o  replay of tokens

   o  guessing

   For example, if an authorization server observes more than one
   attempt to redeem an authorization "code", the authorization server
   may want to revoke all access tokens granted based on the
   authorization "code" as well as reject the current request.

   As with the authorization "code", access tokens may also have a
   limited number of operations.  This either forces client applications
   to re-authenticate and use a refresh token to obtain a fresh access
   token, or forces the client to re-authorize the access token by
   involving the user.

5.1.5.5.  Bind Tokens to a Particular Resource Server (Audience)

   Authorization servers in multi-service environments may consider
   issuing tokens with different content to different resource servers
   and to explicitly indicate in the token the target server to which a
   token is intended to be sent.  SAML assertions (see
   [OASIS.saml-core-2.0-os]) use the Audience element for this purpose.
   This countermeasure can be used in the following situations:

   o  It reduces the impact of a successful replay attempt, since the
      token is applicable to a single resource server only.

   o  It prevents abuse of a token by a rogue resource server or client,
      since the token can only be used on that server.  It is rejected
      by other servers.

   o  It reduces the impact of leakage of a valid token to a counterfeit
      resource server.

Top      Up      ToC       Page 56 
5.1.5.6.  Use Endpoint Address as Token Audience

   This may be used to indicate to a resource server which endpoint URL
   has been used to obtain the token.  This measure will allow the
   detection of requests from a counterfeit resource server, since such
   a token will contain the endpoint URL of that server.

5.1.5.7.  Use Explicitly Defined Scopes for Audience and Tokens

   Deployments may consider only using tokens with explicitly defined
   scopes, where every scope is associated with a particular resource
   server.  This approach can be used to mitigate attacks where a
   resource server or client uses a token for a different purpose than
   the one intended.

5.1.5.8.  Bind Token to Client id

   An authorization server may bind a token to a certain client
   identifier.  This identifier should be validated for every request
   with that token.  This technique can be used to

   o  detect token leakage and

   o  prevent token abuse.

   Note: Validating the client identifier may require the target server
   to authenticate the client's identifier.  This authentication can be
   based on secrets managed independently of the token (e.g.,
   pre-registered client id/secret on authorization server) or sent with
   the token itself (e.g., as part of the encrypted token content).

5.1.5.9.  Sign Self-Contained Tokens

   Self-contained tokens should be signed in order to detect any attempt
   to modify or produce faked tokens (e.g., Hash-based Message
   Authentication Code or digital signatures).

5.1.5.10.  Encrypt Token Content

   Self-contained tokens may be encrypted for confidentiality reasons or
   to protect system internal data.  Depending on token format, keys
   (e.g., symmetric keys) may have to be distributed between server
   nodes.  The method of distribution should be defined by the token and
   the encryption used.

Top      Up      ToC       Page 57 
5.1.5.11.  Adopt a Standard Assertion Format

   For service providers intending to implement an assertion-based token
   design, it is highly recommended to adopt a standard assertion format
   (such as SAML [OASIS.saml-core-2.0-os] or the JavaScript Object
   Notation Web Token (JWT) [OAuth-JWT]).

5.1.6.  Access Tokens

   The following measures should be used to protect access tokens:

   o  Keep them in transient memory (accessible by the client
      application only).

   o  Pass tokens securely using secure transport (TLS).

   o  Ensure that client applications do not share tokens with 3rd
      parties.

5.2.  Authorization Server

   This section describes considerations related to the OAuth
   authorization server endpoint.

5.2.1.  Authorization "codes"

5.2.1.1.  Automatic Revocation of Derived Tokens If Abuse Is Detected

   If an authorization server observes multiple attempts to redeem an
   authorization grant (e.g., such as an authorization "code"), the
   authorization server may want to revoke all tokens granted based on
   the authorization grant.

5.2.2.  Refresh Tokens

5.2.2.1.  Restricted Issuance of Refresh Tokens

   The authorization server may decide, based on an appropriate policy,
   not to issue refresh tokens.  Since refresh tokens are long-term
   credentials, they may be subject to theft.  For example, if the
   authorization server does not trust a client to securely store such
   tokens, it may refuse to issue such a client a refresh token.

Top      Up      ToC       Page 58 
5.2.2.2.  Binding of Refresh Token to "client_id"

   The authorization server should match every refresh token to the
   identifier of the client to whom it was issued.  The authorization
   server should check that the same "client_id" is present for every
   request to refresh the access token.  If possible (e.g., confidential
   clients), the authorization server should authenticate the respective
   client.

   This is a countermeasure against refresh token theft or leakage.

   Note: This binding should be protected from unauthorized
   modifications.

5.2.2.3.  Refresh Token Rotation

   Refresh token rotation is intended to automatically detect and
   prevent attempts to use the same refresh token in parallel from
   different apps/devices.  This happens if a token gets stolen from the
   client and is subsequently used by both the attacker and the
   legitimate client.  The basic idea is to change the refresh token
   value with every refresh request in order to detect attempts to
   obtain access tokens using old refresh tokens.  Since the
   authorization server cannot determine whether the attacker or the
   legitimate client is trying to access, in case of such an access
   attempt the valid refresh token and the access authorization
   associated with it are both revoked.

   The OAuth specification supports this measure in that the token's
   response allows the authorization server to return a new refresh
   token even for requests with grant type "refresh_token".

   Note: This measure may cause problems in clustered environments,
   since usage of the currently valid refresh token must be ensured.  In
   such an environment, other measures might be more appropriate.

5.2.2.4.  Revocation of Refresh Tokens

   The authorization server may allow clients or end users to explicitly
   request the invalidation of refresh tokens.  A mechanism to revoke
   tokens is specified in [OAuth-REVOCATION].

Top      Up      ToC       Page 59 
   This is a countermeasure against:

   o  device theft,

   o  impersonation of a resource owner, or

   o  suspected compromised client applications.

5.2.2.5.  Device Identification

   The authorization server may require the binding of authentication
   credentials to a device identifier.  The International Mobile Station
   Equipment Identity [IMEI] is one example of such an identifier; there
   are also operating system-specific identifiers.  The authorization
   server could include such an identifier when authenticating user
   credentials in order to detect token theft from a particular device.

   Note: Any implementation should consider potential privacy
   implications of using device identifiers.

5.2.2.6.  X-FRAME-OPTIONS Header

   For newer browsers, avoidance of iFrames can be enforced on the
   server side by using the X-FRAME-OPTIONS header (see
   [X-Frame-Options]).  This header can have two values, "DENY" and
   "SAMEORIGIN", which will block any framing or any framing by sites
   with a different origin, respectively.  The value "ALLOW-FROM"
   specifies a list of trusted origins that iFrames may originate from.

   This is a countermeasure against the following threat:

   o  Clickjacking attacks

5.2.3.  Client Authentication and Authorization

   As described in Section 3 (Security Features), clients are
   identified, authenticated, and authorized for several purposes, such
   as to:

   o  Collate requests to the same client,

   o  Indicate to the user that the client is recognized by the
      authorization server,

   o  Authorize access of clients to certain features on the
      authorization server or resource server, and

   o  Log a client identifier to log files for analysis or statistics.

Top      Up      ToC       Page 60 
   Due to the different capabilities and characteristics of the
   different client types, there are different ways to support these
   objectives, which will be described in this section.  Authorization
   server providers should be aware of the security policy and
   deployment of a particular client and adapt its treatment
   accordingly.  For example, one approach could be to treat all clients
   as less trustworthy and unsecure.  On the other extreme, a service
   provider could activate every client installation individually by an
   administrator and in that way gain confidence in the identity of the
   software package and the security of the environment in which the
   client is installed.  There are several approaches in between.

5.2.3.1.  Don't Issue Secrets to Clients with Inappropriate Security
          Policy

   Authorization servers should not issue secrets to clients that cannot
   protect secrets ("public" clients).  This reduces the probability of
   the server treating the client as strongly authenticated.

   For example, it is of limited benefit to create a single client id
   and secret that are shared by all installations of a native
   application.  Such a scenario requires that this secret must be
   transmitted from the developer via the respective distribution
   channel, e.g., an application market, to all installations of the
   application on end-user devices.  A secret, burned into the source
   code of the application or an associated resource bundle, is not
   protected from reverse engineering.  Secondly, such secrets cannot be
   revoked, since this would immediately put all installations out of
   work.  Moreover, since the authorization server cannot really trust
   the client's identifier, it would be dangerous to indicate to end
   users the trustworthiness of the client.

   There are other ways to achieve a reasonable security level, as
   described in the following sections.

5.2.3.2.  Require User Consent for Public Clients without Secret

   Authorization servers should not allow automatic authorization for
   public clients.  The authorization server may issue an individual
   client id but should require that all authorizations are approved by
   the end user.  For clients without secrets, this is a countermeasure
   against the following threat:

   o  Impersonation of public client applications.

Top      Up      ToC       Page 61 
5.2.3.3.  Issue a "client_id" Only in Combination with "redirect_uri"

   The authorization server may issue a "client_id" and bind the
   "client_id" to a certain pre-configured "redirect_uri".  Any
   authorization request with another redirect URI is refused
   automatically.  Alternatively, the authorization server should not
   accept any dynamic redirect URI for such a "client_id" and instead
   should always redirect to the well-known pre-configured redirect URI.
   This is a countermeasure for clients without secrets against the
   following threats:

   o  Cross-site scripting attacks

   o  Impersonation of public client applications

5.2.3.4.  Issue Installation-Specific Client Secrets

   An authorization server may issue separate client identifiers and
   corresponding secrets to the different installations of a particular
   client (i.e., software package).  The effect of such an approach
   would be to turn otherwise "public" clients back into "confidential"
   clients.

   For web applications, this could mean creating one "client_id" and
   "client_secret" for each web site on which a software package is
   installed.  So, the provider of that particular site could request a
   client id and secret from the authorization server during the setup
   of the web site.  This would also allow the validation of some of the
   properties of that web site, such as redirect URI, web site URL, and
   whatever else proves useful.  The web site provider has to ensure the
   security of the client secret on the site.

   For native applications, things are more complicated because every
   copy of a particular application on any device is a different
   installation.  Installation-specific secrets in this scenario will
   require obtaining a "client_id" and "client_secret" either

   1.  during the download process from the application market, or

   2.  during installation on the device.

   Either approach will require an automated mechanism for issuing
   client ids and secrets, which is currently not defined by OAuth.

   The first approach would allow the achievement of a certain level of
   trust in the authenticity of the application, whereas the second
   option only allows the authentication of the installation but not the
   validation of properties of the client.  But this would at least help

Top      Up      ToC       Page 62 
   to prevent several replay attacks.  Moreover, installation-specific
   "client_ids" and secrets allow the selective revocation of all
   refresh tokens of a specific installation at once.

5.2.3.5.  Validate Pre-Registered "redirect_uri"

   An authorization server should require all clients to register their
   "redirect_uri", and the "redirect_uri" should be the full URI as
   defined in [RFC6749].  The way that this registration is performed is
   out of scope of this document.  As per the core spec, every actual
   redirect URI sent with the respective "client_id" to the end-user
   authorization endpoint must match the registered redirect URI.  Where
   it does not match, the authorization server should assume that the
   inbound GET request has been sent by an attacker and refuse it.
   Note: The authorization server should not redirect the user agent
   back to the redirect URI of such an authorization request.
   Validating the pre-registered "redirect_uri" is a countermeasure
   against the following threats:

   o  Authorization "code" leakage through counterfeit web site: allows
      authorization servers to detect attack attempts after the first
      redirect to an end-user authorization endpoint (Section 4.4.1.7).

   o  Open redirector attack via a client redirection endpoint
      (Section 4.1.5).

   o  Open redirector phishing attack via an authorization server
      redirection endpoint (Section 4.2.4).

   The underlying assumption of this measure is that an attacker will
   need to use another redirect URI in order to get access to the
   authorization "code".  Deployments might consider the possibility of
   an attacker using spoofing attacks to a victim's device to circumvent
   this security measure.

   Note: Pre-registering clients might not scale in some deployments
   (manual process) or require dynamic client registration (not
   specified yet).  With the lack of dynamic client registration, a
   pre-registered "redirect_uri" only works for clients bound to certain
   deployments at development/configuration time.  As soon as dynamic
   resource server discovery is required, the pre-registered
   "redirect_uri" may no longer be feasible.

Top      Up      ToC       Page 63 
5.2.3.6.  Revoke Client Secrets

   An authorization server may revoke a client's secret in order to
   prevent abuse of a revealed secret.

   Note: This measure will immediately invalidate any authorization
   "code" or refresh token issued to the respective client.  This might
   unintentionally impact client identifiers and secrets used across
   multiple deployments of a particular native or web application.

   This a countermeasure against:

   o  Abuse of revealed client secrets for private clients

5.2.3.7.  Use Strong Client Authentication (e.g., client_assertion/
          client_token)

   By using an alternative form of authentication such as client
   assertion [OAuth-ASSERTIONS], the need to distribute a
   "client_secret" is eliminated.  This may require the use of a secure
   private key store or other supplemental authentication system as
   specified by the client assertion issuer in its authentication
   process.

5.2.4.  End-User Authorization

   This section includes considerations for authorization flows
   involving the end user.

5.2.4.1.  Automatic Processing of Repeated Authorizations Requires
          Client Validation

   Authorization servers should NOT automatically process repeat
   authorizations where the client is not authenticated through a client
   secret or some other authentication mechanism such as a signed
   authentication assertion certificate (Section 5.2.3.7) or validation
   of a pre-registered redirect URI (Section 5.2.3.5).

5.2.4.2.  Informed Decisions Based on Transparency

   The authorization server should clearly explain to the end user what
   happens in the authorization process and what the consequences are.
   For example, the user should understand what access he is about to
   grant to which client for what duration.  It should also be obvious
   to the user whether the server is able to reliably certify certain
   client properties (web site URL, security policy).

Top      Up      ToC       Page 64 
5.2.4.3.  Validation of Client Properties by End User

   In the authorization process, the user is typically asked to approve
   a client's request for authorization.  This is an important security
   mechanism by itself because the end user can be involved in the
   validation of client properties, such as whether the client name
   known to the authorization server fits the name of the web site or
   the application the end user is using.  This measure is especially
   helpful in situations where the authorization server is unable to
   authenticate the client.  It is a countermeasure against:

   o  A malicious application

   o  A client application masquerading as another client

5.2.4.4.  Binding of Authorization "code" to "client_id"

   The authorization server should bind every authorization "code" to
   the id of the respective client that initiated the end-user
   authorization process.  This measure is a countermeasure against:

   o  Replay of authorization "codes" with different client credentials,
      since an attacker cannot use another "client_id" to exchange an
      authorization "code" into a token

   o  Online guessing of authorization "codes"

   Note: This binding should be protected from unauthorized
   modifications (e.g., using protected memory and/or a secure
   database).

5.2.4.5.  Binding of Authorization "code" to "redirect_uri"

   The authorization server should be able to bind every authorization
   "code" to the actual redirect URI used as the redirect target of the
   client in the end-user authorization process.  This binding should be
   validated when the client attempts to exchange the respective
   authorization "code" for an access token.  This measure is a
   countermeasure against authorization "code" leakage through
   counterfeit web sites, since an attacker cannot use another redirect
   URI to exchange an authorization "code" into a token.

Top      Up      ToC       Page 65 
5.3.  Client App Security

   This section deals with considerations for client applications.

5.3.1.  Don't Store Credentials in Code or Resources Bundled with
        Software Packages

   Because of the number of copies of client software, there is limited
   benefit in creating a single client id and secret that is shared by
   all installations of an application.  Such an application by itself
   would be considered a "public" client, as it cannot be presumed to be
   able to keep client secrets.  A secret, burned into the source code
   of the application or an associated resource bundle, cannot be
   protected from reverse engineering.  Secondly, such secrets cannot be
   revoked, since this would immediately put all installations out of
   work.  Moreover, since the authorization server cannot really trust
   the client's identifier, it would be dangerous to indicate to end
   users the trustworthiness of the client.

5.3.2.  Use Standard Web Server Protection Measures (for Config Files
        and Databases)

   Use standard web server protection and configuration measures to
   protect the integrity of the server, databases, configuration files,
   and other operational components of the server.

5.3.3.  Store Secrets in Secure Storage

   There are different ways to store secrets of all kinds (tokens,
   client secrets) securely on a device or server.

   Most multi-user operating systems segregate the personal storage of
   different system users.  Moreover, most modern smartphone operating
   systems even support the storage of application-specific data in
   separate areas of file systems and protect the data from access by
   other applications.  Additionally, applications can implement
   confidential data by using a user-supplied secret, such as a PIN or
   password.

   Another option is to swap refresh token storage to a trusted backend
   server.  This option in turn requires a resilient authentication
   mechanism between the client and backend server.  Note: Applications
   should ensure that confidential data is kept confidential even after
   reading from secure storage, which typically means keeping this data
   in the local memory of the application.

Top      Up      ToC       Page 66 
5.3.4.  Utilize Device Lock to Prevent Unauthorized Device Access

   On a typical modern phone, there are many "device lock" options that
   can be utilized to provide additional protection when a device is
   stolen or misplaced.  These include PINs, passwords, and other
   biometric features such as "face recognition".  These are not equal
   in the level of security they provide.

5.3.5.  Link the "state" Parameter to User Agent Session

   The "state" parameter is used to link client requests and prevent
   CSRF attacks, for example, attacks against the redirect URI.  An
   attacker could inject their own authorization "code" or access token,
   which can result in the client using an access token associated with
   the attacker's protected resources rather than the victim's (e.g.,
   save the victim's bank account information to a protected resource
   controlled by the attacker).

   The client should utilize the "state" request parameter to send the
   authorization server a value that binds the request to the user
   agent's authenticated state (e.g., a hash of the session cookie used
   to authenticate the user agent) when making an authorization request.
   Once authorization has been obtained from the end user, the
   authorization server redirects the end-user's user agent back to the
   client with the required binding value contained in the "state"
   parameter.

   The binding value enables the client to verify the validity of the
   request by matching the binding value to the user agent's
   authenticated state.

5.4.  Resource Servers

   The following section details security considerations for resource
   servers.

5.4.1.  Authorization Headers

   Authorization headers are recognized and specially treated by HTTP
   proxies and servers.  Thus, the usage of such headers for sending
   access tokens to resource servers reduces the likelihood of leakage
   or unintended storage of authenticated requests in general, and
   especially Authorization headers.

Top      Up      ToC       Page 67 
5.4.2.  Authenticated Requests

   An authorization server may bind tokens to a certain client
   identifier and enable resource servers to validate that association
   on resource access.  This will require the resource server to
   authenticate the originator of a request as the legitimate owner of a
   particular token.  There are several options to implement this
   countermeasure:

   o  The authorization server may associate the client identifier with
      the token (either internally or in the payload of a self-contained
      token).  The client then uses client certificate-based HTTP
      authentication on the resource server's endpoint to authenticate
      its identity, and the resource server validates the name with the
      name referenced by the token.

   o  Same as the option above, but the client uses his private key to
      sign the request to the resource server (the public key is either
      contained in the token or sent along with the request).

   o  Alternatively, the authorization server may issue a token-bound
      key, which the client uses in a Holder-of-Key proof to
      authenticate the client's use of the token.  The resource server
      obtains the secret directly from the authorization server, or the
      secret is contained in an encrypted section of the token.  In that
      way, the resource server does not "know" the client but is able to
      validate whether the authorization server issued the token to that
      client.

   Authenticated requests are a countermeasure against abuse of tokens
   by counterfeit resource servers.

5.4.3.  Signed Requests

   A resource server may decide to accept signed requests only, either
   to replace transport-level security measures or to complement such
   measures.  Every signed request should be uniquely identifiable and
   should not be processed twice by the resource server.  This
   countermeasure helps to mitigate:

   o  modifications of the message and

   o  replay attempts

Top      Up      ToC       Page 68 
5.5.  A Word on User Interaction and User-Installed Apps

   OAuth, as a security protocol, is distinctive in that its flow
   usually involves significant user interaction, making the end user a
   part of the security model.  This creates some important difficulties
   in defending against some of the threats discussed above.  Some of
   these points have already been made, but it's worth repeating and
   highlighting them here.

   o  End users must understand what they are being asked to approve
      (see Section 5.2.4.2).  Users often do not have the expertise to
      understand the ramifications of saying "yes" to an authorization
      request and are likely not to be able to see subtle differences in
      the wording of requests.  Malicious software can confuse the user,
      tricking the user into approving almost anything.

   o  End-user devices are prone to software compromise.  This has been
      a long-standing problem, with frequent attacks on web browsers and
      other parts of the user's system.  But with the increasing
      popularity of user-installed "apps", the threat posed by
      compromised or malicious end-user software is very strong and is
      one that is very difficult to mitigate.

   o  Be aware that users will demand to install and run such apps, and
      that compromised or malicious ones can steal credentials at many
      points in the data flow.  They can intercept the very user login
      credentials that OAuth is designed to protect.  They can request
      authorization far beyond what they have led the user to understand
      and approve.  They can automate a response on behalf of the user,
      hiding the whole process.  No solution is offered here, because
      none is known; this remains in the space between better security
      and better usability.

   o  Addressing these issues by restricting the use of user-installed
      software may be practical in some limited environments and can be
      used as a countermeasure in those cases.  Such restrictions are
      not practical in the general case, and mechanisms for after-the-
      fact recovery should be in place.

   o  While end users are mostly incapable of properly vetting
      applications they load onto their devices, those who deploy
      authorization servers might have tools at their disposal to
      mitigate malicious clients.  For example, a well-run authorization
      server must only assert client properties to the end user it is
      effectively capable of validating, explicitly point out which
      properties it cannot validate, and indicate to the end user the
      risk associated with granting access to the particular client.

Top      Up      ToC       Page 69 
6.  Acknowledgements

   We would like to thank Stephen Farrell, Barry Leiba, Hui-Lan Lu,
   Francisco Corella, Peifung E. Lam, Shane B. Weeden, Skylar Woodward,
   Niv Steingarten, Tim Bray, and James H. Manger for their comments and
   contributions.

7.  References

7.1.  Normative References

   [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework",
              RFC 6749, October 2012.

   [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
              Framework: Bearer Token Usage", RFC 6750, October 2012.

7.2.  Informative References

   [Framebusting]
              Rydstedt, G., Bursztein, Boneh, D., and C. Jackson,
              "Busting Frame Busting: a Study of Clickjacking
              Vulnerabilities on Popular Sites", IEEE 3rd Web 2.0
              Security and Privacy Workshop, May 2010, <http://elie.im/
              publication/busting-frame-busting-a-study-of-
              clickjacking-vulnerabilities-on-popular-sites>.

   [IMEI]     3GPP, "International Mobile station Equipment Identities
              (IMEI)", 3GPP TS 22.016 11.0.0, September 2012,
              <http://www.3gpp.org/ftp/Specs/html-info/22016.htm>.

   [OASIS.saml-core-2.0-os]
              Cantor, S., Ed., Kemp, J., Ed., Philpott, R., Ed., and E.
              Maler, Ed., "Assertions and Protocols for the OASIS
              Security Assertion Markup Language (SAML) V2.0", OASIS
              Standard saml-core-2.0-os, March 2005,
              <http://docs.oasis-open.org/security/saml/
              v2.0/saml-core-2.0-os.pdf>.

   [OASIS.sstc-saml-bindings-1.1]
              Maler, E., Ed., Mishra, P., Ed., and R. Philpott, Ed.,
              "Bindings and Profiles for the OASIS Security Assertion
              Markup Language (SAML) V1.1", September 2003,
              <http://www.oasis-open.org/committees/download.php/3405/
              oasis-sstc-saml-bindings-1.1.pdf>.

Top      Up      ToC       Page 70 
   [OASIS.sstc-sec-analysis-response-01]
              Linn, J., Ed., and P. Mishra, Ed., "SSTC Response to
              "Security Analysis of the SAML Single Sign-on Browser/
              Artifact Profile"", January 2005,
              <http://www.oasis-open.org/committees/download.php/
              11191/sstc-gross-sec-analysis-response-01.pdf>.

   [OAuth-ASSERTIONS]
              Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
              "Assertion Framework for OAuth 2.0", Work in Progress,
              December 2012.

   [OAuth-HTTP-MAC]
              Richer, J., Ed., Mills, W., Ed., and H. Tschofenig, Ed.,
              "OAuth 2.0 Message Authentication Code (MAC) Tokens", Work
              in Progress, November 2012.

   [OAuth-JWT]
              Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", Work in Progress, December 2012.

   [OAuth-REVOCATION]
              Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "Token
              Revocation", Work in Progress, November 2012.

   [OPENID]   "OpenID Foundation Home Page", <http://openid.net/>.

   [OWASP]    "Open Web Application Security Project Home Page",
              <https://www.owasp.org/>.

   [Portable-Contacts]
              Smarr, J., "Portable Contacts 1.0 Draft C", August 2008,
              <http://portablecontacts.net/>.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              July 2005.

Top      Up      ToC       Page 71 
   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [SSL-Latency]
              Sissel, J., Ed., "SSL handshake latency and HTTPS
              optimizations", June 2010.

   [Sec-Analysis]
              Gross, T., "Security Analysis of the SAML Single Sign-on
              Browser/Artifact Profile", 19th Annual Computer Security
              Applications Conference, Las Vegas, December 2003.

   [X-Frame-Options]
              Ross, D. and T. Gondrom, "HTTP Header X-Frame-Options",
              Work in Progress, October 2012.

   [iFrame]   World Wide Web Consortium, "Frames in HTML documents",
              W3C HTML 4.01, December 1999,
              <http://www.w3.org/TR/html4/present/frames.html#h-16.5>.

Authors' Addresses

   Torsten Lodderstedt (editor)
   Deutsche Telekom AG

   EMail: torsten@lodderstedt.net


   Mark McGloin
   IBM

   EMail: mark.mcgloin@ie.ibm.com


   Phil Hunt
   Oracle Corporation

   EMail: phil.hunt@yahoo.com