jwt使用两种类型的令牌， 参数Token:访问令牌pass作为参数。 不记名令牌:它是带有“不记名”的传递头。

请同时阅读以下问题:

OAuth 2中的不记名令牌和token_type是什么?

JWT是令牌的编码标准，其中包含可以签名和加密的JSON数据有效负载。

JWT可以用于许多事情，其中包括记名令牌，即您可以向某些服务提供的一条信息，由于您拥有它(您是“记名者”)，您可以访问某些东西。

承载令牌可以以不同的方式包含在HTTP请求中，其中之一(可能是首选的方式)是授权报头。但你也可以把它放到一个请求参数，一个cookie或请求体中。这主要是在您和您试图访问的服务器之间。

简短的回答

JWT是一种编码和验证声明的方便方法。

记名令牌只是一个字符串，可能是任意的，用于授权。

背景(故事时间)

几年前，在JWT革命之前，<令牌>只是一个没有内在含义的字符串，例如2pWS6RQmdZpE0TQ93X。然后在数据库中查找该令牌，该数据库包含该令牌的声明。这种方法的缺点是每次使用令牌时都需要DB访问(或缓存)。

jwt编码并验证(通过签名)它们自己的声明。这允许人们发布短期的无状态jwt(即:自包含，不依赖于任何人)。他们不需要打DB。这减少了DB负载并简化了应用程序架构，因为只有发出jwt的服务才需要担心触及DB/持久层(您可能遇到过refresh_token)。

因为你提到你在你的url查询参数发送令牌，这可能是你感兴趣的。我认为把它们作为url参数发送，就像你和其他一些提到的答案可能会导致一些安全问题。你应该总是在你的HTTP请求中使用Authentication头，就像下面RFC文档中推荐的那样。：） 使用访问令牌

AFAIK bearer is just a more generic term for tokens, because in the following RFC7523 it's also often referred to JWT Bearer Token. However it is true that in contrast to the "normal" Bearer Token the JWT also holds information (about the issuer, creation date, ...) in, as the name implies, when decoded the JSON Format. Note that this parameters can be decoded by anyone, so this shouldn't include sensitive data, unless encrypted. JWT just ensures that the data sent inside the token, isn't manipulated because of the signature which consists of HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret), with the secret either a passphrase or public/private key pair. In the case of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it is. The size of the payload of a JWT should not exceed approx. 8kB because some browser won't accept tokens of this size. For further information about JWT you can either look up JWT.io or for more detailed information RFC 7523 JWT for oAuth

更新: 我从rfc收集到的其他一些信息证实了我的假设，非常有趣的东西:

Clients using the URI Query Parameter method SHOULD also send a
   Cache-Control header containing the "no-store" option.  Server
   success (2XX status) responses to these requests SHOULD contain a
   Cache-Control header with the "private" option.

   Because of the security weaknesses associated with the URI method
   (see Section 5), including the high likelihood that the URL
   containing the access token will be logged, it SHOULD NOT be used
   unless it is impossible to transport the access token in the
   "Authorization" request header field or the HTTP request entity-body.
   Resource servers MAY support this method. https://www.rfc-editor.org/rfc/rfc6750#section-2.3


   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). https://www.rfc-editor.org/rfc/rfc6750#section-1.2