我们有一个网络应用程序，我们允许用户使用任何Open ID提供商（例如Okta，Google，Facebook等）登录应用程序。我们希望实施正确的Open ID Connect规定的方法/工作流程，以保持用户登录网站。
现有的实现，查看访问令牌的到期，然后如果它接近到期使用刷新令牌来获取新的访问令牌以保持用户登录。我觉得这是错误的。当用户登录Web应用程序时，Identity Token用于使用授权代码工作流验证用户的身份。访问令牌和刷新令牌存储在服务器端。刷新令牌定期用于获取新的访问令牌以保持用户登录站点。我认为这是一个安全隐患，因为 -
想象一下，如果用户在浏览器中登录了他的OP帐户。他打开Sky并直接登录MP，因为他已登录MP。然后，他在一个单独的选项卡中，退出他的OP帐户。他将在此刷新令牌/访问令牌机制的基础上继续登录MP数天！这不是安全隐患吗？
如果感觉正确的方法是使用OIDC中规定的iframe使用会话管理 - https://openid.net/specs/openid-connect-session-1_0.html
有关更多上下文，当用户登录我们的WebApp时，我们从OP的UserInfo端点提取数据，以在WebApp中创建配置文件，并根据从OP的UserInfo端点发送的数据在我们的应用程序中设置权限/角色。我们会定期继续这样做。为此，我觉得使用访问令牌（并使用刷新令牌来获取新的访问令牌）来访问UserInfo API是正确的，因为它符合使用访问令牌保护/授权API /资源端点的OAuth 2.0概念。
我想知道这是否确实是管理用户在支持Open ID Connect时应该如何登录的正确方法。
我认为第一个问题是您是否要将OpenID Connect提供程序Single Sign On会话的生命周期与应用程序的会话绑定。您只想使用其OpenID Connect服务对用户进行身份验证。如果我退出Google，我希望退出GMail，但不会使用Google进行身份验证的第三方应用程序。您是否也想实施单点注销？
但是如果我想在你注销OpenID Connect提供程序时注销，我会实现OpenID Connect Session management。使用iframes和cookies时有一件事需要注意 - 浏览器可以选择“阻止第三方cookie”（这就是Chrome调用它的方式），默认情况下它是关闭的，但据我所知，它会禁用打开时的SSO功能。
我不确定为什么要定期请求userinfo端点。如果您只想检查访问令牌是否仍然有效，您还可以使用token introspection endpoint。
出于安全考虑，我建议你阅读OAuth 2.0 for Browser-Based Apps RFC。它建议使用带有PKCE的auth代码流而不是隐式流。使用隐式流，在重定向URL中传输的访问令牌将保留在网络和浏览器缓存中，并且可以立即被攻击者使用。使用PKCE的auth代码需要code_verifier（一次性密码）才能交换令牌。因此，我首先会检查提供程序如何使用您选择的配置以及是否支持它。