单页应用程序的身份验证

Question

背景

我正在查看 OAuth 2.0 隐式授权流程，其中用户被重定向到身份验证服务，并将 JWT 令牌发送回单页应用程序 (SPA)。令牌存储在 cookie 或本地存储中，在我看到的示例中，应用程序将根据是否可以在存储中找到令牌来隐藏/显示某些页面。

问题

问题在于，在所有示例中（来自服务提供商的官方示例），我能够手动将任何随机但格式正确的令牌添加到浏览器的本地存储中，并可以访问“安全”页面。

有人向我解释说，您无法在 SPA 中验证令牌，因为这需要公开客户端密码，并且您应该在 API 服务器上验证令牌。这意味着您可以“隐藏”这些页面，但如果有人愿意，很容易看到它们。话虽如此，您不太可能造成任何真正的损害，因为任何数据检索或操作都需要通过 API 服务器，并且应该在那里验证令牌。

这并不是一个真正的漏洞，但我看到的文档和示例并没有明确涵盖这个细微差别，我认为它可能会导致天真的程序员（比如我自己）认为某些页面是完全安全的，但它不是严格意义上的案例。

问题

如果比我更了解情况的人确认这确实是 SPA 身份验证的工作方式，将不胜感激？

Answer 1

我远非专家，但我在这个领域玩过一些。我的印象是您是正确的，任何仅基于令牌存在的功能显示/隐藏都很容易被欺骗。当然，您的 SPA 可以进入 verifying an access token。 但这可能会使欺骗变得更具挑战性。如果有人想假装客户端认为它有一个有效的令牌，他们可能会操纵客户端 JS 来做到这一点。不幸的是，这就是客户端 JS 的本质。大部分代码都可以在浏览器中操作。

到目前为止，这是为了防止用户看到 UI/UX。大多数应用程序只有在有数据填充其 UI 时才有用。这就是 API 访问令牌策略仍然有效的地方。服务器将验证令牌，没有它就不给客户端任何数据。

因此，不幸的是，JS 很容易被欺骗和操纵以显示开发人员不想让其可见的东西，但这通常不会破坏交易。如果你有一些不需要数据的很棒的 UI 功能，并且你需要保护对该 UI 本身的访问，那么这个模型可能不是最好的。