The OAuth 2.0 Authorization Framework: Bearer Token Usage

https://tools.ietf.org/html/rfc6750

1.2. Terminology

   Bearer Token
      A security token with the property that any party in possession of
      the token (a "bearer") can use the token in any way that any other
      party in possession of it can.  Using a bearer token does not
      require a bearer to prove possession of cryptographic key material
      (proof-of-possession).

   All other terms are as defined in "The OAuth 2.0 Authorization
   Framework" [RFC6749].

 

1.3. Overview

   OAuth provides a method for clients to access a protected resource on
   behalf of a resource owner.  In the general case, before a client can
   access a protected resource, it must first obtain an authorization
   grant from the resource owner and then exchange the authorization
   grant for an access token.  The access token represents the grant's
   scope, duration, and other attributes granted by the authorization
   grant.  The client accesses the protected resource by presenting the
   access token to the resource server.  In some cases, a client can
   directly present its own credentials to an authorization server to
   obtain an access token without having to first obtain an
   authorization grant from a resource owner.

   The access token provides an abstraction, replacing different
   authorization constructs (e.g., username and password, assertion) for
   a single token understood by the resource server.  This abstraction
   enables issuing access tokens valid for a short time period, as well
   as removing the resource server's need to understand a wide range of
   authentication schemes.

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

                     Figure 1: Abstract Protocol Flow

   The abstract OAuth 2.0 flow illustrated in Figure 1 describes the
   interaction between the client, resource owner, authorization server,
   and resource server (described in [RFC6749]).  The following two
   steps are specified within this document:

   (E)  The client requests the protected resource from the resource
        server and authenticates by presenting the access token.

   (F)  The resource server validates the access token, and if valid,
        serves the request.

   This document also imposes semantic requirements upon the access
   token returned in step (D).

 

 

5.  Security Considerations

   This section describes the relevant security threats regarding token
   handling when using bearer tokens and describes how to mitigate these
   threats.

5.1.  Security Threats

   The following list presents several common threats against protocols
   utilizing some form of tokens.  This list of threats is based on NIST
   Special Publication 800-63 [NIST800-63].  Since this document builds
   on the OAuth 2.0 Authorization specification [RFC6749], we exclude a
   discussion of threats that are described there or in related
   documents.

   Token manufacture/modification:  An attacker may generate a bogus
      token or modify the token contents (such as the authentication or
      attribute statements) of an existing token, causing the resource
      server to grant inappropriate access to the client.  For example,
      an attacker may modify the token to extend the validity period; a
      malicious client may modify the assertion to gain access to
      information that they should not be able to view.

   Token disclosure:  Tokens may contain authentication and attribute
      statements that include sensitive information.

 

      Token redirect:  An attacker uses a token generated for consumption
      by one resource server to gain access to a different resource
      server that mistakenly believes the token to be for it.

   Token replay:  An attacker attempts to use a token that has already
      been used with that resource server in the past.

5.2.  Threat Mitigation

   A large range of threats can be mitigated by protecting the contents
   of the token by using a digital signature or a Message Authentication
   Code (MAC).  Alternatively, a bearer token can contain a reference to
   authorization information, rather than encoding the information
   directly.  Such references MUST be infeasible for an attacker to
   guess; using a reference may require an extra interaction between a
   server and the token issuer to resolve the reference to the
   authorization information.  The mechanics of such an interaction are
   not defined by this specification.

   This document does not specify the encoding or the contents of the
   token; hence, detailed recommendations about the means of
   guaranteeing token integrity protection are outside the scope of this
   document.  The token integrity protection MUST be sufficient to
   prevent the token from being modified.

   To deal with token redirect, it is important for the authorization
   server to include the identity of the intended recipients (the
   audience), typically a single resource server (or a list of resource
   servers), in the token.  Restricting the use of the token to a
   specific scope is also RECOMMENDED.

   The authorization server MUST implement TLS.  Which version(s) ought
   to be implemented will vary over time and will depend on the
   widespread deployment and known security vulnerabilities at the time
   of implementation.  At the time of this writing, TLS version 1.2
   [RFC5246] is the most recent version, but it has very limited actual
   deployment and might not be readily available in implementation
   toolkits.  TLS version 1.0 [RFC2246] is the most widely deployed
   version and will give the broadest interoperability.

   To protect against token disclosure, confidentiality protection MUST
   be applied using TLS [RFC5246] with a ciphersuite that provides
   confidentiality and integrity protection.  This requires that the
   communication interaction between the client and the authorization
   server, as well as the interaction between the client and the
   resource server, utilize confidentiality and integrity protection.
   Since TLS is mandatory to implement and to use with this
   specification, it is the preferred approach for preventing token

disclosure via the communication channel.  For those cases where the
   client is prevented from observing the contents of the token, token
   encryption MUST be applied in addition to the usage of TLS
   protection.  As a further defense against token disclosure, the
   client MUST validate the TLS certificate chain when making requests
   to protected resources, including checking the Certificate Revocation
   List (CRL) [RFC5280].

   Cookies are typically transmitted in the clear.  Thus, any
   information contained in them is at risk of disclosure.  Therefore,
   bearer tokens MUST NOT be stored in cookies that can be sent in the
   clear.  See "HTTP State Management Mechanism" [RFC6265] for security
   considerations about cookies.

   In some deployments, including those utilizing load balancers, the
   TLS connection to the resource server terminates prior to the actual
   server that provides the resource.  This could leave the token
   unprotected between the front-end server where the TLS connection
   terminates and the back-end server that provides the resource.  In
   such deployments, sufficient measures MUST be employed to ensure
   confidentiality of the token between the front-end and back-end
   servers; encryption of the token is one such possible measure.

   To deal with token capture and replay, the following recommendations
   are made: First, the lifetime of the token MUST be limited; one means
   of achieving this is by putting a validity time field inside the
   protected part of the token.  Note that using short-lived (one hour
   or less) tokens reduces the impact of them being leaked.  Second,
   confidentiality protection of the exchanges between the client and
   the authorization server and between the client and the resource
   server MUST be applied.  As a consequence, no eavesdropper along the
   communication path is able to observe the token exchange.
   Consequently, such an on-path adversary cannot replay the token.
   Furthermore, when presenting the token to a resource server, the
   client MUST verify the identity of that resource server, as per
   Section 3.1 of "HTTP Over TLS" [RFC2818].  Note that the client MUST
   validate the TLS certificate chain when making these requests to
   protected resources.  Presenting the token to an unauthenticated and
   unauthorized resource server or failing to validate the certificate
   chain will allow adversaries to steal the token and gain unauthorized
   access to protected resources.

 

5.3.  Summary of Recommendations

   Safeguard bearer tokens:  Client implementations MUST ensure that
      bearer tokens are not leaked to unintended parties, as they will
      be able to use them to gain access to protected resources.  This
      is the primary security consideration when using bearer tokens and
      underlies all the more specific recommendations that follow.

   Validate TLS certificate chains:  The client MUST validate the TLS
      certificate chain when making requests to protected resources.
      Failing to do so may enable DNS hijacking attacks to steal the
      token and gain unintended access.

   Always use TLS (https):  Clients MUST always use TLS [RFC5246]
      (https) or equivalent transport security when making requests with
      bearer tokens.  Failing to do so exposes the token to numerous
      attacks that could give attackers unintended access.

   Don't store bearer tokens in cookies:  Implementations MUST NOT store
      bearer tokens within cookies that can be sent in the clear (which
      is the default transmission mode for cookies).  Implementations
      that do store bearer tokens in cookies MUST take precautions
      against cross-site request forgery.

   Issue short-lived bearer tokens:  Token servers SHOULD issue
      short-lived (one hour or less) bearer tokens, particularly when
      issuing tokens to clients that run within a web browser or other
      environments where information leakage may occur.  Using
      short-lived bearer tokens can reduce the impact of them being
      leaked.

   Issue scoped bearer tokens:  Token servers SHOULD issue bearer tokens
      that contain an audience restriction, scoping their use to the
      intended relying party or set of relying parties.

   Don't pass bearer tokens in page URLs:  Bearer tokens SHOULD NOT be
      passed in page URLs (for example, as query string parameters).
      Instead, bearer tokens SHOULD be passed in HTTP message headers or
      message bodies for which confidentiality measures are taken.
      Browsers, web servers, and other software may not adequately
      secure URLs in the browser history, web server logs, and other
      data structures.  If bearer tokens are passed in page URLs,
      attackers might be able to steal them from the history data, logs,
      or other unsecured locations.

 

OAuth Bearer Tokens are a Terrible Idea

 

OAuth 2.0: Bearer Token Usage

四. 安全威胁

• Token 伪造/修改(Token manufacture/modification)：攻击者伪造或修改已有的token，导致资源服务器授权通过非法访问的客户端。因此需要对token使用数字签名或消息认证码来保证其完整性
• Token 泄露(Token disclosure)：Token本身可能包含认证、有效期等敏感信息。因此实现TLS并验证证书是必选项，加密token可用于防止客户端观察token的内容，加密token还可防止token在前端服务器和后端服务器(如果他们没有启用TLS)之间发生泄露
• Token 改寄(Token redirect)：攻击者用一个访问A资源服务器的token去请求B资源服务器的资源。因此通常token中可以包含代表资源服务器的标识来防止这种情况的发生
• Token 重放(Token replay)：攻击者企图使用曾经使用过的token来请求资源。因此token需包含有效期(比如少于1小时)

 　　另外cookie不能包含token，关于cookie的安全弱点，RFC 6265 中有如下描述：

　　A server that uses cookies to authenticate users can suffer security
   vulnerabilities because some user agents let remote parties issue
   HTTP requests from the user agent (e.g., via HTTP redirects or HTML
   forms).  When issuing those requests, user agents attach cookies even
   if the remote party does not know the contents of the cookies,
   potentially letting the remote party exercise authority at an unwary
   server.

可见即使服务端实现了TLS，攻击者依旧可以利用cookie来获取机密信息，如果cookie中包含机密信息的话；对此，不得已可将机密信息包含于URLs(前提是已实现了TLS)，但尽量使用更安全的办法，因为浏览器历史记录、服务器日志等可能泄露URLs机密信息。

 

Web API OAuth Bearer Token security

OAuth 2.0 bearer tokens depend solely on SSL/TLS for its security, there is no internal protection or bearer tokens. if you have the token you are the owner. In many API providers who relay on OAuth 2.0 they put in bold that client developers should store securely and protect the token during it is transmission.

You can read this intersting post by Eran Hammer who used to work with the community which standardize OAuth 2.0 but I believe he left them for conflict in opinions. Check his post OAuth Bearer Tokens are a Terrible Idea and you can read this post too.

But at the end it is becoming the standard way and you must transmit it over https and store it securely.