AddJwtBearer() 是否按照我的想法行事? [英] Does AddJwtBearer() Do what I think it does?

问题描述

我正在尝试确定为 .net core 3.0 提供的 JwtBearer 服务是否真的使用了由我的 oidc 提供商众所周知的配置提供的非对称签名密钥???

I am trying to determine if the JwtBearer Service provided for .net core 3.0, does it actually use the asymettric signing key that is provided by my oidc providers well known configuration???

我找不到有关此的任何文档.

I can't find any documentation around this.

.AddJwtBearer(opt =>
                    {
                        opt.Authority = "http://localhost:8180/auth/realms/master";
                        opt.TokenValidationParameters = new Microsoft.IdentityModel.Tokens.TokenValidationParameters
                        {
                            ValidateIssuer = true,
                            ValidateAudience = false,
                            ValidateLifetime = true,
                            ValidateIssuerSigningKey = true
                        };

我使用 Keycloak 4.8.3 作为我的 oidc 提供程序.我能找到的最接近的文档在这里.https://developer.okta.com/blog/2018/03/23/token-authentication-aspnetcore-complete-guide

I am using Keycloak 4.8.3 as my oidc provider. The closest documentation I could find was here. https://developer.okta.com/blog/2018/03/23/token-authentication-aspnetcore-complete-guide

相关部分在这里:

如果你让 JwtBearer 中间件通过发现文档自动配置，这一切都会自动运行！

If you let the JwtBearer middleware auto-configure via the discovery document, this all works automatically!

上面的代码做了所有这些吗?由于我们不再注册中间件，这在 3.0 中仍然相关吗??

Did that above code do all that? Is this still relevant in 3.0 since we don't register the middleware anymore??

我敢打赌，很多人不知道非对称签名密钥，也不知道它们为何如此重要.我们从开发者那里抽象出来了这么多，现在我什至不知道我的 api 是否安全.

I bet a lot of people don't know about Asymetric Signing keys, and why they are so important. We have abstracted away so much from the developer, that now I don't even know if my api is secure.

所以最后一个问题是.带有ValidateIssuerSigningKey"的 .AddJwtBearer 服务是否会定期检查众所周知的或任何发现文档以获取最新的非对称签名密钥?

推荐答案

我也在想同样的问题 - 研究/调试表明 JwtBearer 确实试图联系权威以获取公钥.

I was wondering same - research/debugging showed that JwtBearer indeed trying to contact authority to get public key.

这是在验证过程中调用的函数:

Here is function called during validation :

// System.IdentityModel.Tokens.Jwt.JwtSecurityTokenHandler.cs

protected virtual SecurityKey ResolveIssuerSigningKey(string token, JwtSecurityToken jwtToken, TokenValidationParameters validationParameters)
            {
                if (validationParameters == null)
                    throw LogHelper.LogArgumentNullException(nameof(validationParameters));

                if (jwtToken == null)
                    throw LogHelper.LogArgumentNullException(nameof(jwtToken));

                return JwtTokenUtilities.FindKeyMatch(jwtToken.Header.Kid, jwtToken.Header.X5t, validationParameters.IssuerSigningKey, validationParameters.IssuerSigningKeys);
            }

显然，只有当您在配置中设置 Oauth 权限时，才会调用此联系公钥权限的逻辑:

Obviously this logic to contact authority for public key is called only when you set Oauth authority in your configuration:

 .AddJwtBearer(o =>{
     o.Authority = "https://authorityUri/";
 })

AddJwtBearer 中间件处理程序在内部将.well-known/openid-configuration"字符串添加到 o.Authority 并将尝试获取带有授权服务器详细信息的 JSON.(谷歌示例:https://accounts.google.com/.well-known/openid-configuration).

AddJwtBearer middleware handler internally will add ".well-known/openid-configuration" string to o.Authority and will try to fetch JSON with details of authority server. (Google example: https://accounts.google.com/.well-known/openid-configuration).

下一步 - 获取 jwks_uri，(如果是 google https://www.googleapis.com/oauth2/v3/certs) 并获取 jwks 文件，该文件将包含用于签名验证的数据(公钥、算法、初始向量).

Next step - get jwks_uri, (in case of google https://www.googleapis.com/oauth2/v3/certs) and fetch jwks file, which will have data used for signature validation (publicKey, algorithm, initial vector)..

在所有这些步骤之后，JwtBearer 验证令牌签名.

After all this steps, JwtBearer validates token signature.

仅供参考 - 如果您使用自己的签名密钥颁发者对其进行配置，JwtBearer 可以在没有权限的情况下验证令牌，如下所示:

Just for info - JwtBearer can validate token without authority if you configure it with your own Signing Key issuer, like this:

.AddJwtBearer(o =>{
         o.TokenValidationParameters.IssuerSigningKey = GetKey();
         //in this case you need to provide valid audience or disable validation
         o.TokenValidationParameters.ValidateAudience = false
         //in this case you need to provide valid issuer or disable validation
         o.TokenValidationParameters.ValidateIssuer= false
     })

Microsoft.IdentityModel.Tokens.SecurityKey = GetKey(){
            var key = "Secret_Pass";
            return new SymmetricSecurityKey(Encoding.UTF8.GetBytes(key));
}

在这种情况下，您需要提供发行者和受众或禁用验证.此配置可用于 B2B 案例 - 服务器到服务器的通信 - 当您没有 Oauth 服务器并使用共享密钥自行发布令牌时.

In this case you need either provide issuer and audience or disable validation. This configuration can be used for B2B cases - server to server communications - when you don't have Oauth server and issue tokens yourself using shared secret.

有关此配置的完整图片 - 权限和颁发者密钥集:

For the full picture look at this configuration - both authority and issuer key set:

 .AddJwtBearer(o =>{
     o.Authority = "https://authorityUri/";
     o.TokenValidationParameters.IssuerSigningKey = GetKey();
 })

在这种情况下，不会触及权限，并且您本地生成的密钥将用于验证令牌，因此优先级是 TokenValidationParameters.IssuerSigningKey.意味着没有理由添加权限.

In this case authority will not be touched and your locally generated key will be used to validate token, so priority is TokenValidationParameters.IssuerSigningKey. Means no reason to add Authority.

这篇关于AddJwtBearer() 是否按照我的想法行事?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！