我目前正在处理一个有复杂需求的项目，我对正在考虑的解决方案感到不舒服。
其主要思想是在不修改现有应用程序的情况下保护现有应用程序(不包括安全性本身(。这些应用程序无法从外部访问，只能通过反向代理(OpenResty(访问。
用户不能访问所有的应用程序，识别用户的解决方案是Keycloft。
主要组件有：
- 一个棱角分明的入口：入口点
- 重定向所选应用程序上的用户的反向代理
- IAM：钥匙斗篷
- 所有可用的应用程序
这个模式解释它
想法是：
- 用户单击Keycloft登录，然后使用包含其角色(他可以访问的应用程序(的访问令牌(JWT(返回门户
- 用户单击门户上的应用程序，然后通过反向代理重定向到目标应用程序
- 反向代理检查令牌(exp、iss和角色(的有效性
我知道这不是在应用程序之间进行SSO的正确方法，但这里的要求是，未受保护的应用程序不能编辑，必须由前端系统(此处为反向代理(保护
我的问题是：好吧，这对第一次调用有效，因为用户在门户网站上有他的JWT令牌，第一次用它点击应用程序，但之后用户会点击该应用程序中的链接。。没有更多的象征了。这种体系结构可以很好地保护web应用程序的REST API bu，这听起来有点过时。
通常，您将使用反向代理服务器来处理用户身份验证，而不是首先登录到keycapture。
流程如下：
- 用户访问门户
- 门户通过反向代理将用户重定向到应用程序
- 反向代理将首先将用户重定向到身份验证，并在浏览器和反向代理服务器
- 反向代理转发请求到您的应用程序服务器
- 对于所有后续请求，用户总是通过反向代理服务器
尝试使用github.com/gambol99/keycaph-proxy。它将令牌存储在cookie中，这是web应用程序的更好选择。
警告：我猜任何身份验证代理都只能使用授权代码流，但建议将隐式流