根据RFC6750-OAuth 2.0授权框架：承载令牌使用情况，承载令牌是：
具有属性的安全令牌，即拥有该令牌的任何一方（“持票人”）可以以任何其他拥有该令牌的方式使用该令牌 .
对我来说，这个定义含糊不清，我找不到任何规范 .
假设我正在实施授权提供程序，我可以为持有者令牌提供任何类型的字符串吗？
可以是随机字符串吗？
它是否必须是某些属性的base64编码？它应该散列吗？
服务提供商是否需要查询授权提供商才能验证此令牌？
谢谢你的指针 .
承载令牌一种安全令牌，其属性是拥有该令牌的任何一方（“持票人”）可以以任何其他拥有该令牌的方式使用该令牌 . 使用不记名令牌不需要持票人来证明拥有加密密钥材料（占有证明） .
身份验证服务器为您创建了承载令牌或刷新令牌 . 当用户对您的应用程序（客户端）进行身份验证时，身份验证服务器会为您生成一个承载令牌（刷新令牌），然后您可以使用该令牌来获取访问令牌 .
承载令牌通常是由认证服务器创建的某种秘密值 . 它不是随机的;它是根据用户提供访问权限和应用程序访问客户端创建的 .
例如，要访问API，您需要使用访问令牌 . 访问令牌是短暂的（约一小时） . 您使用承载令牌获取新的Access令牌 . 要获取访问令牌，您需要向身份验证服务器发送此承载令牌以及您的客户端ID . 这样，服务器知道使用承载令牌的应用程序是与为其创建承载令牌的应用程序相同的应用程序 . 示例：我不能只为您的应用程序创建一个持有者令牌，并将其与我的应用程序一起使用它不会工作，因为它不是为我生成的 .
Google刷新令牌如下所示：1 / mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM
从评论中复制：我认为您提供的持有人令牌没有任何限制 . 我唯一能想到的是允许不止一个的好处 . 例如，用户可以对应用程序进行多达30次的身份验证，旧的承载令牌仍然有效 . 哦，如果一个人没有被用于说6个月，我会从你的系统中删除它 . 这是您的身份验证服务器，必须生成它们并验证它们，以便它的格式取决于您 .
Update:
在每个内联操作HTTP请求的授权头中设置承载令牌 . 例如：
POST /rsvp?eventId=123 HTTP/1.1 Host: events-organizer.com Authorization: Bearer AbCdEf123456 Content-Type: application/x-www-form-urlencoded User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0 (KHTML, like Gecko; Gmail Actions) rsvpStatus=YES
上例中的字符串 "AbCdEf123456" 是承载授权令牌 . 这是由身份验证服务器生成的加密令牌 . 通过操作发送的所有承载令牌都具有问题字段，受众字段将发件人域指定为https：//形式的URL . 例如，如果电子邮件来自noreply@example.com，则受众是https://example.com .
"AbCdEf123456"
如果使用承载令牌，请验证请求是否来自身份验证服务器并且是否适用于发件人域 . 如果令牌未验证，则服务应使用HTTP响应代码401（未授权）响应该请求 .
承载令牌是OAuth V2标准的一部分，并被许多API广泛采用 .
在我阅读你的问题时，我试图在互联网上搜索Bearer令牌是如何加密或签名的，但没有成功 . 我想承载令牌不是哈希（可能部分，但不完全），因为在这种情况下，将无法解密它并从中检索用户属性 .
但你的问题似乎是试图找到有关承载令牌功能的答案：
假设我正在实施授权提供程序，我可以为持有者令牌提供任何类型的字符串吗？它可以是随机字符串吗？它必须是某些属性的base64编码吗？它应该散列吗？
因此，我将尝试解释Bearer令牌和刷新令牌的工作原理：
当用户通过SSL向服务器请求发送用户和密码的令牌时，服务器返回两件事： Access token 和 Refresh token .
访问令牌是一个承载令牌，您必须在所有请求头中添加这些令牌以作为具体用户进行身份验证 .
Authorization: Bearer <access_token>
访问令牌是一个加密的字符串，包含您希望的所有用户属性，声明和角色 . （如果添加更多角色或声明，您可以检查令牌的大小是否增加） . 一旦资源服务器收到一个acccess令牌，它就能解密它并读取这些用户属性 . 这样，将在所有应用程序中验证和授予用户 .
访问令牌的到期时间很短（即30分钟） . 如果访问令牌有很长的到期时间，那将是一个问题，因为理论上没有可能撤销它 . 因此，假设一个角色=“Admin”的用户更改为“User” . 如果用户使用role =“Admin”保留旧令牌，则他将能够使用管理员权限访问令牌到期 . 这就是访问令牌过期时间短的原因 .
但是，有一个问题可以考虑 . 如果访问令牌的到期时间很短，我们必须每隔短期发送一次用户和密码 . 这样安全吗？不，不是 . 我们应该避免它 . 那时刷新令牌似乎解决了这个问题 .
刷新令牌存储在数据库中，并且有很长的到期时间（例如：1个月） .
用户可以使用刷新令牌获取新的访问令牌（当它到期时，例如每30分钟），用户在第一次令牌请求中收到该令牌 . 当访问令牌到期时，客户端必须发送刷新令牌 . 如果此刷新令牌存在于DB中，则服务器将向客户端返回新的访问令牌和另一个刷新令牌（并将用新刷新令牌替换旧的刷新令牌） .
如果用户访问令牌已被泄露，则必须从DB中删除该用户的刷新令牌 . 这样，令牌只有在访问令牌到期时才有效，因为当黑客试图获取发送刷新令牌的新访问令牌时，此操作将被拒绝 .
持票人令牌是一个或多个字母，数字，“ - ”，“ . ”的重复 . ，“_”，“〜”，“”，“/”后跟0或更多“=” .
RFC 6750 2.1. Authorization Request Header Field（格式为ABNF（增强型BNF））
The syntax for Bearer credentials is as follows: b64token = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"=" credentials = "Bearer" 1*SP b64token
它看起来像Base64，但根据Should the token in the header be base64 encoded?，它不是 .
深入研究“HTTP / 1.1，第7部分：身份验证”**，但是，我看到b64token只是一个ABNF语法定义，允许通常在base64，base64url等中使用的字符 . 所以b64token不会定义任何编码或解码，而只是定义可以在包含访问令牌的Authorization标头部分中使用的字符 .
RFC 5234 3.6. Variable Repetition: *Rule
RFC 2616 2.1 Augmented BNF
3 回答
身份验证服务器为您创建了承载令牌或刷新令牌 . 当用户对您的应用程序（客户端）进行身份验证时，身份验证服务器会为您生成一个承载令牌（刷新令牌），然后您可以使用该令牌来获取访问令牌 .
承载令牌通常是由认证服务器创建的某种秘密值 . 它不是随机的;它是根据用户提供访问权限和应用程序访问客户端创建的 .
例如，要访问API，您需要使用访问令牌 . 访问令牌是短暂的（约一小时） . 您使用承载令牌获取新的Access令牌 . 要获取访问令牌，您需要向身份验证服务器发送此承载令牌以及您的客户端ID . 这样，服务器知道使用承载令牌的应用程序是与为其创建承载令牌的应用程序相同的应用程序 . 示例：我不能只为您的应用程序创建一个持有者令牌，并将其与我的应用程序一起使用它不会工作，因为它不是为我生成的 .
Google刷新令牌如下所示：1 / mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM
从评论中复制：我认为您提供的持有人令牌没有任何限制 . 我唯一能想到的是允许不止一个的好处 . 例如，用户可以对应用程序进行多达30次的身份验证，旧的承载令牌仍然有效 . 哦，如果一个人没有被用于说6个月，我会从你的系统中删除它 . 这是您的身份验证服务器，必须生成它们并验证它们，以便它的格式取决于您 .
Update:
在每个内联操作HTTP请求的授权头中设置承载令牌 . 例如：
上例中的字符串
"AbCdEf123456"是承载授权令牌 . 这是由身份验证服务器生成的加密令牌 . 通过操作发送的所有承载令牌都具有问题字段，受众字段将发件人域指定为https：//形式的URL . 例如，如果电子邮件来自noreply@example.com，则受众是https://example.com .如果使用承载令牌，请验证请求是否来自身份验证服务器并且是否适用于发件人域 . 如果令牌未验证，则服务应使用HTTP响应代码401（未授权）响应该请求 .
承载令牌是OAuth V2标准的一部分，并被许多API广泛采用 .
在我阅读你的问题时，我试图在互联网上搜索Bearer令牌是如何加密或签名的，但没有成功 . 我想承载令牌不是哈希（可能部分，但不完全），因为在这种情况下，将无法解密它并从中检索用户属性 .
但你的问题似乎是试图找到有关承载令牌功能的答案：
因此，我将尝试解释Bearer令牌和刷新令牌的工作原理：
当用户通过SSL向服务器请求发送用户和密码的令牌时，服务器返回两件事： Access token 和 Refresh token .
访问令牌是一个承载令牌，您必须在所有请求头中添加这些令牌以作为具体用户进行身份验证 .
访问令牌是一个加密的字符串，包含您希望的所有用户属性，声明和角色 . （如果添加更多角色或声明，您可以检查令牌的大小是否增加） . 一旦资源服务器收到一个acccess令牌，它就能解密它并读取这些用户属性 . 这样，将在所有应用程序中验证和授予用户 .
访问令牌的到期时间很短（即30分钟） . 如果访问令牌有很长的到期时间，那将是一个问题，因为理论上没有可能撤销它 . 因此，假设一个角色=“Admin”的用户更改为“User” . 如果用户使用role =“Admin”保留旧令牌，则他将能够使用管理员权限访问令牌到期 . 这就是访问令牌过期时间短的原因 .
但是，有一个问题可以考虑 . 如果访问令牌的到期时间很短，我们必须每隔短期发送一次用户和密码 . 这样安全吗？不，不是 . 我们应该避免它 . 那时刷新令牌似乎解决了这个问题 .
刷新令牌存储在数据库中，并且有很长的到期时间（例如：1个月） .
用户可以使用刷新令牌获取新的访问令牌（当它到期时，例如每30分钟），用户在第一次令牌请求中收到该令牌 . 当访问令牌到期时，客户端必须发送刷新令牌 . 如果此刷新令牌存在于DB中，则服务器将向客户端返回新的访问令牌和另一个刷新令牌（并将用新刷新令牌替换旧的刷新令牌） .
如果用户访问令牌已被泄露，则必须从DB中删除该用户的刷新令牌 . 这样，令牌只有在访问令牌到期时才有效，因为当黑客试图获取发送刷新令牌的新访问令牌时，此操作将被拒绝 .
持票人令牌是一个或多个字母，数字，“ - ”，“ . ”的重复 . ，“_”，“〜”，“”，“/”后跟0或更多“=” .
RFC 6750 2.1. Authorization Request Header Field（格式为ABNF（增强型BNF））
它看起来像Base64，但根据Should the token in the header be base64 encoded?，它不是 .
参考文献
RFC 5234 3.6. Variable Repetition: *Rule
RFC 2616 2.1 Augmented BNF