ASP.NET Core SPA 中基于 JWT 的身份验证 - 前端验证

Posted 2023-03-27

【中文标题】ASP.NET Core SPA 中基于 JWT 的身份验证 - 前端验证

【英文标题】：JWT-based authentication in ASP.NET Core SPA - front-end validation

【发布时间】：2019-05-19 07:56:09

【问题描述】：

我目前正在使用 ASP.NET Core 2.1 中的 KnockoutJS SPA 模板，并且我设法实现了与在 Angular 中制作的授权流程完全相同的授权流程：

https://fullstackmark.com/post/13/jwt-authentication-with-aspnet-core-2-web-api-angular-5-net-core-identity-and-facebook-login

正如你在他们的用户前端服务中看到的，基本上唯一检查用户是否在客户端登录是检查客户端本地存储中是否存在“auth_token”键：

https://github.com/mmacneil/AngularASPNETCore2WebApiAuth/blob/master/src/src/app/shared/services/user.service.ts

this.loggedIn = !!localStorage.getItem('auth_token');
// ?? not sure if this the best way to broadcast the status but seems to resolve issue on page refresh where auth status is lost in
// header component resulting in authed user nav links disappearing despite the fact user is still logged in

简单地说，任何人都可以打开浏览器本地存储并使用“auth_token”键插入一个随机字符串，他们将能够在 UI 中看到所有与管理员相关的内容（即使他们在 API 请求上会失败） .

有人可以为此建议更好的流程吗？还是在“打开”管理页面时向 API 发送“登录请求”的唯一选项？

附：我对身份验证方案方面比较陌生，JWT 不应该用于客户端内容验证吗？

【参考方案1】：

考虑到 JWT 最佳实践，您的所有验证都应该在您的后端完成，因为您的 Web 应用程序中编码的任何验证都可以被您的任何客户端读取，从而导致一个巨大的安全漏洞：任何人都知道如何创建您的应用程序的有效 JWT。

即使没有任何数据，也能看到与管理员相关的 UI 是否是个大问题？考虑到所有可以返回敏感数据的路由都受到 JWT 授权的保护，如果用户访问需要数据的任何页面或 UI 部分，他们将触发检索它的请求，这可能会返回 401（未授权） HTTP 状态，或类似的。在这些情况下，常见的前端做法是清除客户端用户数据，然后重定向到登录页面。

因此，典型的流程是：

用户将伪造的访问令牌插入到他们的存储中 用户打开一个管理页面/用户界面，它以任何方式使用敏感数据（显示、用于任何内部逻辑等） Web 应用向 API 发出请求以请求数据 API 返回一个将被解释为授权错误的响应 Web 应用接收 API 响应，清除用户访问令牌并将其重定向到其登录页面

在大多数情况下，整个流程的发生速度足以阻止您的用户进一步互动和探索您的网络应用。

如果您提供有关您的场景的更多信息会更好，这样任何人都可以理解您的担忧是否需要考虑并真正解决。但是，在大多数情况下，上述行为是可以接受的。

【讨论】：

在 401 响应中没有考虑擦除本地存储，也许这有助于对抗暴力破解。