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

Question

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

我的理解是:

1. 客户端执行登录
2. API或身份验证服务器使用令牌进行响应
3. 客户端调用API(包含保存令牌的头)
4. API检查令牌是否有效以及有效是否响应资源

我检查了几个选项:

IdentityServer4

具有轻松实现Facebook等第三方认证的优势.您可以轻松使用ASP.NET Core身份根据角色授权API.

自定义(简单)JWT身份验证

参考:ASP.NET核心令牌认证指南

使用此方法,您必须创建自己的标识用户并从数据库中获取它.

Cookie身份验证

客户端在发送您必须发送的请求时将令牌保存在cookie中.

---

我的前端是用JS编写的,而后端是ASP.NET Core,所以它是CORS.

我不知道应该使用什么,为什么？为什么许多人建议使用IdentityServer4; 是不是简单的自定义身份验证？

(我在IdentityUser属性和"隐藏"数据库检查方面遇到问题)

Answer 1

身份验证的问题在于编写几行代码来完成验证用户身份的最终目标可能很简单,但这样做的方式非常复杂,以后您不会后悔.又名我的应用程序拥有.

尝试防止这种情况发生的其中一个步骤是不要试图重新发明轮子并坚持使用现行标准.但是,即使使用标准,您也需要相应地实施它们,这就是为什么您可能会看到类似您提到的建议的原因.我实际上会自己做同样类型的推荐,尽可能多地委托IdentityServer4等第三方库或Auth0等云服务.(你应该知道我在Auth0工作,所以你可以认为我有偏见;但是对于无偏见的推荐,你可以查看ThoughtWorks技术雷达).

此外,如果您在令牌中存储令牌,虽然令牌的存储和传输方式不同,但这仍然是基于令牌的身份验证系统; 有关选择客户端令牌存储方法的可能影响的更多信息,请检查在基于浏览器的应用程序中保存JWT的位置.

关于CORS,你没有明确说明,所以我认为提及它可能是值得的.如果您将前端和后端部署在不同的域中,您只需要真正担心CORS,因为即使开发是孤立发生的,如果他们共享域CORS也不用担心.

结论

对于与REST API交互的基于浏览器的前端应用程序,最常见的方法是使用依赖于OAuth 2.0协议的基于令牌的身份验证来执行令牌的实际发布.此外,您应该将令牌颁发委派给第三方(IdentityServer4或其他),这样您就不需要实现或维护系统的这一部分,只需要使用/验证生成的令牌.