网络调用/.well-known/openid-configuration/和/.well-known/openid-configuration/jwks [英] Network calls /.well-known/openid-configuration/ and /.well-known/openid-configuration/jwks

问题描述

我有:

• 身份服务器4，
• 具有OpenId Connect和混合流的Mvc应用程序
• WebApi应用

假设用户已经获得了带有id_token和访问令牌的cookie. 然后他从mvc应用程序调用了一个动作:

 var client = new HttpClient();
 client.SetBearerToken(accessToken);
// call webapi from mvc
 var content = await client.GetStringAsync("http://localhost:5001/api/resource-with-policy");

在提琴手中，我看到两个电话:

• 获取/.well-known/openid-configuration/

• 获取/.well-known/openid-configuration/jwks

因为我假设WebApi在执行时看到[Authorize]属性并进行这些调用. 这些电话的目的是什么?

WebApi的配置方式如下:

              .AddJwtBearer("Bearer", options =>
              {options.Authority = "<is4-url>";
                  options.RequireHttpsMetadata = false;
                  options.Audience = "Api1";
              });```

解决方案

由安全令牌服务在私钥中签名的JWT令牌. JWT令牌是未加密的数字签名JSON有效负载，其中包含用于标识用户的不同属性(声明).签名是JWT的最后一部分，需要用于验证有效负载.此签名是使用标头(例如，RS256)中描述的算法生成的，以防止未经授权的访问.请参考此处是一个代码示例.

I have :

• Identity server 4,
• Mvc app with OpenId Connect and Hybrid flow
• WebApi app

Assume user already got cookies with id_token and access token. Then he calls an action from mvc app:

 var client = new HttpClient();
 client.SetBearerToken(accessToken);
// call webapi from mvc
 var content = await client.GetStringAsync("http://localhost:5001/api/resource-with-policy");

In fiddler i see two calls:

• GET /.well-known/openid-configuration/

• GET /.well-known/openid-configuration/jwks

As i assume WebApi sees [Authorize] attribute on action and make these calls. What's purpose of these calls?

WebApi is configured this way:

              .AddJwtBearer("Bearer", options =>
              {options.Authority = "<is4-url>";
                  options.RequireHttpsMetadata = false;
                  options.Audience = "Api1";
              });```

解决方案

The JWT token which is signed by Security Token Service in private key. A JWT token is a non-encrypted digitally signed JSON payload which contains different attributes (claims) to identify the user. The signature is the last part of the JWT and needs to be used for verification of the payload. This signature was generated with the algorithm described in the header(RS256 for example) to prevent unauthorized access.Please refer to this document for more details about JWT token .

To validate signature , firstly we should retrieve and cache the singing tokens (public key) :1)The first call is to the discovery endpoint. It's URL is formed as /.well-known/openid-configuration .2) Then you will find lots of metadata here including the jwks_uri endpoint address which will send get request to get the keys to validate the token's signature .

Token signing is implemented according to JSON Web Key spec. Using Key ID and X.509 certificate thumbprint values from the token's header (kid and x5t parameters respectively) and then find the appropriate public key in the obtained collection of keys to verify the signature with n(Modulus) and e(Exponent). Here is one code sample .

这篇关于网络调用/.well-known/openid-configuration/和/.well-known/openid-configuration/jwks的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！