oauth-2.0 - OAuth2 访问 token 中允许使用哪些字符？

Question

RFC6749和 RFC6750关于 OAuth2 访问 token 中允许使用哪些字符，似乎彼此不同意。
Section A.12 RFC6749(原始 OAuth2 规范)定义访问 token 格式如下:

A.12. "access_token" Syntax

The "access_token" element is defined in Sections 4.2.2 and 5.1:

access-token = 1*VSCHAR 

在 ABNF format , VSCHAR 表示:

VSCHAR = %x20-7E

(这基本上是 all printable ASCII characters )
但是，在 RFC6750(处理 OAuth2 不记名 token 的使用)中 Section 2.1似乎为访问 token 设置了更严格的允许字符子集。

The syntax for Bearer credentials is as follows:

b64token    = 1*( ALPHA / DIGIT /

                   "-" / "." / "_" / "~" / "+" / "/" ) *"="

credentials = "Bearer" 1*SP b64token

所以这是一组限制性更强的字符，仅包括字母数字、六个特殊字符和尾随 =用于填充。
我的问题是:

这些文件中的哪一个在控制？ RFC6750 是否因为限制性更强而优先？

就“在野外”的实际实现而言，访问 token 是否总是仅限于 RFC6750 字符集？

额外的问题:有谁知道为什么这两个在同一个月发布的关于如此密切相关的主题的规范在访问 token 格式上存在分歧？

Answer 1

TL;DR: 标准之间没有冲突。 OAuth 访问 token 通常可以包含任何可打印的 ASCII 字符，但如果访问 token 是不记名 token ，则它必须使用“token64”语法才能符合 HTTP/1.1。
RFC 6749, §1.4告诉我们:“访问 token 是一个字符串”和“通常对客户端不透明”。 §A.12将其定义为一个或多个可打印的 ASCII 字符([ -~]+ 在正则表达式中)。
RFC 6749 定义了获取访问 token 的各种方法，但并不关心如何实际使用访问 token ，只是说您将它“呈现”给资源服务器，资源服务器必须验证然后接受或拒绝它。
但是 RFC 6749 确实要求授权服务器告诉客户端 token 类型(另一个字符串)，客户端可以使用它来确定访问 token 的使用方式。
token 类型字符串要么是 IANA 注册的类型名称(如 Bearer 或 mac)，要么是供应商 URL(如 http://oauth.example.org/v1)，尽管 URL 只是一个方便命名的标识符，并且不必解决任何事情。
在大多数部署中， token 类型将为 Bearer ，其语义在 RFC 6750 中定义。
RFC 6750 定义了向资源服务器提供承载访问 token 的三种方法(第 2.1–2.3 节)。推荐的方法(资源服务器必须支持以符合标准)是在 HTTP 授权 header (§2.1)中发送它，在这种情况下， token 必须是“b64token”(正则表达式中的 [-a-zA-Z0-9._~+/]+=*)。
这与 HTTP/1.1 规范所称的“token68”(RFC 7235 §2.1)相匹配，并且对于允许在 HTTP 授权 header 中不加引号地使用 token 是必要的。 (至于为什么 HTTP/1.1 允许这些确切的字符，它归结为与 HTTP/1.0 和基本身份验证标准相关的历史原因，以及当前和历史 HTTP 实现的限制。网络协议(protocol)是一项困惑的业务。)
“b64token”(又名“token68”)允许通常与 base64 编码一起使用的 ASCII 字符子集，但(尽管名称)不记名 token does not impose any base64 semantics .它只是客户端从一台服务器接收并传递给另一台服务器的不透明字符串。实现可能会为其分配语义(例如 JWT )，但这超出了 OAuth 或 Bearer token 标准。
RFC 6750 没有说明如果与其他两种(不推荐的)方法一起使用，Bearer 访问 token 必须是 b64token，但鉴于客户端应该能够选择该方法，因此给它是一个非 b64token token 。
其他 OAuth token 类型可能不依赖于在 HTTP header 中不加引号地传递(或者它们可能根本不使用 HTTP)，因此可以自由使用任何可打印的 ASCII 字符。这可能例如对于对客户端不透明的 token 类型很有用；例如，我目前正在处理访问 token 响应看起来有点像这样的设置:

{
  "access_token": "{\"endpoint\": \"srv8.example.org\", \"session_id\": \"fafc2fd\"}",
  "token_type": "http://vendor.example.org/",
  "expires_in": 3600,
  "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA"
}

在这里，访问 token 是一个 JSON 编码的数据结构，客户端必须对其进行操作(根据与供应商 token 类型相关的规则)才能访问 protected 资源。