.NET JWT 令牌验证的命名空间:系统与 Microsoft

Posted

技术标签:

【中文标题】.NET JWT 令牌验证的命名空间:系统与 Microsoft【英文标题】:Namespaces for .NET JWT token validation: System vs. Microsoft 【发布时间】:2016-11-26 09:17:33 【问题描述】:

我正在尝试使用 JWT 向 ASP.NET Web API 验证 Node 应用程序。

在 ASP.NET 中,我使用的是 .NET 4.5.1 和 nuget 包 System.IdentityModel.Tokens.Jwt5.0.0

我不明白的是,为什么命名空间在MicrosoftSystem 之间混合使用。

例如:

var tokenReader = new JwtSecurityTokenHandler();

tokenReader.ValidateToken(token, 
                new TokenValidationParameters()
            
                ValidateAudience = false
            ,
                out validatedToken);    

主要的JwtSecurityTokenHandler 位于System.IdentityModel.Tokens.Jwt 命名空间中,但TokenValidationParameters 类及其依赖项位于Microsoft.IdentityModel.Tokens 命名空间中,并且可能与System.IdentityModel.Tokens 命名空间中的类似类发生冲突。

这是设计使然,还是其他地方版本不匹配的可能迹象?

【问题讨论】:

你了解过这个吗?我现在面临同样的事情。 你能建立一个minimal reproducible example吗? 您使用的是 WIF 3.5 吗?如果是这样,您是否能够从 WIF 3.5 迁移到 4.5?这应该清除(已弃用)Microsoft 命名空间。 您是从 System.IdentityModel.Tokens.Jwt 5.0.0 还是更低版本开始升级? @DaveAlperovich 我想我是从 RC 版本之一开始的。我现在使用的是 5.0.0,但它仍然需要 System.IdentityModel 和 Microsoft.IdentityModel 类才能工作。 【参考方案1】:

在这些情况下,当您实例化时,您必须提供整个命名空间以告知编译器您正在引用哪个类和命名空间。因此,您将避免冲突。

Microsoft.Identity 在 NET 4.5 中已弃用。你可以在这里看到更多:https://social.msdn.microsoft.com/Forums/vstudio/en-US/256c6bcd-6752-4487-b2e8-6c63f4efb9e9/difference-between-microsoftidentitymodel-and-systemidentitymodel?forum=Geneva

【讨论】:

你也可以在 using 语句中定义一个别名,但我想这不是重点:问题是当它在错误的命名空间。这意味着您需要为它们中的每一个编写转换器或适配器类。这个答案不考虑这方面。 没错,Thomas(别名),但您可以使用完整格式的参数(引用命名空间/类)。无论如何,为什么存在冲突(用户的最后一个问题)的答案就在上面。 如果 Microsoft.Identity* 在 .NET 4.5 中已被弃用,为什么 ASP.NET Core 的 JwtBearerOptionsclass 使用其中的类型进行配置? 在 5.0 中不再是这种情况。为了使 System.IdentityModel.TokensJwt 更轻,该库再次依赖于 Microsoft.IdentityModel.Tokens 问题集中在两个方面:1)库制造商正在引用 NET 框架的更轻/更快的代码(命名空间); 2) 但 MS 警告说这些功能在 NET 4.5 中已弃用。为什么?只有 lib 制作者才能提供答案。【参考方案2】:

如果你看一下

的依赖关系

nuget System.IdentityModel.Tokens.Jwt 4.0.2

nuget System.IdentityModel.Tokens.Jwt 5.0

你会看到 5.0 依赖于

依赖关系

.NETFramework 4.5.1

Microsoft.IdentityModel.Tokens (>=5.0.0)

4.0 没有。事实上,以前的版本没有。

Microsoft 正在重新构建他们的框架,使其更轻量级。在 ASP.NET 大小的框架中,您将有许多功能冗余。

为了使 WIF 更轻巧,同时保持向后兼容,我们决定从 System.IdentityModel.Tokens.Jwt 等库中删除冗余功能,不再依赖于 System.IdentityModel.Tokens,而是依赖于 Microsoft.IdentityModel.Tokens。不幸的结果之一是两个层都暴露了相同的方法。

【讨论】:

我也看到了这种依赖关系——所以这很可能是故意的,可能是设计使然,即使它会造成混乱。知道这是否会永远持续下去,或者这两个命名空间中的一个是否最终会获胜? @wrschneider,这仍在团队之间决定。他们知道冲突,但这种方式仍然向后兼容 @DaveAlperovich 这是一个很好的答案,但你能弄清楚我们应该使用哪个版本吗? Microsoft.IdentityModel.Tokens 是旧版本的库吗?还是新的? @TarkaDaal,我看到了混乱。 Microsoft.IdentityModel.TokensOLDER 库。它已作为依赖项重新引入。 System.IdentityModel 已作为依赖项被删除。如果可用,您应该始终使用System.IdentityModel.Tokens.Jwt 方法和类。这种向后兼容的轻量级架构的不幸部分是依赖库公开了相同的方法。理想情况下,Microsoft.IdentityModel.Tokens 将是私有方法或不同的名称。我希望我是在澄清而不是进一步混淆......

以上是关于.NET JWT 令牌验证的命名空间:系统与 Microsoft的主要内容,如果未能解决你的问题,请参考以下文章

asp.net 核心中的 JWT 身份验证验证

JWT/OAuth 令牌签名验证失败

ASP.NET Core 中的 Jwt 令牌身份验证

.Net Core 2.1 过期的 JWT 令牌响应 [发布与获取]

.Net Core API JWT 令牌验证

如何对 ASP.NET WebApi 的每个请求应用自定义验证到 JWT 令牌?