Oauth 2.0 隐式流的安全风险是什么

隐式流被认为是不安全的。我意识到两个问题：

。但要克服它，您只需要检查是否为您的应用程序提供了访问令牌。没什么大不了的

XSS攻击。因此，如果我们的access_令牌是通过XSS攻击被盗的，它可以用来发出请求（这是我们最初请求的范围的一部分）。这很糟糕，但很难窃取access_令牌，因为很可能我们只有在登录页面上才有它，并且没有存储在应用程序状态中，因为它的寿命很短（我想这就是隐式工作流不支持刷新令牌的原因）

---

看起来还不错。是否存在我不知道的任何其他安全漏洞？

正确的声明应该是

隐式流相对于代码流而言是不安全的

如果攻击者想使用代码流从应用程序中窃取用户访问令牌，则攻击者必须侵入服务器网络，或者揭露应用程序机密，或者窃听从服务器到谷歌（即HTTPS）的网络流量，以获取访问令牌

在隐式流中，访问令牌驻留在浏览器中。在这种情况下，攻击者还可能在不破坏网络的情况下窃取令牌

• XSS（正如您已经解释的）
• 代理问题混乱（正如您已经解释的）
• 会话固定问题（在用户B的会话中使用用户A的令牌。）
• 重定向url参数操作
• （可能）referer头出现令牌泄漏
• 各种各样的网络钓鱼和社会工程可能诱骗用户泄露他们的访问令牌（比询问他们的密码更容易）

---

但正如您所说，如果您是一个安全意识强的开发人员，那么很容易减轻所有这些错误。但是，如果实现隐式流，仍然有可能出现这些漏洞。因此，如果您不将令牌交付给浏览器并在服务器端组件（代码流）中处理令牌，这可能是一个好主意

您编写的隐式流相对于代码流是不安全的。我理解代码流指的是在机密客户端（后端）上使用代码流。第三种选择如何：与公共客户端（如SPA）一起使用代码流，即没有秘密。这意味着将刷新令牌传递到浏览器。这是比隐式流更糟糕还是相同？你是对的，我指的是在代码流场景中使用机密客户机。对于您的问题，我只能以“理论上”的形式回答，因为我认为这完全取决于实现的安全强化。所以“理论上”我认为向浏览器交付刷新令牌比交付访问令牌更危险。原因：刷新令牌比访问令牌具有更长的生存期。访问令牌的有效期可以持续一个小时左右，但刷新令牌的有效期可以持续几个月。因此，危险性很高。“在隐式流中，访问令牌驻留在浏览器中。”-在混合流中，令牌不也驻留在浏览器中吗？这些客户端流的目的不是将令牌存储在客户端上，这样它就可以在不通过服务器的情况下调用安全服务吗？没错。这两种情况都使用浏览器端令牌处理，只是在混合流中，您可以获得一个代码，您可以使用该代码在第二步中请求令牌，这比隐式令牌检索更安全。我将相应地更新答案。如果公共客户没有安全的方式存储客户机密，则仍然可以使用PKCE保护授权代码流。看到或看到。