C# 如何在Web Api应用程序中验证IdentiyServer发布的Jwt令牌

我使用IdentiyServer向客户机发出JWT令牌，令牌包含角色声明和一些其他声明，这部分工作正常，我获得了具有所需声明的访问令牌

在我的web API应用程序中，我添加了以下代码以支持JWT身份验证：

 services.AddAuthentication(options =>
            {
                options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
                options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
            })
            .AddJwtBearer(options =>
            {
                options.RequireHttpsMetadata = false;
                options.Authority = "http://localhost:5004";
                IdentityModelEventSource.ShowPII = true;
                options.TokenValidationParameters = new TokenValidationParameters()
                {
                    ValidateAudience = false,
                    ValidateIssuer = false,
                    ValidateLifetime = false,
                    ValidateIssuerSigningKey = true,
                    IssuerSigningKey = "what is this ?"
                };

问题是，假设一个黑客生成了一个JWT令牌，该令牌具有任何头部和主体，并声明他想要并签名，那么我的web api应用程序如何验证签名？如何与identityServer和web api应用程序共享IssuerSigningKey

IssuersingKey与identityServer中的ClientSecrets相同吗

---

我查阅了IdentityServer文档，但找不到答案。

虽然黑客可以生成带有某些头和声明的伪造JWT，但他不能使用服务器的私钥对令牌进行签名，除非他还攻击您的服务器以窃取密钥。因此，在实践中，JWT通常在令牌的末尾带有校验和，这是基于令牌内容和服务器密钥的哈希。如果您的服务器接收到传入JWT且校验和未验证，则应拒绝该JWT。

当您使用AddJWTBear时，它将从您的IdentityServer下载公共签名密钥(http://localhost:5004)并使用该公钥验证接收到的JWT令牌中的签名是否由预期的颁发者颁发。默认情况下，AddJwtBearer将每24小时刷新一次下载的公钥

不需要在API中设置的IssuerSigningKey。通常，您应该在TokenValidationParameters对象中禁用尽可能少的检查

在生产环境中，您应该尝试将ShowPII设置为false，否则令牌和其他机密可能会出现在日志中

IssuersingKey与identityServer中的ClientSecrets相同吗

不，它们是两个不同的东西。ClientSecret就像客户机的密码，当它根据IdentityServer进行身份验证时

---

在IdentityServer中设置的签名密钥，它表示公共/私有签名密钥。密钥可以是RSA或ECDSA密钥。

< P>在看似的问题中，使用OAuthor或开放ID服务器的完整OAuth流并不十分清楚，让我们考虑各种问题和选项。

我正在使用IdentiyServer向客户端发出JWT令牌，令牌包含角色声明和一些其他声明，这部分工作正常，我获得了带有所需声明的访问令牌。

让我们将身份验证服务器与授权分离，通常当我们集成任何社交登录时，它们所做的是提供一个访问令牌，我们使用回调在服务器上生成一个JWT身份验证令牌，我们像后端服务器一样控制它

两者有什么区别？

身份验证服务器通常只知道很少关于我们的详细信息，大多数情况下他们只是验证电子邮件并返回成功，他们没有能力分配角色和其他详细信息，这些信息因应用程序而异

那我们该怎么办

接收访问令牌，从中获取电子邮件等详细信息，获取与该电子邮件相关的所有详细信息，创建json有效负载，使用对称（仅一个密钥）或非对称加密（生成私钥-公钥对）的算法，更清楚地查看了解JWT的详细信息。在对称加密中，我们使用相同的密钥进行编码/解码，而在非对称加密中，我们使用私钥进行编码，使用公钥进行解码。正如您在JWT中检查的那样，编码和解码只是意味着哈希

header.payload

，并比较两者以确保不被篡改

关于加密类型和黑客的剩余问题：

非对称加密更强大、更安全，但会降低性能

如果客户端Ui（Javascript）不需要解码JWT，那么对称加密就足够了

在非对称加密中，每个客户端都有一个公钥，而主令牌使用私钥签名，如果令牌被更改/篡改，则解码密钥将失败，从而导致错误。匹配键只是比较

header.jsonpayload

在对称加密中，有一个onky 1密钥保留在服务器上，用于解码客户端传递的jwt令牌

通过网络嗅出JWT令牌的黑客别无选择，只能使用相同的令牌，否则令牌解码将失败，所以最好的选择是模拟，但这在时间到期之前也是好的，这就是为什么有一个刷新令牌，它无缝地刷新访问令牌，插入的应用程序将生成新的JWT令牌。现在也有针对冒充的检查，当有人试图从未知机器登录时，为什么会弹出消息

为什么在每次调用中，我们都不去identity server，因为这会使令牌验证过程变慢，这也是生成JWT的原因

对web api的每次调用都应使用插入式中间件来解码/验证令牌并继续，只有在JWT令牌过期时才应重新登录/验证

ASP.Net Web API特定更改

我使用Fast API在Python中编写代码，我们所做的是使用一个

中间件

，它类似于Asp.Net中的拦截器/过滤器，它将拦截对控制器/API的所有调用，获取令牌，解码，验证并允许调用继续进行，或者抛出一个错误以重新登录，请注意，编码发生在身份验证服务器的

回调中。Python中的示例代码

对于C#来说，此链接是一个不错的选择

您可以在这里看到代码，其中添加了显式过滤器以验证令牌。它使用一个decorator，
[Authorize]
来调用授权过滤器

public static void Register(HttpConfiguration config) {  
 // Web API configuration and services    
 config.SuppressDefaultHostAuthentication();  
 config.Filters.Add(new HostAuthenticationFilter(OAuthDefaults.AuthenticationType));  
  
 // Web API routes    
 config.MapHttpAttributeRoutes();  
  
 config.Routes.MapHttpRoute(  
  name: "DefaultApi",  
  routeTemplate: "api/{controller}/{action}/{id}",  
  defaults: new {  
   id = RouteParameter.Optional  
  }  
 );  
}  

如何在web api上验证签名？我应该使用公钥来验证签名吗？我对您的API或.NET不太了解，无法回答