背景
我正在查看OAuth 2.0隐式授予流，其中将用户重定向到身份验证服务，并将JWT令牌发送回单页应用程序（SPA）。令牌存储在cookie或本地存储中，在我所看到的示例中，应用程序将根据是否可以在存储中找到令牌来隐藏/显示某些页面。
问题
问题在于，在所有示例（服务提供商提供的官方示例）中，我都能够手动将任何随机但格式正确的令牌添加到浏览器的本地存储中，并可以访问“安全”页面。
有人告诉我，您无法在SPA中验证令牌，因为这将需要公开客户端密码，并且您应该在API服务器上验证令牌。这意味着您可以“隐藏”页面，但是如果有人愿意的话，很容易看到它们。话虽这么说，您不太可能造成任何实际损失，因为任何数据检索或操作都需要通过API服务器进行，并且令牌应在此处进行验证。
这并不是真正的漏洞，但是我所看到的文档和示例并未明确涵盖这一细微差别，我认为这可能会使天真的程序员（如我自己）认为某些页面在严格意义上不是完全安全的。情况。
问题
如果一个比我更了解情况的人确认这确实是SPA身份验证应该工作的方式，将不胜感激？
答案 0 :(得分：3)
我距离专家还很远，但是我在这个领域发挥了一些作用。我的印象是，您是正确的，任何仅基于令牌存在的功能显示/隐藏都容易被欺骗。您的SPA当然可以进入verifying an access token。 但这可能会使欺骗变得更具挑战性。如果有人想假冒客户认为它具有有效的令牌，则可以操纵客户端JS来做到这一点。不幸的是，这就是客户端JS的本质。许多代码可以在浏览器中进行操作。
到目前为止，这是在保护用户免受UI / UX的侵害。大多数应用程序只有在有数据填充其UI时才有用。那就是API访问令牌策略仍然有效的地方。服务器将验证令牌，如果没有令牌，则不会向客户端提供任何数据。
因此，不幸的是，可以很容易地欺骗和操纵JS以显示开发人员宁愿不可见的事物，但这通常不会破坏交易。如果您具有不需要数据的很棒的UI功能，并且需要保护对该UI本身的访问，则此模型可能不是最大的模型。