我有一个使用identityserver和facebook身份验证的出色的webassembly项目。从Webassembly调用api控制器时，在使用设置httpclient.AddHttpMessageHandler<BaseAddressAuthorizationMessageHandler>()并将useridclaimtype映射到nameidentifier后，一切工作都很好。可通过访问该用户UserManager.GetUserAsync。
现在，我尝试添加一个纯服务器控制器，其视图希望用户能够直接从浏览器进行浏览。但是，直接浏览到服务器视图时，尽管进行了设置，但似乎没有身份验证：
app.UseIdentityServer();
app.UseAuthentication();
app.UseAuthorization();
和
services.AddDefaultIdentity<ApplicationUser>(options => options.SignIn.RequireConfirmedAccount = true)
.AddRoles<IdentityRole>()
.AddEntityFrameworkStores<ApplicationDbContext>();
services.AddIdentityServer()
.AddApiAuthorization<ApplicationUser, ApplicationDbContext>();
services.AddAuthentication()
.AddIdentityServerJwt().AddFacebook(facebookOptions =>
{
facebookOptions.AppId = Configuration["id"];
facebookOptions.AppSecret = Configuration["idpwd"];
});
services.Configure<IdentityOptions>(options => options.ClaimsIdentity.UserIdClaimType = ClaimTypes.NameIdentifier);
我曾期望中间件通过此设置为我自动进行身份验证。但是，即使我先登录并携带.AspNetCore.Identity.Application cookie，该用户仍然无法通过usermanager进行访问。我只会得到一个没有名称和声明的空白标识，并且如果我Authorize向控制器添加属性，则会得到401。
我是否缺少一些秘密成分来使它起作用？我对中间件应该为我做什么有错误的期望吗？
经过一番尝试并比较了可以正常工作的标准asp.net核心项目和我的项目。似乎这是杀死服务器端控制器的行：
services.AddAuthentication().AddIdentityServerJwt()
如果我不添加AddIdentityServerJwt()，则控制器表现良好，可以在需要授权时重定向我，并正确登录。谁能向我解释为什么？AddIdentityServerJwt()中间件是否与返回视图的控制器不兼容？
在我看来，添加AddIdentityServerJwt（）增加了以下要求：每个请求都需要带有承载令牌的授权标头，blazor客户端httpclient提供了此请求。但是，当浏览器直接进行呼叫时，承载令牌丢失，并且管道也不会尝试对用户进行身份验证以获取一个。
发生了什么
控制器端点上AuthorizeFilter的特定混合以及身份验证构建器上AddIdentityServerJwt的用法可能是这里的罪魁祸首。AddIdentityServerJwt将Jwt身份验证方案添加为默认身份验证方案，该默认身份验证方案由AddAuthentication方法中传递身份验证方案名称指示。这意味着与此Jwt身份验证方案（JwtBearerHandler）关联的处理程序将是通过其HandleChallengeAsync方法发出401的类。请注意，此方法没有用于进一步操作的重定向，这就是为什么看不到重定向的原因。
为什么会这样呢？
由于控制器端点上的AuthorizeFilter，因此调用了JwtBearerHandler上的HandleChallengeAsync方法。执行AuthorizeFilter的方法是OnAuthorizationAsync方法（在初始化过滤器后立即调用）。由于没有在控制器上的Authorization属性中指定任何策略（在中没有传递任何参数作为参数[Authorize]），因此最终使用了默认授权策略。默认策略基本上检查是否有任何身份验证方案已经成功验证了您的身份（通过查看HttpContext中的身份），如果没有，则返回质询的响应。此挑战默认为默认身份验证方案的挑战，这就是为什么在JwtBearerHandler上调用HandleChallengeAsync的原因。
您可以在此处了解有关策略的更多信息，并在此处了解有关AuthorizationFilter（以及一般的过滤器）的更多信息。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句