发送 Bearer 令牌的浏览器原生方式答案

【问题标题】：Browser-native way to send Bearer token发送 Bearer 令牌的浏览器原生方式
【发布时间】：2020-12-24 19:38:55
【问题描述】：

我想知道是否有一种方法可以从基于浏览器的客户端发送 Authorization: Bearer ... 标头，自动将令牌链接到请求，就像 Authorization: Basic ... 一样，可以通过发送 WWW-Authenticate: Basic realm="..." 来触发在回应中。然后浏览器要求输入用户名和密码，并在下一个请求中自动设置Authorization 标头。

有没有办法为不记名令牌做类似的事情？尤其是将令牌链接到跨页面刷新工作的主机或类似上下文？

我问的原因是避免不必要的延迟，因为必须加载和解析一些从 LocalStorage 提取承载令牌并设置 Authorization 标头的 JavaScript。这也将允许我拥有通过 Ajax 或 Fetch 请求不请求的受保护资产，例如图片（img 标签）。

我知道一个常见的解决方法是用不记名令牌替换会话 cookie。但是我想知道这个问题是否有其他解决方案。

【问题讨论】：

标签： javascript oauth-2.0

【解决方案1】：

访问令牌使用情况

没有选项可以在 HTML 请求期间自动发送访问令牌。它们被设计为仅在您的代码明确请求时发送。这可以防止 cookie 中常见的某些漏洞。

混合方法

我开始认为现代 SPA 的最佳全面选择是采用以下方法：

在浏览器中使用访问令牌 - 支持快速跨域 API 调用
仅使用 HTTP cookie 来处理与页面重新加载和多选项卡浏览相关的方面 - 其中 cookie 还可以存储或链接到刷新令牌

保护 HTML 资产

感觉 cookie 也是唯一适合您的场景的选项。正如您所说，在您的 Javascript 包完全下载之前，将在图像请求上发送一个 cookie。

我的场景

我有不同的理由想要同时获得 cookie 和令牌的好处，以便在多标签浏览期间解决一些 token renewal problems 问题。不过，我希望整体行为类似于 SPA。

有限使用的cookies

在我的例子中，我使用了一个 cookie，但是以一种非常有针对性的方式。也许在您的情况下，您可以做类似的事情，同时继续使用访问令牌进行 API 调用。

【讨论】：

谢谢 - “我非常怀疑在添加标头时会出现明显的延迟，因为浏览器将提供对本地存储的优化访问。”我指的是普通的 SPA，在后台渲染或发生任何事情之前下载、解析和执行 JS 包。如果涉及身份验证，这会增加加载时间。如果您有需要授权的资产，则不能仅使用 URL 来引用它们。（RFC 提到您可以将 ?access_token=... 添加到 URL，但不鼓励这样做，因为它不安全。）
我也不认为这是一个好处，因为这需要我使用 JavaScript。我认为应该可以支持禁用 JS 的用户的身份验证。
对不起 - 我误解了你的问题，这不是我最好的答案，所以我已经更新了。