企业中大型项目通常使用ASP.NET Identity还是自定义实现？

Hey there!作为一个在企业环境里摸爬滚打多年的开发者，我来聊聊你关心的这个问题～

优先选择ASP.NET Identity的场景 #

• 绝大多数常规企业项目都会优先用它：毕竟是微软官方维护的成熟框架，内置了全套身份认证与授权的核心能力——从密码哈希存储、多因子认证（MFA），到角色/声明管理、OAuth2/OpenID Connect第三方登录集成，这些开箱即用的功能能帮团队省下大量从零造轮子的时间。
• 维护成本低，安全性有保障：官方会持续修复安全漏洞、跟进最新的身份认证标准，不用自己去关注各种加密算法的迭代、身份流程的边缘case，对于企业来说，稳定和安全是第一位的。
• 扩展性足够应对大部分需求：如果项目有特殊需求（比如自定义用户字段、扩展角色权限逻辑），ASP.NET Identity提供了丰富的扩展点，你可以轻松定制用户类、角色类，或者替换部分流程（比如自定义登录验证逻辑）。

选择自定义身份实现的少数情况 #

只有当企业有非常特殊且官方框架无法满足的需求时，才会考虑自定义方案，比如：

• 需要和企业内部遗留的身份系统做深度无缝集成（比如老系统的用户数据结构、认证逻辑完全不兼容ASP.NET Identity）；
• 有极端定制化的权限模型（比如基于资源的细粒度权限控制，比Identity的角色/声明体系复杂得多）；
• 金融、政务等对身份合规性要求极高的行业，需要完全掌控身份流程的每一个环节（比如自定义加密算法、审计日志的特殊格式要求）。

注意：自定义身份实现的成本和风险都很高，你需要自己处理密码安全、会话管理、防攻击（比如CSRF、暴力破解）等所有细节，除非真的有必要，否则不建议这么做。

给你的个人项目建议 #

如果是做SPA项目用来展示能力：

• 若想贴近企业实际工作场景，优先基于ASP.NET Identity开发，重点展示你对官方框架的掌握和扩展能力（比如集成第三方登录、自定义用户资料页）；
• 若想挑战自己，也可以尝试做一个简化版的自定义身份系统，但一定要把安全放在第一位——比如用bcrypt做密码哈希，做好会话的安全管理，避免出现低级安全漏洞。

内容的提问来源于stack exchange，提问作者Daniel