与URL编码等其他技术相比，为什么我们更喜欢授权头向服务器发送承载令牌
为什么授权标头主要用于向服务器发送承载令牌？为什么我们不将授权令牌作为URL参数发送或将其作为请求正文的json有效负载发布？
共有1个答案
标头非常适合保存这些数据，它们独立于请求类型。
您可以在正文中发送授权令牌，甚至包括其他所有内容，如内容类型、内容长度、缓存头，但请求类型不同（POST、GET）可能具有不同的请求正文格式<代码>获取使用查询参数发送数据，内容类型：应用程序/json在正文中以编码形式放入（使用内容类型：application/x-www-form-urlencoded使服务器知道输入数据格式），内容类型：应用程序/json在正文中包含json、XML和其他内容。多部分请求的情况变得更加复杂（请检查此项https://stackoverflow.com/a/19712083/1017363).
正如您所看到的，主体或查询中的授权令牌使客户端和服务器端的事情更加复杂。客户端应该知道如何在每个请求上“适应”授权令牌，服务器应该知道如何读取该值。
-
我正在做一个带有用户名和密码的登录屏幕。如果登录成功，服务器将返回令牌。然后，我试图调用另一个函数来获取用户信息，但没有传递授权标头。我正在邮递员上尝试我的服务器方法，它工作得很好，所以我相信问题出在邮件头上。有人能告诉我该怎么做吗？ 请注意，result.access_token！=null是true.并且我成功地拿回了令牌。但是它不会被再次传递到第二个url（info）
-
我刚意识到谷歌将AdMob嵌入最新的Google Play服务(4+) 我这么问的原因是，我发现谷歌Play服务的AdMob仍然很有问题。 这是我的观察。 从Java代码创建一个智能横幅，并将其放在滚动视图的中间。 每当智能横幅从Google服务器成功获取广告时，滚动视图将自动滚动以使智能横幅可见。 演示该bug的完整源代码可以在这里找到：来自Google Play服务的AdMob将执行不希望的自
-
问题内容： 在Swing中，密码字段具有（returns ）方法，而不是通常的（returns ）方法。同样，我也遇到了不建议使用密码的建议。 为什么涉及密码安全性受到威胁？使用起来感觉不方便。 问题答案： 字符串是不可变的。这意味着一旦创建了，如果另一个进程可以转储内存，则除了反射之外，你将无法清除数据，然后再进行垃圾回收。 使用数组，你可以在使用完数据后显式擦除数据。你可以用任何你喜欢的东西覆
-
我正在为一个全新的前端添加JWT认证到一个遗留的Rails后端。 根据 HTTP 请求，似乎大多数消息来源都建议我通过持有者标头将令牌发送回服务器。 为什么？通过报头发送的附加价值是什么(承载或基本)。我不能简单地把JWT传回到服务器。json并在那里验证令牌。 Authorization标头给我带来了什么好处，更重要的是，Bearer Authorize标头给了我什么好处？ 我当然可以简单地效仿
-
例如，当我有一个post方法-登录时，我得到了签名的JSON Web令牌。我在youtube上看了一些教程，当他们检查用户是否被授权时，他们会在授权标头中发送JWT，例如： 不记名令牌 我的问题是：当同样的事情在工作时，如果我们只发送授权标头中的令牌，而没有令牌前面的“持有人”，他们为什么要这样做？
-
当一个人试图使用azure AD承载令牌访问我们的系统时，这个获取和缓存资源令牌的工作流程是不存在的。 所以我的问题是，我如何使用承载令牌来启用它？如何才能像使用OpenIDConnect一样请求额外的资源令牌？是否可以使用ADAL从承载令牌获取授权代码？