.AddOpenIdConnect() 中间件说明

Question

因此，我尝试使用 ASP.NET Core 3.1 实现 OIDC 客户端应用程序。我正在尝试利用.AddOpenIdConnect()和.AddJswtBearer()中间件。但是，我需要澄清一下这个中间件的作用。

这是我目前的中间件配置：

.AddOpenIdConnect(options =>
{
    options.Authority = Configuration["auth:oidc:authority"];
    options.ClientId = Configuration["auth:oidc:clientid"];
    options.ClientSecret = Configuration["auth:oidc:clientsecret"];
    options.ResponseType = OpenIdConnectResponseType.Code;
    options.GetClaimsFromUserInfoEndpoint = true;
    options.SaveTokens = true;
})
.AddJwtBearer(options =>
{
    options.Authority = Configuration["auth:oidc:authority"];
    options.Audience = Configuration["auth:oidc:clientid"];
    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuer = true,
        ValidateAudience = true,
        ValidateLifetime = true,
        ValidIssuer = Configuration["auth:oidc:authority"],
        ValidAudience = Configuration["auth:oidc:clientid"],
        ValidateIssuerSigningKey = true,
        ClockSkew = TimeSpan.Zero
     };
}

我注意到，根据下面的 Fiddler 捕获，应用程序首次启动时会请求对授权服务器/.well-known/oidc-configuration和端点的请求/.well-known/keys

它在哪里做到这一点？

我还尝试验证从授权服务器收到的 JWT 是否有效（在服务器发送它的时间和客户端收到它的时间之间它没有被篡改）。TokenValidationParameters当我在中间件中添加对象时，我知道会发生这种情况.AddJwtBearer()。为了测试这一点，我尝试将 更改Valid Audience为我知道不是我的令牌的有效受众的TokenValidationParameters内容。asdkwewrj但是，我从未收到客户端的错误消息，称受众无效。身份验证仍然有效，我仍然能够访问我的安全仪表板。

我试图实现的另一件事是使用此 OIDC 客户端执行刷新令牌授予类型。我认为options.saveTokens中间件.AddOpenIdConnect()可以让我保存令牌。看起来它们保存为 cookie，但这些 cookie 看起来与我的令牌值完全不同（我的访问令牌是 JWT，但在我看到的 cookie 中，没有一个以 开头ey）。

简而言之，我试图理解以下内容：

1. 如果我有正确的定义（就像我上面所做的那样），这个.AddJwtBearer()中间件是否会为我验证 ID 令牌？JwtBearerOptions或者我是否需要根据 JWK URI 中的 JWK 手动验证 ID 令牌？
2. 如果我必须使用 JWKs URI 中的 JWK 手动验证 ID 令牌，那么当中间件向端点发出请求时，如何存储这些 JWK /.well-known/keys？
3. 如何获取与访问令牌和刷新令牌对应的 cookie，然后将刷新令牌发送到我的授权服务器？
4. 我注意到我可以在这两个中间件中使用 options.Events 。其中任何一个可以解决我想要完成的任何项目吗？
5. 总的来说，这两个中间件为我处理什么，我不需要手动执行（即令牌验证和/或令牌更新）？

谢谢你！我对这样的深入 ASP.NET 开发还很陌生，所以我很感谢您的回复。

Answer 1

首先，OIDC认证方案和JWT承载认证方案是相互独立的。OIDC 主要用于服务器端身份验证，几乎永远不会单独使用，而是始终与 cookie 方案一起使用。原因是 OIDC 方案仅用于身份验证，但无法自行保存信息。I\xe2\x80\x99ve在我的另一个答案中详细介绍了更多细节，该答案还解释了身份验证流程如何与 OIDC 配合使用。

\n

对于 JWT 承载，此身份验证方案将在每个请求上运行，因为它是完全无状态的，并且期望客户端Authorization始终使用标头对自己进行身份验证。这使得它主要用于保护 API，因为浏览器\xe2\x80\x99 无法为正常浏览器请求提供 JWT。

\n

因此，您应该首先问自己是否正在保护您的服务器端 Web 应用程序（例如使用 Razor 视图或 Razor 页面）（在这种情况下您希望使用 OIDC 和 cookies 身份验证方案），或者您是否正在保护您的 API。当然，答案可能是 \xe2\x80\x9cboth\xe2\x80\x9d 在这种情况下，您需要所有这三个方案，但 ASP.NET Core 将不支持这种情况，无需进一步配置。

\n\n

澄清这一点后，让\xe2\x80\x99s 回答你的问题：

\n

\n

0. 要求/.well-known/oidc-configuration和/.well-known/keysOIDC 和 JWT 承载方案完成，以便从您的身份提供商检索信息。他们将定期这样做来更新他们的数据，包括有关他们将用来验证令牌的签名密钥的信息。这发生在方案处理程序中，并且通常对您不可见。

   \n
\n

1. 正确设置后，JWT 持有者身份验证将为您验证令牌。它将通过使用检索到的签名密钥验证签名来实现这一点，然后它可能会检查其他属性，例如指定的受众或其生命周期。

   \n
\n

2. 您不应该\xe2\x80\x99 需要手动验证令牌。那\xe2\x80\x99就是认证方案的工作。您正在使用身份验证堆栈，因此您可以在应用程序中访问用户主体，而无需执行任何操作。

   \n
\n

3. Cookie 受到数据保护的保护，因此可以防止伪造。为了检索 存储的令牌，您可以在 HTTP 上下文中SaveTokens = true使用该方法。GetTokenAsync

   \n
\n

4. 您可以使用身份验证事件添加到身份验证方案的默认行为。为了使用标准机制验证您的令牌，您不应该\xe2\x80\x99 需要这样做。

   \n
\n

5. 只有一个中间件：身份验证中间件。它使用配置的身份验证方案来执行用户身份验证，以便\xe2\x80\x94一旦正确设置\xe2\x80\x94，经过身份验证的用户就可以在整个应用程序中使用，例如在控制器、MVC 过滤器、Razor 视图等中。

   \n
\n

\n

Answer 2

如果我定义了正确的 JwtBearerOptions（就像我上面所做的那样），这个 .AddJwtBearer() 中间件是否会为我验证 ID 令牌？或者我是否需要根据 JWK URI 中的 JWK 手动验证 ID 令牌？

AddJwtBearer 仅由 API 用于验证访问令牌并从中创建用户 (ClaimsPrincipal)。这就是它的全部作用。它不处理 id 令牌。

一般来说，将 API 放在单独的服务上更容易，以便更清楚谁在做什么。当您将客户端和 API 混合在同一个服务中时，可能会更难以推理。

如果我必须使用 JWKs URI 中的 JWK 手动验证 ID 令牌，那么当中间件向 /.well-known/keys 端点发出请求时，如何存储这些 JWK？如何获取与访问令牌和刷新令牌对应的 cookie，然后将刷新令牌发送到我的授权服务器？

ID 令牌由 AddOpenIdConnect 为您进行验证和处理。您不需要自己验证 ID 令牌。AddOpenIdConnect 将创建 cookie 并可选择将令牌存储在 cookie 中。

总的来说，这两个中间件为我处理什么，我不需要手动执行（即令牌验证和/或令牌更新）？

总结一下：

乌斯。AddOpenIdConnect ()为客户端，允许用户登录。

使用 。AddJswtBearer ()用于后端API。

令牌更新是一个不同的故事，他们都没有开箱即用的处理方式。为此，您可以考虑使用IdentityModel.AspNetCore或自己做一些事情。

为了补充这个答案，我写了一篇博客文章，更详细地介绍了这个主题：调试 ASP.NET Core 中的 OpenID Connect 声明问题