问题描述
我的Web应用程序（OAuth2客户端）通过使用OAuth2框架向单独的授权服务器发出请求来授权用户。对于每个用户登录，我的应用都会生成一个state值，该值最终会根据授权响应进行验证。
我的问题是用户将授权服务器页面标记为进入我的Web应用程序的快捷方式，因为这是输入凭据的地方。授权服务器很乐意将其作为“新”请求来处理，但是带有书签的请求上的state在我的应用中不再有效，因为它不再与我的应用中发起的请求相关。尽管对凭据进行了完全有效的验证，但我的应用当前仍会生成一条错误消息，这对用户来说非常不高兴。
我研究了其他应用程序是如何完成的，并注意到了差异。对于某些网站，这不是问题（例如Stack Overflow！），但是其他网站（例如Auth0）会产生错误消息：
您可能已按下“后退”按钮，在登录过程中刷新，打开了太多登录对话框或cookie出现问题，因为我们找不到您的会话。尝试从应用程序重新登录，如果问题仍然存在，请与管理员联系。
我的产品经理希望我实施“堆栈溢出行为”，并接受登录才能获得更好的用户体验；但我倾向于Auth0实际上可以确保请求源自我的应用程序。
我的问题是处理此问题的正确方法是什么，希望同时满足安全性需求和可用性需求。换句话说，假设堆栈溢出不是不安全的，它的工作方式与Auth0的工作方式有何不同？
更新：堆栈溢出技术支持已响应：
我们的开发人员仔细研究了一下，非常感谢这份报告！我们传递给OAuth2端点的“状态”已经过验证，并且不能永久重用-对其进行书签仅会在状态被视为无效之前的一个小时内起作用。此外，除非用户的计算机/浏览器受到破坏或HTTPS连接受到破坏以允许MITM攻击，否则获取其中一个URL并非易事-的CSRF风险非常低。
也就是说，我们将在此处进行更改，以确保该状态为一次性使用，只是为了消除任何疑问。我没有解决方案的预计到达时间，但直到我们收到为止，我都会将此票保持打开状态。
解决方法
要一般使用Auth0或OpenID-Connect / Oauth2，必须始终从客户端启动身份验证过程，对auth0加书签将永远无法工作，因为Auth0应该重定向到谁？我们希望客户端重定向到应用程序信任的身份提供者。
很多内置的安全功能（PKCE / Nonce / State）都要求客户端为第一步。
在堆栈溢出的情况下，我怀疑他们使用纯OpenID-connect来获得单点登录体验，因为它们都在其自己的控制下（域，应用程序...），他们可以根据自己的需要定制和定制登录体验自己的需求。