如何解决代理oauth SSO流的风险有多大?
因此,我有多个项目,api等...并且我想拥有一个中央登录系统。因此,我转向SSO和openId PKCE流。
假设我想使用某种云解决方案来节省时间和金钱-假设,假设AWS cognito与AWS产品良好集成。
现在让我们说,与竞争对手和我的需求相比,我的云解决方案在许多方面仍然有一半支持,例如,我们可以想象oauth sso登录页面的托管ui无法正确定制或翻译,这是不行的。
现在,我们可以想象我们了解了oauth PKCE代码授予流程,并且我们构建了一个小型服务器或几个lambda,以代理oauth实现,以便我们可以构建替代的前端。服务器将:
-
使用客户端应用程序提供的code_challenge进行初始授权请求,获取状态-或在认知到csrf令牌的情况下-将其返回给我们的“自定义登录字体”。
-
“自定义登录前端”可以使用csrf,登录名和密码来调用我们的服务器,然后我们的服务器将调用oauth云解决方案的登录端点,并检查响应是否为重定向返回我们提供的代码的回调-抓取该代码并将其返回到登录前端,以便在一个不错的加载程序完成移动之后最终进行重定向。
这样做会很不好,尤其是如果我们无法在主机上托管登录前端和服务器,则知道到我们的oauth云解决方案的登录POST请求可能必须设置不诚实的“ HOST”标头才能使请求通过与我们的oauth云解决方案相同的域?
最后,我有道理吗?
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。