如何保护 Web 应用程序中的不记名令牌答案

【问题标题】：How to protect bearer tokens in a web app如何保护 Web 应用程序中的不记名令牌
【发布时间】：2018-01-19 09:13:08
【问题描述】：

我正在尝试为基于 JavaScript 的应用程序实现 RFC 6749 (OAuth 2.0) 中描述的授权代码流程。我知道我应该使用 Web 服务器后端作为机密客户端，以便它可以保护授权服务器返回的访问令牌和刷新令牌，而不是将它们传递给 JavaScript 前端。然后从前端到任何受保护资源的所有请求都通过 Web 服务器后端，后端将访问令牌附加到请求并代理它。

我的问题是如何让 JavaScript 前端以安全的方式使用这些令牌？我假设我必须做一些事情，比如在 Web 服务器上设置一个会话并传回一个标识会话的 cookie。但这意味着 JavaScript 应用程序将拥有一个 cookie，该 cookie 赋予它们相同的权限，就好像它们可以直接访问存储在 Web 服务器中的不记名令牌一样。拥有一个 Web 服务器来保存令牌如何提供额外的安全性？

【问题讨论】：

你必须使用授权代码流程还是你只是选择它？
我需要支持刷新令牌和规范的section 4.2 说隐式授权类型不支持它们。

标签： rest oauth-2.0

【解决方案1】：

我了解我应该使用 Web 服务器后端作为机密客户端，以便它可以保护授权服务器返回的访问令牌和刷新令牌，而不是将它们传递给 JavaScript 前端。

不，这是对 OAuth2 流程和目标的误解。

这是 OAuth2 的主要目标：您的应用程序（例如，可以是在浏览器中运行的 JavaScript 程序、网络服务器等）不得 > 需要知道用户的凭据（大多数情况下是登录名/密码对）才能代表用户访问服务。

这是实现此目标必须使用 OAuth2 的方式：

根据您的需要，即在浏览器中运行基于Javascript的应用程序（即不是 node.js应用程序），您需要使用OAuth2 隐式flow，而不是授权码流。但是，当然，因为您的应用程序在浏览器中运行，它将无法持久访问服务提供商提供的资源的凭据。对于您应用程序上的每个新会话，用户都必须向服务提供商进行身份验证。
当您的应用程序需要在用户未登录的情况下访问服务提供者时，或者当您的应用程序能够保留凭据（因为您的应用程序有自己的凭据系统来识别其用户）时，您的应用程序会不仅依赖于在浏览器中运行的 JavaScript 程序。它可能仅依赖于 Web 服务器，或者同时依赖于 Web 服务器和与该服务器对话的 JavaScript 程序。因此，在这些情况下，您必须使用授权代码流。

因此，作为结论，您决定将 Web 服务器添加到您的应用程序中，因为您认为必须使用授权代码流。但是在您的情况下，您可能不必使用此代码流，因此您应该为您的应用程序选择适当的代码流：隐式代码流。这样，您不必添加 Web 服务器到运行您的应用程序。

拥有一个 Web 服务器来保存令牌如何提供额外的安全性？

这并没有提供额外的安全性。拥有一个 Web 服务器来保存令牌只是让您的应用程序在用户未登录您的应用程序时在后台代表用户访问服务的一种方式。

【讨论】：

但是 OP 想要使用隐式流不支持的刷新令牌。在这种情况下，我认为他的应用程序需要自己的 Web 服务器会话，并受其自己的一组凭据保护，因此它可以将令牌安全地存储在服务器上。这似乎消除了使用 OAuth2 委派身份验证过程的好处，因为您首先需要一个单独的会话身份验证过程。还是我弄错了？

【解决方案2】：

虽然我同意 Alexandre Fenyo 的 cmets，但我只想添加 2021 版本。您不应再使用implicit flow，因为这是no longer considered secure。

对于诸如 JavaScript 应用程序必须处理令牌的情况，我建议改用 Authorization Code flow with PKCE：https://auth0.com/docs/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce

【讨论】：