#1 楼
Authorization: <type> <credentials>模式是W3C在HTTP 1.0中引入的，此后已在许多地方重复使用。许多Web服务器支持多种授权方法。在这种情况下，仅发送令牌是不够的。使用
Authorization : Bearer cn389ncoiwuencr
格式的网站最有可能实现OAuth 2.0承载令牌OAuth 2.0授权框架设置了许多其他要求以确保授权安全，例如要求使用HTTPS / TLS。
如果要与使用OAuth 2.0的服务集成，则熟悉框架的好主意，以便正确使用您正在使用的流程，并避免不必要的漏洞。在线上有许多不错的教程。
评论
我不熟悉MS Graph API，可能是其实现的怪癖。
– Vegard
16年4月13日在8:17
那就是我在想的。考虑到您通常对Bearer令牌和令牌的了解，您是否可以通过API接受不带Bearer关键字的令牌这一事实看到任何安全隐患？
– DaRoGa
16年4月13日在8:18
并非如此，但是我同意这个问题的一个意见-如果他们在这一点上的实现不同，还有什么不同？话虽这么说，但仍有许多类似RFC的类似于OAuth的实现。但是，这并不意味着它们的实现不太安全。
– Vegard
16年4月13日在8:42
#2 楼
在进行承载授权之前，此标头已用于基本身份验证。为了实现互操作性，这些标头的使用受W3C规范支配，因此，即使您正在读写标头，也应遵循它们。 Bearer区分您使用的授权类型，因此很重要。#3 楼
在每个“内联操作” HTTP请求的“授权”标头中都设置了一个“承载令牌”，“承载”本身确定了身份验证的类型。 -bearer-tokens评论
此答案特定于gmail开发人员，而不是所有Web开发人员。 “动作”是一个gmail概念。
–aeb0
19年8月8日在1:19
评论
http验证还有其他方法，例如基本或摘要。我想能够区分它们很好。这个问题专门针对基于令牌的身份验证，通常是在基本身份验证之后进行的，这样用户不必在每次请求时都提供用户名和密码。
我也有类似的问题。我想为短暂的令牌实现选择一种方案，该方案不完全符合Oauth 2.0。我想知道我是否可以使用Bearer或任何非标准值而不会麻烦代理和服务器的解释。我最接近找到答案的是：stackoverflow.com/questions/7802116/…和stackoverflow.com/questions/8463809/…
服务器通常是否通过相同的路由（即HTTP响应的“授权：承载”）返回令牌？还是它几乎总是响应主体的一部分？
MDN上的HTTP身份验证页面对于讨论非常有用。