小编kkl*_*klo的帖子

我不清楚应该将哪个 id 标头放入请求和响应中以用于关联目的。

“X-Correlation-ID”和“X-Request-ID”是已知的 http 标头。我在请求和响应中使用哪一个重要吗？

ASP.NET Core 的 System.Diagnostics.DiagnosticSource 查找“Request-Id”。这仅用于活动目的吗？为什么不使用“X-Request-ID”？

如果我不使用 Activity，我就不需要发送该标头，对吗？

ASP.NET Core 也有 我喜欢这个想法的分层请求 ID ( https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/HierarchicalRequestId.md )。我可以做这样的事情

    var newRequestId = $"{context.Request.headers["X-Correlation-ID"]}:{CreateNewGuid()}";

还是使用活动更好？我发现 Activity.Current 始终为空。是否需要启用它是否会影响性能？

我有一个 ASP.NET Core 应用程序，它使用 cookie 身份验证并在 Web 场上运行。数据保护密钥存储在 DB 中。我的应用程序实现了 IXmlRepository，ASP.NET Core 将调用 IXmlRepository.GetAllElements 来获取密钥环。因此，所有节点中的应用程序都使用相同的密钥环，并且在节点 1 中加密的 cookie 可以在节点 2 中解密。它工作正常。

但是，数据保护密钥将过期，ASP.NET Core 将生成新密钥。ASP.NET Core 还会缓存密钥，并将每 18-24 小时刷新一次。所以，当key过期时，Node1可能会生成一个新的key，但是其他所有的节点可能不会马上刷新并得到新的key。节点 1 加密的 Cookie 无法在所有其他节点中解密。

ASP.NET Core 如何处理这种情况？

我读了这个https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/web-farm?view=aspnetcore-2.2，它指出

默认配置通常不适用于在 Web 场中托管应用程序。实现共享密钥环的另一种方法是始终将用户请求路由到同一节点。

用户使用该节点登录后，这是将所有请求路由到同一节点的唯一选择吗？

由于 JWT 令牌是独立的，因此可以在资源服务器本地验证它，并且资源不需要将令牌发送到 IdentityServer IntroSpection 端点进行验证。

我检查IdentityServer4.AccessTokenValidation的实现，如果 IdentityServerAuthenticationOptions 设置为支持 JWT，它会在本地验证 JWT 令牌。使用 JWT 令牌的 IntroSpection 端点的唯一方法是将 IdentityServerAuthenticationOptions 设置为仅支持引用。

是否有任何特殊情况需要将 JWT 访问令牌发送到 IntroSpection 端点？

对于本地不具备加密能力的资源服务器，是否应该获取引用令牌而不是 JWT 令牌？

根据ASP.NET 密钥管理，

删除密钥确实是破坏性行为，因此数据保护系统没有公开任何一流的 API 来执行此操作。

即使该密钥已过期，过期的密钥是否仍可用于解除先前受该密钥保护的数据的保护？

过期的密钥是否会永远保留，即使它可能不再有任何受其保护的数据？

如果密钥寿命很短并且永远不会被删除，那么 ASP.NET Core 中用于查找匹配密钥的哈希表是否会永远增长？

我找不到任何文件或指南来说明如何处理过期的数据保护密钥。我想知道处理它的最佳实践。

提前致谢。

也许我应该问一下Identity令牌的用途是什么.我认为它用于识别用户,它可以传递给其他服务(例如后端服务),并且该服务使用id_token来验证它是否是有效用户？但我没有看到任何当前可用的端点来验证id_token.如果没有,应该从一个服务传递到另一个服务以验证用户？

获取id_token参数的唯一终点是End Session Endpoint,它作为id_token_hint传递.但在这种情况下,为什么IdentityTokenLifetime默认只有300秒？我不希望用户在300秒内结束会话.