如何在 Web Api 應用程序中驗證 IdentiyServer 頒發的 Jwt 令牌

Question

我正在使用 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 ?"
                };

The question is, suppose a hacker generates a JWT token with whatever header and body and claims he wants and signs it, how does my web api application validate the signature? 如何與 identityServer 和我的 web api 應用程序共享 IssuerSigningKey？

IssuerSigningKey 是否與 IdentityServer 中的 ClientSecrets 相同？

我瀏覽了 IdentityServer 文檔，但找不到答案。

Answer 1

雖然黑客當然可以生成偽造的 JWT 和一些 header 並聲稱，但他無法使用服務器的私鑰簽署令牌，除非他還入侵您的服務器以竊取密鑰。 因此，在實踐中，JWT 通常在令牌末尾帶有校驗和，即基於令牌內容和服務器密鑰的 hash。 如果您的服務器收到傳入的 JWT 並且校驗和未驗證，那么它應該拒絕該 JWT。

Answer 2

當您使用 AddJwtBearer 時，它將從您的 IdentityServer (http://localhost:5004) 下載公共簽名密鑰，並使用此公共密鑰來驗證收到的 JWT 令牌中的簽名是否由預期的頒發者頒發。 AddJwtBearer 默認每 24 小時刷新一次下載的公鑰。

您不需要在 API 中設置 IssuerSigningKey。 一般來說，您應該在 TokenValidationParameters object 中禁用盡可能少的檢查。

在生產環境中，您應該嘗試將 ShowPII 設置為 false，否則令牌和其他機密等內容可能最終會出現在日志中。

IssuerSigningKey 是否與 IdentityServer 中的 ClientSecrets 相同？

不，它們是兩個不同的東西。 ClientSecret 就像客戶端的密碼，當它針對 IdentityServer 進行身份驗證時。

您在 IdentityServer 中設置的 SigningKey 代表公鑰/私鑰簽名密鑰。 密鑰可以是 RSA 或 ECDSA 密鑰。

Answer 3

在看起來的問題中，使用 OAuth 或 Open Id 服務器的完整 OAuth 流程不是很清楚，讓我們考慮各種問題和選項。

我正在使用 IdentiyServer 向客戶端發出 JWT 令牌，令牌包含角色聲明和其他一些聲明，這部分工作正常，我得到了帶有所需聲明的訪問令牌。

讓我們將身份驗證服務器與授權分開，通常當我們集成任何社交登錄時，它們所做的是提供訪問令牌，我們使用回調在我們的服務器上生成 JWT 授權令牌，我們像后端服務器一樣控制它

兩者有什么區別？

認證服務器一般對我們了解的很少，大多只是驗證 email 並返回成功，無法分配角色等細節，因應用而異

那我們該怎么辦？

接收訪問令牌，從中獲取諸如 email 之類的詳細信息，獲取與該email相關的所有詳細信息，創建 json 有效負載，或使用對稱加密算法與對稱公鑰（僅一個）更清楚地了解有關 JWT 的詳細信息。 在對稱加密中，我們使用相同的密鑰進行編碼/解碼，而在非對稱加密中，我們使用私鑰進行編碼並使用公鑰進行解碼。 正如您將在 JWT 中檢查的那樣，編碼和解碼只是意味着散列header.payload並比較兩者以確保沒有篡改

關於加密類型和黑客的剩余問題：

1. 非對稱加密更強大、更安全，但它有性能損失
2. 如果客戶端 Ui (Javascript) 不需要解碼 JWT 那么對稱加密就足夠了
3. 在非對稱加密中，每個客戶端都有一個公鑰，而主令牌使用私鑰簽名，如果令牌被更改/篡改，則解碼密鑰將失敗，從而出錯。 匹配鍵只是比較 header.jsonpayload 的header.jsonpayload
4. 在對稱加密中，保留在服務器上的 onky 1 密鑰用於解碼客戶端傳遞的 jwt 令牌。
5. 通過網絡嗅出 JWT 令牌的黑客，別無選擇，只能使用相同的令牌，否則令牌解碼將失敗，因此最好的選擇是模擬，但這也很好，直到時間到期，這就是為什么有一個刷新令牌，它無縫刷新訪問令牌，插入的應用程序將生成新的 jwt 令牌。 現在也有針對假冒的檢查，為什么會在嘗試從未知機器登錄時彈出消息
6. 為什么在每次調用中，我們都不 go 到身份服務器，因為這會使令牌驗證過程緩慢，這也是生成 JWT 的原因
7. 對 web api 的每次調用都應使用插入的中間件來解碼/驗證令牌並繼續進行，重新登錄/身份驗證僅在 JWT 令牌過期時發生

ASP.Net Web API 具體改動

I code in Python using Fast API, what we do is use a middleware , which is similar to interceptor / filter in Asp.Net, which will intercept all the calls to the controller / api, fetch the token, decode, verify and allow the調用以繼續或拋出錯誤以重新登錄，請注意編碼發生在來自身份驗證服務器的callback中。 Python、 https://pyjwt.readthedocs.io/en/latest/usage.html中的示例代碼

對於 C# 這個鏈接是一個不錯的選擇， https://www.c-sharpcorner.com/article/asp-net-web-api-2-creating-and-validating-jwt-json-web-token/

在這里您可以看到代碼，其中添加了顯式過濾器以驗證令牌。 它使用裝飾器[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  
  }  
 );  
}