JWT不记名令牌包含敏感信息，因为它们允许持有令牌的任何人模拟您。因此，特别谨慎地对待它们是有意义的，例如，* 不要 * 将它们写入服务器日志，或者不允许它们出现在跨源请求中。
但是，只有当所有相关方都知道请求的哪些部分包含敏感信息时，这种特殊处理才是可能的。如果令牌只是有效负载的一部分，则只有发送客户端和接收应用程序可能知道，而代理、服务器框架或浏览器等中间方则不会知道。相比之下，每个人都知道Authorization报头总是包含敏感信息。例如，浏览器将不会使用Authorization标头进行跨源请求，除非先前使用Access-Control-Request-Headers: Authorization的preflight request成功。
换句话说就是：如果HTTP请求总是在同一个位置包含某些类型的信息（如预定义的头），这是有意义的。

即standard specification（官方互联网协议标准）
The OAuth 2.0 Authorization Framework: Bearer Token Usage
RFC规范rfc6750中的2.1. Authorization Request Header Field部分之一

• 映像版本
  

• 纯文字版本

2.1.  Authorization Request Header Field

  When sending the access token in the "Authorization" request header
  field defined by HTTP/1.1 [RFC2617], the client uses the "Bearer"
  authentication scheme to transmit the access token.

  For example:

    GET /resource HTTP/1.1
    Host: server.example.com
    Authorization: Bearer mF_9.B5f-4.1JqM

  The syntax of the "Authorization" header field for this scheme
  follows the usage of the Basic scheme defined in Section 2 of
  [RFC2617].  Note that, as with Basic, it does not conform to the
  generic syntax defined in Section 1.2 of [RFC2617] but is compatible
  with the general authentication framework being developed for
  HTTP 1.1 [HTTP-AUTH], although it does not follow the preferred
  practice outlined therein in order to reflect existing deployments.
  The syntax for Bearer credentials is as follows:

    b64token    = 1*( ALPHA / DIGIT /
                      "-" / "." / "_" / "~" / "+" / "/" ) *"="
    credentials = "Bearer" 1*SP b64token

  Clients SHOULD make authenticated requests with a bearer token using
  the "Authorization" request header field with the "Bearer" HTTP
  authorization scheme.  Resource servers MUST support this method.

令牌类型为Basic和Digest，也用作Bearer
This guide易于理解令牌概念。