.NET Core 2.0 和 EF 下是否需要使用 IdentityDbContext 进行 JWT 身份验证？

Question

我正在使用 .NET Core 下的登录过程，我注意到当我按照指南使用 IdentityDbContext 和 IdentityUser 时，我会自动在数据库中获得一堆表（例如 AspNetUsers 、AspNetUserClaims 等）。

虽然很好，但我想知道使用不那么神奇的DbContext 并创建自己的用户和角色管理模式是否非常错误。我更喜欢“杀死我自己的食物”以了解安全性是如何工作的，我不喜欢使用我不了解其中的螺栓和螺母的工具和框架。 （“它就是这样工作的”通常会在它停止按预期工作时导致问题。）

IdentityDbContext、IdentityUser 等中的 Identity 部分只是为了方便还是应该使用？

我将针对的技术堆栈是 .NET Core 2.0 和 JWT 身份验证。当然，模型应该由EF在DB中管理。

如果问题是愚蠢的，请原谅。我是安全方面的新手，可能会找错树。

Answer 1

不需要使用这些类。它们是经过测试的便利实现，适合大多数常见用例，但您可以替换或自定义身份堆栈的各个方面。

身份堆栈具有以下组件：

• 经理：UserManager、RoleManager 和类似的类在应用程序中用于对数据执行必要的“业务”操作。尽管您可以将它们替换为自定义实现，但几乎没有必要。
• Stores：UserStore、RoleStore 和类似的用于对它们管理的类型执行核心数据操作。您可以提供自定义实现来替换使用的存储机制。提供的存储使用实体框架对托管类型执行数据操作。您可以替换这些以实现其他商店类型。如果您要将用户数据作为文档存储在 ElasticSearch 中，这将是要实现的接口。
• 存储数据类型：IdentityUser、IdentityRole 等是保存有关用户/角色/声明/的信息的默认实体类型。这些类型可以子类化以扩展它们，或者如果您愿意，可以使用不同的类.例如，如果您要存储在 ElasticSearch 中，您可以重用这些类型以避免创建自定义类型来保存用户数据。如果您希望与它们一起存储自定义信息，则默认存储（实体框架）用于处理子类。但是您不必也可以使用您喜欢的任何类，只要您实现了一个知道如何使用它们的自定义存储并且它们上至少有一个Id 和一个UserName 属性。

有关自定义选项的更多信息，请参阅Custom storage providers for ASP.NET Core Identity 文档页面。