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

Posted 2023-03-08

【中文标题】.NET Core 2.0 和 EF 下是不是需要使用 IdentityDbContext 进行 JWT 身份验证？

【英文标题】：Is it required to use IdentityDbContext for JWT authentication under .NET Core 2.0 and EF?.NET Core 2.0 和 EF 下是否需要使用 IdentityDbContext 进行 JWT 身份验证？

【发布时间】：2018-05-23 03:44:32

【问题描述】：

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

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

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

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

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

【参考方案1】：

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

身份堆栈具有以下组件：

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

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

【讨论】：

这回答了我的问题。但是，我仍然有一些问题让我感到困惑。 (1) 我希望我的Id 成为一名向导。我可以在默认字符串类型上使用new 它而不会对类的便利性造成损害吗？ (2) 我期待IdentityUser 类有对IdentityRole 的引用和声明列表，但据我所知，智能感知并没有呈现类似的东西。我错过了什么吗？

(1) IdentityUser 是IdentityUser<TKey> 的子类，您可以使用它来自定义要使用的ID 类型。我不知道实际的设计决定是默认使用string，但就个人而言（！）我喜欢它，因为它不假定默认情况下能够自动递增整数的商店。

(2) store 中的关注点是分离的，因此 store 默认情况下不必实现声明。然后UserManager 将在声明操作上抛出异常，其SupportsUserClaim 属性将返回false。如果应用程序要支持声明，商店可以实现IUserClaimStore<TUser>。

至于（1），我习惯了所有ID的guid-ification。如果字段类型是字符串，如何顺利分配随机 guid？我已经看到 FluidApi 中有一个选项可以在加法时自动生成值，但是在字符串的情况下不会有太大的好处，不是吗？对于 IdentityUser 类型，您会推荐什么将值分配为 ID 的策略？

用户管理器在哪里？ （或者，可能，应该在哪里实施？）对不起，如果这个问题很愚蠢 - 只是想弄清楚这件事。