SSO and Single Login Identification (SLI)

All the versions of this article: [English] [français]

One expected feature of authorization delegation, which is naturally associated with Single Sign On (SSO), is the ability given to the end user to log in only once to access different applications (Single Login Identification, SLI).

In a standard way, OpenID Connect flows do not allow direct SLI realization, but possibilities exist. We are here on a little disclosed technique, which requires significant development on the application side.

OAuthSD offers the option of managing SLI and silent re-authentication without the need for specific code on the side of client applications. This is discussed in this article: SLI, SLO and SRA are in a boat: OAuthSD.

SSO and SLI

SSO does not automatically imply SLI
When we think about SSO (Single Sign On), we often include two features:
the fact of only registering once (sign on [1]) on an identity server and being able to connect (enter his login and password) on different applications without having to register on each one. It is strictly speaking the SSO.
to connect to an application and navigate to another without having to re-enter your login and password. This is the Single Connection or Single Login Identification (SLI).

If the SSO is in the nature of OAuth 2 and OpenID Connect, it is not the same for the SLI. However, OpenID Connect offers "everything you need" to achieve it. Without presenting a particular flow for this: it is therefore a functionality to develop on the side of applications (see: OpenID Connect Session Management), or a new feature to add [2] to OpenID Connect. This is what OAuthSD offers, see: SLI, SLO and SRA are in a boat: OAuthSD.

Of course, SLI is only possible in a set of applications linked to the same identity server, ie in a network and application space controlled by the same entity (corporate realm).

Apps in the same domain

In the case of applications located in the same domain (for example in different subdomains of a main domain, in addition to this domain itself), a simple solution is to share the session cookie between the applications. For this, the application designer will save the cookie for the primary domain instead of saving it for the application subdomain (cookie_domain and cookie_path settings).

However, scopes are unique to applications. The target application must therefore re-query the authorization server to obtain a JWT of its own.

Apps located in different domains

In the case of applications located in different domains the problem is a little more complex.
Authorization forwarding is known to have no secure solution with standard OpenID Connect flows. Indeed, the target application must obtain certainty of the origin of the received token, and therefore the identity of the end user, without being able to impose a new identification request. This is what Silent Re-Authentication, SRA is made for.

Silent Re-Authentication Request (SRA)

The OpenID Connect protocol supports parameter prompt = none on the authentication request that allows applications to indicate that the authorization server should not display any user interaction (such as authentication , the consent). OAuthSD will return the requested response to the application or return an error if the user is not already authenticated, or if a consent type or prompt is required before continuing.

Errors and actions

The possible values for ERROR_CODE are defined by the OpenID Connect specification:

login_required: The user was not logged in to OAuthSD, silent authentication is not possible.
The user must be redirected to the OAuthSD login page (without prompt = ’none’) in order to authenticate.

consent_required: The user was connected to OAuthSD, but the application is waiting for its consent (for which a prompt should be displayed, which is excluded by prompt = ’none’).
According to the standard, the user should be redirected to the OAuthSD login page as before.

We have two solutions:

avoid this situation by considering that the applications are trusted applications, known to the users, or that the users are sufficiently informed otherwise (for example by presenting them the general conditions of the site to be approved at their first direct connection to the user. ’application). It will be enough to modify the flow not to return an error.

edit the feed to submit the consent request rather than return an error.

interaction_required: The user was logged in to OAuthSD and allowed the application, but must be redirected elsewhere before authentication can be completed, for example, when using a redirect rule .
According to the standard, the user should be redirected to the OAuthSD login page.
This situation should not occur in a corporate realm, where the SLI should be implemented for all client applications. So we come back to the two previous cases.

These errors are returned to the client application that attempted the connection. This involves significant developments in client applications. Fortunately, there is OAuthSD!

Security note:
Querying Authorize with prompt = ’none’ without id_token_hint can not be considered as a user authentication, but as a simple information about its connection.
See: id_token_hint : Silent Re-authentication of subject with ID Token.

OAuthSD goes further ...

In addition to these standard methods which require adaptation of applications, OAuthSD offers the option of manage SLI and silent re-authentication without requiring specific code on the side of the client applications: the authorize controller supports all the work.