使用 JWT 进行身份验证：服务器端还是客户端？答案

【问题标题】：Authentication with JWT: server or client-side?使用 JWT 进行身份验证：服务器端还是客户端？
【发布时间】：2017-10-07 09:39:21
【问题描述】：

我一直在阅读有关如何设置 JSON Web 令牌以及我发现的所有示例都在客户端实现身份验证逻辑（例如 generator-angular-fullstack）。

例如，假设有一个应用程序，用户只需转到根地址即可访问个人仪表板。如果未通过身份验证，则应将用户重定向到登录或登录页面。遵循 Angular 全栈生成器的最佳实践，客户端将首先下载整个 Angular 应用程序，然后将其用于处理身份验证和路由，并在必要时重定向到登录页面。

假设大多数访问者甚至没有帐户，为什么让他们下载所有代码只是为了最终向他们显示一个日志页面？

简单地为未经身份验证的用户提供轻量级登录页面，只为已经拥有有效令牌的用户提供 Angular 应用程序不是更好吗？如果是这样，为什么我找不到任何以这种方式实现的示例？

【问题讨论】：

【解决方案1】：

您在前端应用程序中面临基于令牌的身份验证的问题之一：在客户端向服务器发出初始请求时，服务器不知道登录状态。

如果您的登录表单不是您的 Angular 应用程序的一部分，这是基于 cookie/会话的身份验证的常见用例，因为 cookie 是与初始请求一起交付的。这样，服务器就知道是为 Angular 应用程序提供服务还是重定向到登录表单。

但是，如果您的登录表单是您的 Angular 应用程序的一部分，我认为在为整个应用程序提供服务时没有任何问题。登录后（将用户名 + 密码发送到服务器），您将获得一个用于所有进一步请求的令牌。在经典的单页应用程序中，这不会包括任何额外的重新加载。

【讨论】：

但是 JWT 可以存储为 cookie（如我上面给出的示例中所实现的）并在第一个请求中发送出去，因此服务器应该能够判断该客户端是否经过身份验证。实际上，我看不出这与加载并验证您的应用程序后进行完全刷新有何不同。无需依赖 Angular 发送该令牌。至于实用性，假设您有大量没有帐户的一次性访问者。为这些用户提供一个精简的登录页面将使加载时间更快并节省带宽。还是我误会了什么？