A1:规范当然允许使用 JWT 作为访问令牌，因为规范没有限制其格式.

A2:使用 JWT 作为访问令牌背后​​的想法是它可以是自包含的，以便目标可以验证访问令牌并使用关联的内容，而无需返回授权服务器.这是一个很好的属性，但会使撤销变得更加困难.因此，如果您的系统需要立即撤销访问权限的功能，那么 JWT 可能不是访问令牌的正确选择(尽管您可以通过缩短 JWT 的生命周期来获得更多收益).

From what I can tell, the OAuth 2.0 specification is extremely vague in terms of what form an access token should take:

The token may denote an identifier used to retrieve the authorization information or may self-contain the authorization information in a verifiable manner (i.e., a token string consisting of some data and a signature). Additional authentication credentials, which are beyond the scope of this specification, may be required in order for the client to use a token.

The access token provides an abstraction layer, replacing different authorization constructs (e.g., username and password) with a single token understood by the resource server. This abstraction enables issuing access tokens more restrictive than the authorization grant used to obtain them, as well as removing the resource server's need to understand a wide range of authentication methods.

Access tokens can have different formats, structures, and methods of utilization (e.g., cryptographic properties) based on the resource server security requirements. Access token attributes and the methods used to access protected resources are beyond the scope of this specification and are defined by companion specifications such as RFC6750.

(emphasis added)

The linked RFC6750 doesn't offer much further specificity. There is an example HTTP response body that shows:

{
       "access_token":"mF_9.B5f-4.1JqM",
       "token_type":"Bearer",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
     }

This seems to indicate that the access_token can be opaque ASCII text such as an encoded JSON Web Token (JWT)

From my perspective, it seems like JWT-as-access_token has some desirable properties:

• It's a known specification, with fairly wide adoption and client libraries available in many languages.

• It allows for easy signing and verification using vetted cryptographic libraries.

• Because it can be decoded to JSON, it would allow us to include metadata and information about the token within the token itself.

My questions are: First, is it permissible for the access token to be a JWT? Second, if it is permissible according to the spec, are there any additional considerations that would make using a JWT as an access token a bad idea?

A1: Using a JWT as an access token is certainly permissible by spec exactly because the spec does not restrict its format.

A2: The idea behind using a JWT as an access token is that it can then be self-contained so that the target can verify the access token and use the associated content without having to go back to the Authorization Server. That is a great property but makes revocation harder. So if your system requires a capability for immediate revocation of access, a JWT is probably not the right choice for an access token (though you can get pretty far by reducing the lifetime of the JWT).