identityserver4 踩坑之不同API的ClaimsPrincipal获取用户信息的Type不一致

在微服务项目中使用的Identityserver4,给各个API添加认证时看到下面两种方式,写法一是原始的写法,写法二是Identityserver4封装的写法,主要是在根据token获取用户信息时存在差异。

写法一获取用户ID时的claim的type是 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier  ,对应System.Security.Claims下的 ClaimTypes.NameIdentifier

写法二获取用户ID时的claim的type是 sub,对应IdentityModel下的 JwtClaimTypes.Subject

如果你获取用户信息的方法在项目中不是公用的,那你可以分开写,每个API写自己的获取信息;如果你获取用户信息的方法在项目中是公用的那就要统一认证写法了,不然就有问题,我就是这个有问题的。

因为使用的认证方法不一样,对应的解析结果也不一样,然后有些API就报错了。

 

string IdentityUrl= Configuration["IdentityUrl"];
       // 写法1
            //services.AddAuthentication("Bearer")
            //     .AddJwtBearer("Bearer", options =>
            //     {
            //         options.Authority = IdentityUrl;
            //         options.RequireHttpsMetadata = false;
            //         options.Audience = "orderapi";
            //     });
            //微服务中保持结构一致,要么多个API服务都使用上面的结构,要么统一用下面的结构,不一致会对 ClaimsPrincipal 解析不一致

       // 写法2 services.AddAuthentication(options => { options.DefaultScheme = IdentityServerAuthenticationDefaults.AuthenticationScheme; options.DefaultAuthenticateScheme = IdentityServerAuthenticationDefaults.AuthenticationScheme; options.DefaultChallengeScheme = IdentityServerAuthenticationDefaults.AuthenticationScheme; options.DefaultSignInScheme = IdentityServerAuthenticationDefaults.AuthenticationScheme; options.DefaultForbidScheme = IdentityServerAuthenticationDefaults.AuthenticationScheme; }) .AddIdentityServerAuthentication(options => { options.Authority = IdentityUrl; options.ApiName = "orderapi"; options.RequireHttpsMetadata = false; });

 

这是我获取用户ID的方法

 

public static int GetUserId(ClaimsPrincipal User)
        {
            
            var claim = User.Claims.Where(a => a.Type == JwtClaimTypes.Subject).FirstOrDefault();
            return Convert.ToInt32(claim.Value);
        }

 

identityserver4 踩坑之不同API的ClaimsPrincipal获取用户信息的Type不一致

上一篇:用 express 框架写api


下一篇:C#工作总结(一):Fleck的WebSocket使用