身份验证对我来说有点过分了。
我的理解是:- 客户端执行登录
- API或认证服务器响应令牌
- 客户端调用API(包括一个保存令牌的头)
- API检查令牌是否有效，如果有效则响应资源
我检查了几个选项:
IdentityServer4
具有易于实现第三方身份验证的优势，如Facebook。您可以轻松地使用ASP。. NET核心身份来基于角色授权你的API。
自定义(简单)JWT认证
参考:ASP。. NET核心令牌认证指南
使用这种方法，您必须创建自己的身份用户，并从数据库中获取它。
Cookie验证
客户端在发送请求时将令牌保存在cookie中，您也必须发送它。
我的前端是用JS编写的，后端是ASP。. NET Core，所以是CORS。
我不知道我应该用什么，为什么?为什么很多人推荐使用IdentityServer4;简单的自定义身份验证还不够吗?
(我对IdentityUser属性和"hidden"有问题)数据库检查)
身份验证的问题在于，编写几行代码来完成对用户进行身份验证的最终目标可能很简单，但要以一种以后不会后悔的方式完成这一目标却非常复杂;也就是我的应用程序被拥有了。
防止这种情况发生的步骤之一是不要尝试重新发明轮子并坚持使用当前的标准。然而，即使有了标准，您也需要相应地实现它们，这就是为什么您可能会看到您提到的建议。我自己也会提出同样的建议，尽可能多地委托给第三方库，比如IdentityServer4，或者云服务，比如Auth0。(你应该知道我在Auth0工作，所以你可以认为我有偏见;但是，要获得一个无偏见的推荐，您可以查看ThoughtWorks Technology Radar)。
同样，如果你在cookie中存储令牌，尽管令牌的存储和传输发生不同，这仍然是一个基于令牌的身份验证系统;有关选择客户端令牌存储方法的更多含义，请查看在基于浏览器的应用程序中将JWT保存在何处。
关于CORS，您没有明确说明，所以我认为有必要提一下。只有当你将前端和后端部署在不同的域中时，你才需要真正担心CORS，因为即使开发是隔离进行的，如果它们共享一个域，CORS也是你需要担心的一件事。
结论对于与REST API对话的基于浏览器的前端应用程序，最常见的方法是使用基于令牌的身份验证，该身份验证依赖于OAuth 2.0协议来执行令牌的实际发布。此外，您应该将令牌发布委托给第三方(IdentityServer4或其他)，这样您就不需要实现或维护系统的这一部分，只需要使用/验证生成的令牌。