OpendID Connect and IDP Initiated SSO

Question

I have an application which is a Service Provider. Is it possible to implement an Idp initiated SSO with OpenID Connect?
It looks like for Idp initiated SSO only SAML could be used, is that correct? Or is there a way to make OpenID Connect work as well? I'm thinking of using some open source tools like Keycloak or OneLogin toolkit etc..

Thanks so much.

Answer 1

Secure IDP-initiated-SSO is not possible with OpenID Connect in its current form. There is however a feature called 3rd-party-initiated-SSO which allows for launching the authentication process via a 3rd-party but that still visits the RP first.

Here are details about third-party initiated SSO:

https://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin

As to the IDP-init suggestions described: a well-behaved RP should prevent this from happening - as technically it enables CSRF - by using the state parameter or (as a less-preferred and less-secure solution) by keeping request state in a cookie which makes the RP vulnerable to CSRF only during the request/response roundtrip.

There's a work-in-progress that describes - amongst other things - how true IDP-init-SSO can be achieved with an extension to OpenID Connect in a secure way using a signed message: https://datatracker.ietf.org/doc/html/draft-bradley-oauth-jwt-encoded-state#section-4.3

Answer 2

Since OpenIDConnect is OAuth2 based, the IdP initiated SSO should technically be possible but under one condition - the SP doesn't rely on the state passed down to the IdP in the intial request where the state acts like an anti-forgery token (i.e. upon the return request the returning state is compared to the state sent by the SP in the initial request).

The longer answer would be:

The first step of the authorization code OAuth2 flow is the SP redirecting to the IdP and the IdP redirects back with the one time code. The state parameter is often passed by the SP and the SP expects the state be passed back.

There are two cases.

The SP verifies the state (e.g. compares it to the state stored in a temp cookie). The IdP SSO won't work as there is no way the IdP knows/forges the state and thus it cannot issue a valid request to the SP that would act as the IdP initiated SSO.

The SP doesn't verify the state. The IdP can then issue the response to a regular OAuth2 request but without the actual request, i.e. it redirects to

 https://sp.com/oauth2?code=...authcode

and the SP picks the OAuth2 handhshake from there as if it was the SP to first initiate the handshake.

In other words, whether the IdP initiated SSO is possible, it only depends on the SP. Since the spec recommends using state to prevent such behavior (classified there as CSRF), I believe you are on your own here. Also, read more on possible security issues around the state parameter.

3.1.2.1. Authentication Request […] state - RECOMMENDED. Opaque value used to maintain state between the request and the callback. Typically, Cross-Site Request Forgery (CSRF, XSRF) mitigation is done by cryptographically binding the value of this parameter with a browser cookie.