首页 > 解决方案 > 单页应用程序的身份验证

问题描述

背景

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

问题

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

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

这并不是一个真正的漏洞,但我看到的文档和示例并没有明确涵盖这种细微差别,我认为它可能会导致天真的程序员(比如我自己)认为某些页面在不严格的情况下是完全安全的。

问题

如果比我更了解情况的人确认这确实是 SPA 身份验证应该如何工作,那将不胜感激?

标签: reactjsauthenticationoauth-2.0auth0

解决方案


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

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

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


推荐阅读