我有一个应用程序，它是服务提供商。
是否可以通过OpenID Connect实现由Idp发起的SSO？
看起来对于Idp启动的SSO，只能使用SAML，对吗？还是有办法使OpenID Connect也能正常工作？
我正在考虑使用一些开源工具，例如Keycloak或OneLogin工具包等。
非常感谢。
答案 0 :(得分：3)
由于OpenIDConnect是基于OAuth2的，因此从技术上讲，IdP发起的SSO应该是可行的，但在一种情况下-SP并不依赖初始请求中传递给IdP的状态，该状态类似于 anti -forgery令牌（即，在返回请求时，将返回状态与SP在初始请求中发送的状态进行比较）。
更长的答案是：
授权码 OAuth2流程的第一步是SP重定向到IdP，而IdP则用一个时间码重定向回去。 SP通常会传递state参数，并且SP希望状态被返回。
有两种情况。
SP验证状态（例如，将其与临时cookie中存储的状态进行比较）。 IdP SSO无法工作，因为IdP无法知道/伪造状态，因此它无法向SP发出有效请求，该请求将充当IdP发起的SSO。
SP不验证状态。然后，IdP可以向常规OAuth2请求发出响应，但没有实际请求，即它重定向到
https://sp.com/oauth2?code=...authcode
SP会从那里选择OAuth2握手，就好像SP是首先启动握手一样。
换句话说，IdP发起的SSO是否可能，仅取决于SP。由于spec 建议使用state来防止这种行为（在此处归类为CSRF），因此我相信您自己就在这里。另外，请阅读有关state参数的可能的安全问题的详细信息。
3.1.2.1。身份验证请求[…]状态-推荐。用于保持请求和回调之间状态的不透明值。通常，跨站点请求伪造（CSRF，XSRF）缓解是通过将此参数的值与浏览器cookie进行密码绑定来完成的。
答案 1 :(得分：3)
使用当前形式的OpenID Connect无法获得安全的IDP发起的SSO。但是，有一个称为3rd-party-initiated-SSO的功能，该功能允许通过3rd-party启动身份验证过程，但仍然首先访问RP。
关于所描述的IDP-init建议：行为良好的RP应该防止这种情况的发生-从技术上讲，它通过使用state参数来启用CSRF，或者（作为较不受欢迎且较不安全的解决方案），将请求状态保存在cookie中，使RP仅在请求/响应往返期间才容易受到CSRF的攻击。</ p>
有一个正在进行的工作，除其他外，它描述了如何使用签名消息https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state#section-4.3