单页应用程序的身份验证

Question

背景

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

问题

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

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

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

问题

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

Answer 1

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

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

因此，虽然不幸的是 JS 很容易被欺骗和操纵来显示开发人员不愿公开的内容，但这通常不会破坏交易。如果您有一些很棒的 UI 功能，不需要数据，并且需要保护对该 UI 本身的访问，那么此模型可能不是最好的。