身份验证对我来说有点过头了。
我的理解是：
我检查了几个选项：
具有轻松实现Facebook等第三方身份验证的优势。您可以轻松使用ASP.NET Core身份根据角色授权API。
参考：ASP.NET Core Token Authentication Guide
使用这种方法，您必须创建自己的身份用户并从数据库中获取它。
客户端在发送您必须发送的请求时，会将令牌保存在Cookie中。
我的前端是用JS编写的，而后端是ASP.NET Core，所以它是CORS。
我不知道应该使用什么以及为什么？ 为什么许多人建议使用IdentityServer4;是不是简单的自定义身份验证？
（我在使用IdentityUser属性和“隐藏”数据库检查时遇到问题）
答案 0 :(得分：12)
身份验证的问题在于编写几行代码来完成验证用户身份的最终目标可能很简单，但这样做的方式非常复杂。后来后悔了;也就是我的申请被拥有。
试图防止这种情况发生的其中一个步骤是不要试图重新发明轮子并坚持使用现行标准。但是，即使使用标准，您也需要相应地实施它们，这就是为什么您可能会看到类似您提到的建议的原因。我实际上会自己做同样类型的推荐，尽可能多地委托给IdentityServer4等第三方库或像Auth0这样的云服务。 （你应该知道我在Auth0工作，所以你可以认为我有偏见;但是对于无偏见的建议你可以检查ThoughtWorks Technology Radar）。
此外，如果您在令牌中存储令牌，虽然令牌的存储和传输方式不同，但这仍然是基于令牌的身份验证系统;有关选择客户端令牌存储方法的可能影响的更多信息，请检查where to save a JWT in a browser-based application。
关于CORS，你没有明确表达，所以我认为提及它可能是值得的。如果您将前端和后端部署在不同的域中，您只需要真正担心CORS，因为即使开发是孤立发生的，如果它们共享域CORS也是您需要担心的一件事。
对于与REST API交互的基于浏览器的前端应用程序，最常见的方法是使用依赖于OAuth 2.0协议的基于令牌的身份验证来执行令牌的实际发布。此外，您应该将令牌发布委托给第三方（IdentityServer4或其他），这样您就不需要实现或维护系统的这一部分，只需要使用/验证生成的令牌。