在我的应用程序前面添加 NGNIX 代理后，我在身份服务器 4 上遇到奇怪的错误。
我的 .net core 身份服务器正在 Docker 容器上的端口 8080 上运行
Ngnix 代理（使用 https://github.com/nginx-proxy/nginx-proxy）配置为将 443 路由到 docker 容器 8080
在回调端点上成功进行身份验证后，无法验证伪造令牌。
奇怪的部分是整个场景适用于我在 .net core 应用程序启动时播种的用户。但通过我的 API 创建的新的失败。
任何想法或教导都值得赞赏。
由 ASP.NET core 发出的会话 cookie 使用数据保护 API 进行加密。
用于签署 cookie 的密钥存储在密钥环中。如果您现在重新部署应用程序并且尚未正确配置它，则将在新密钥环中颁发新的加密密钥。
如果无法找到用于加密 cookie 的密钥，则意味着所有客户端浏览器中现有的会话 cookie 无法再解密。
请参阅这篇关于此 API 的文章以及这篇关于如何配置它的文章。
这适用于您的 IdentityServer 和客户端应用程序，因为两者都使用数据保护 API，因此两者都需要有一个永久密钥环。当您重新部署容器时，密钥环将丢失，除非您已将密钥环放置在文件系统上的某个永久卷中或以其他方式保留它。 API 支持很多地方存储密钥环，包括数据库、redis、Azure Key Vault..
如果您想了解有关如何保护 cookie 以及如何查看 cookie 内部的更多信息，请转到此博客文章： 探索 ASP.NET Core cookie 中的内容
我在我的暂存环境中遇到了这个问题（产品和本地都可以） Tore Nestenius 的回答帮助我弄清楚了。
我实际上重新安装了所有的临时环境。所以密钥存储是新的，但不是我的浏览器，它使用旧的 cookie 运行网站。这向我展示了：
System.Security.Cryptography.CryptographicException：在密钥环中找不到密钥。
只需清除您的cookie即可！
这将从新商店更新密钥。
我们构建仅供内部使用的内部网络应用程序。 关闭此功能，或者更好的是，默认情况下不启用它会更好。 在我们的应用程序中使用它已经超出了工程设计的范围。 我尝试使用“builder.Services.AddDataProtection().DisableAutomaticKeyGeneration();”但这并不成功。 我需要进一步深入研究他们的代码，看看如何为我们的内部应用程序永久关闭它。
有时会出现这个问题，当我们在IIS中发布项目时，另外我们使用实体框架核心，并且您的连接字符串中的身份验证是Windows身份验证并且设置不正确，您可能会得到相同的错误，因此如果将其更改为SQL认证，你的问题或许就能解决。