使用 IdentityServer 与创建基于 JWT 的自定义身份验证

Question

身份验证对我来说有点过头了。

我的理解是：

1. 客户端执行登录
2. API 或身份验证服务器以令牌响应
3. 客户端调用 API（包括保存令牌的标头）
4. API 检查令牌是否有效，如果有效则返回资源

我检查了几个选项：

身份服务器4

具有轻松实现 Facebook 等 3rd 方身份验证的优势。您可以轻松地使用 ASP.NET Core 身份根据角色授权您的 API。

自定义（简单）JWT 身份验证

参考：ASP.NET Core Token Authentication Guide

使用这种方法，您必须创建自己的身份用户并从数据库中获取它。

Cookie 认证

客户端在发送请求时将令牌保存在 cookie 中，您也必须发送它。

---

我的前端是用JS写的，后端是ASP.NET Core，所以是CORS。

我不知道我应该使用什么，为什么？ 为什么很多人推荐使用 IdentityServer4；简单的自定义认证还不够吗？

（我的 IdentityUser 属性和“隐藏”数据库检查存在问题）

Answer 1

身份验证的问题在于，编写几行代码来实现对用户进行身份验证的最终目标可能很简单，但要以一种您以后不会后悔的方式进行操作确实很复杂；也就是我的应用程序被拥有了。

为防止这种情况发生而采取的措施之一是不要尝试重新发明轮子并坚持使用当前标准。但是，即使有标准，您也需要相应地实施它们，这就是为什么您可能会看到像您提到的那样的建议。实际上，我自己也会提出相同类型的推荐，尽可能多地委托给第三方库，如 IdentityServer4 或云服务，如 Auth0。 （你应该知道我在 Auth0 工作，所以你可以认为我有偏见；但是，对于无偏见的推荐，你可以查看ThoughtWorks Technology Radar）。

另外，如果您将令牌存储在 cookie 中，尽管令牌的存储和传输发生不同，这仍然是一个基于令牌的身份验证系统；有关选择客户端令牌存储方法的可能影响的更多信息，请查看where to save a JWT in a browser-based application。

关于 CORS，您没有明确说明，所以我认为值得一提。如果您将前端和后端部署在不同的域中，您只需要真正担心 CORS，因为即使开发是单独进行的，如果它们共享一个域，CORS 也是您需要担心的少一件事。

结论

对于与 REST API 通信的基于浏览器的前端应用程序，最常见的方法是使用基于令牌的身份验证，该身份验证依赖于 OAuth 2.0 协议来执行令牌的实际发放。此外，您应该致力于将令牌颁发委托给第三方（IdentityServer4 或其他），这样您就不需要实施或维护系统的该部分，而只需要使用/验证生成的令牌。