单页应用程序的身份验证 [英] Authentication for single-page apps

问题描述

背景

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

I am looking at the OAuth 2.0 Implicit Grant flow where a user is redirected to an authentication service and a JWT token is sent back a Single Page Application(SPA). The token is stored in a cookie or in local storage and, in the examples i have seen, the application will hide/show certain pages based on whether it can find the token in storage.

问题

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

The problem is that in all the examples (official from service providers), i was able to manually add any random but properly formed token to the browser's local storage and got access to the 'secured' pages.

有人告诉我，您无法在SPA中验证令牌，因为这将需要公开客户端机密，并且您应在API服务器上验证令牌.这意味着您可以隐藏"页面，但是如果有人愿意的话，很容易看到它们.话虽如此，您不太可能造成任何实际损失，因为任何数据检索或操作都需要通过API服务器进行，​​并且令牌应在此处进行验证.

It was explained to me that you cannot validate the token in the SPA because that would require exposing the client secret and that you should validate the token on the API server. This means that you can 'hide' the pages but it is really easy to see them if someone wants to. Having said that you are unlikely to cause any real damage because any data retrieval or actions would need to go through the API server and the token should be validated there.

这并不是真正的漏洞，但是我所看到的文档和示例并未明确涵盖这一细微差别，我认为这可能会使天真的程序员(如我自己)认为某些页面在严格意义上不是完全安全的.情况.

This is not really a vulnerability but the documentation and examples I have seen do not explicitly cover this nuance and i think that it could lead naive programmers (like myself) to think that some pages are completely secure when it is not strictly the case.

问题

如果一个比我更了解情况的人确认这确实是SPA身份验证应该起作用的方式，将不胜感激?

It would be really appreciated if, someone who is better informed than i am, confirm that this is indeed how SPA authentication supposed to work?

推荐答案

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

I am far from an expert, but I have played a bit in this space. My impression is that you are correct, any showing/hiding of functionality based solely on the presence of a token is easily spoofed. Your SPA could, of course, get into verifying an access token. But that may just make it a little more challenging to spoof. If someone wants to fake the client into thinking it has a valid token, they can likely manipulate the client-side JS to do that. Unfortunately that's the nature of client-side JS. Much of the code can be manipulated in the browser.

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

Thus far this is speaking to protecting the user from seeing a UI/UX. Most applications are only beneficial when they have data to populate their UI. That's where the API access token strategy is still sound. The server will verify the token and not give the client any data without it.

因此，不幸的是，JS可以很容易地被欺骗和操纵以显示出开发人员宁愿不可见的内容，但这通常不会破坏交易.如果您拥有一些不需要数据的很棒的UI功能，并且需要保护对该UI本身的访问，则此模型可能不是最大的模型.

So while it's unfortunate that JS can be easily spoofed and manipulated to show things the developer would rather not make visible, this isn't typically a deal-breaker. If you have some awesome UI feature that doesn't need data, and you need to secure access to that UI itself, this model may not be the greatest.

这篇关于单页应用程序的身份验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！