.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.Jwt
5.0.0
我不明白的是,为什么命名空间在Microsoft
和System
之间混合使用。
例如:
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 的JwtBearerOptions
class 使用其中的类型进行配置?
在 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.Tokens
是 OLDER 库。它已作为依赖项重新引入。 System.IdentityModel
已作为依赖项被删除。如果可用,您应该始终使用System.IdentityModel.Tokens.Jwt
方法和类。这种向后兼容的轻量级架构的不幸部分是依赖库公开了相同的方法。理想情况下,Microsoft.IdentityModel.Tokens
将是私有方法或不同的名称。我希望我是在澄清而不是进一步混淆......以上是关于.NET JWT 令牌验证的命名空间:系统与 Microsoft的主要内容,如果未能解决你的问题,请参考以下文章