Kyl*_*yes 4 javascript pingfederate openid-connect
假设用户使用 OpenID Connect 的隐式客户端流登录我的应用程序（其中 OP 为 PingFederate），如果用户已关闭应用程序并在有效时间内返回，我如何确定用户是否仍然登录。时间段？
由于 OpenID Connect 仍在广泛使用，因此又出现了一个老问题。要检查用户是否已通过身份验证（无论是从与您的应用程序的先前会话还是从与另一个联合应用程序的会话），请prompt=none在身份验证请求中提供。根据规范，文档prompt=none说明：
授权服务器不得显示任何身份验证或同意用户界面页面。如果最终用户尚未经过身份验证，或者客户没有对所请求的声明预先配置同意，或者不满足处理请求的其他条件，则会返回错误。错误代码通常是 login_required、interaction_required 或第 3.1.2.6 节中定义的其他代码。这可以用作检查现有身份验证和/或同意的方法。
prompt=none“静默身份验证”在 iFrame 内使用此参数。Auth0对此有一些讨论，在这里。简而言之，身份验证请求是在不可见的 iFrame 中发出的，因此用户代理的主框架不会被重定向。根据您的身份提供商 (IdP)，这可能是也可能不是有效的选项。出于安全原因，授权端点通常会拒绝使用X-Frame-Options: DENY标头在帧中发出的请求。IdP 上的 Cookie 来源策略也可能会阻止静默身份验证。也就是说，同样可以通过在 SPA 初始加载时弹出或完整的用户代理重定向来实现。
值得指出的是，由于存在广泛的安全问题，其中许多问题没有足够的缓解策略，隐式流已被弃用很长时间。基于浏览器的应用程序的 OAuth 2.0描述了当前的最佳实践。如今，可以使用带有 PKCE 的代码流，但它仍然存在许多无法充分缓解的安全问题（在最佳实践文档中再次描述）。
在边缘设备（SPA 和 API 服务器之间的服务器）中使用后端会话服务器的代码流是安全方面的最佳选择。这种方法将令牌完全排除在用户代理之外，有助于减少 XSS 攻击造成的令牌泄漏，如果操作正确，CSRF 攻击将变得无效。关于这个问题，长期刷新令牌可以存储在会话服务器中，并可用于在页面刷新或关闭浏览器时保持身份验证。 这是关于这种方法的文章。
针对上述评论之一：“为什么在完成 authN 后关闭网站的用户会期望 AuthN 在关闭后仍然有效？” 因为它是更好的用户体验，也是当今预期的用户体验。想想 Google、Atlassian，甚至这个网站 (StackOverflow)：用户登录一次，几乎不需要再次登录，前提是用户经常与网站交互并且不会引发任何安全危险信号。
针对另一条评论：“如果应用程序现在拥有‘ID 令牌’，那就是关键。只要令牌有效（检查到期时间）。” ID 令牌和访问令牌都应该很快过期，而刷新令牌应该长期存在。这样，如果 IdP 撤销用户的访问权限，该撤销将快速传播到所有客户端应用程序。