我们目前正在评估Keycloak作为我们的SSO解决方案，虽然它适用于我们基于servlet的应用程序，但我们（基于React的）SPA有一个问题。
我们的设计师想要什么：例如，假设我们有一个电子邮件客户端spa。用户正在撰写电子邮件，但随后会分心。当他返回SSO会话时已经超时并且需要重新登录。现在应该向用户提供登录表单，登录后应该可以发送仍在SPA本地存储中的电子邮件（即重新登录而不重新启动SPA或丢失数据）。
AFAIK Keycloak不提供身份验证-api（出于好的理由），并使用重定向到登录页面并返回应用程序（据我所知，对于移动应用程序，系统浏览器将被使用）。如果我没有弄错，那么重定向会意味着SPA会重新初始化，因此数据会丢失。
所以这就是问题：我们的设计师想要用Keycloak做什么？
如果是，将如何做？直接发布到Keycloak正在使用的login-url似乎是一个坏主意，因为令牌可能无法正确存储，并且可能存在同源策略问题。会在iframe或popup窗口中进行吗？
答案 0 :(得分：2)
对于回到这个问题的人，
我认为最好遵循SPA的oAuth2 / OpenId Connect的最佳做法，该做法目前是PKCE的“授权代码流”。
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13
这里的正常流程需要完全重定向到身份验证服务器，然后再返回，以便您的应用程序将完全重新初始化。或者，您可以使用静默模式中已经提到过的Sébastien这样的check-sso。
您可以配置无提示check-sso选项。启用此功能后，您的浏览器将不会完全重定向到{project_name}服务器并返回到您的应用程序，但是此操作将在隐藏的iframe中执行，因此您的应用程序资源仅需要通过以下方式加载和解析一次：应用程式初始化时的浏览器，而不是从{project_name}重新导向回您的应用程式后的浏览器。这对于SPA（单页应用程序）尤其有用。
通过这种方式，登录将在iframe中进行，并且该应用仅初始化一次并应保留状态。
答案 1 :(得分：1)
即使它不被视为最佳做法，您也可以为您的客户启用直接授权访问，以便通过REST呼叫登录。
无论如何，关于没有丢失你的应用程序的状态，这有点超出了Keycloak的范围，但是你应该能够通过在重定向URL中拥有状态来实现这一点吗？
此外，如果您不希望自己的应用自动重新登录到登录页面，则可以使用：keycloak.init({ onLoad: 'check-sso' })代替login-required