OpenID Connect : SSO, session management etc.

SSO (Single Sign-On) : This is a mechanism that allows a user to log in once to access multiple applications, without having to log in again each time. With OAuthSD, SSO is set up to offer single authentication for a group of applications, thus preventing the same Internet user from having to authenticate several times to access different applications.

SLI (Single Login In) : SLI is a similar concept to SSO, but it focuses on the fact that once logged in, a user can access multiple applications without having to log in again. OAuthSD uses SLI to facilitate navigation and data exchange within a multiple application.

SLO (Single Log-Out)  : SLO is the counterpart of SSO, but for disconnection. It allows a user to log out just once to log out of all applications they are logged in to. This guarantees a global disconnection and reinforces security in the event of the user leaving their workstation.

SRA (Single Re-Authentication) : SRA is a mechanism that allows a user to seamlessly re-authenticate when an authentication cookie is no longer valid. This ensures enhanced security in the event of a need for re-authentication.

This article was written using i-Tego ChatBot, in response to the question : "Dans le contexte d’OAuthSD, expliquer SSO, SLI, SLO, SRA."

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.

The OAuthSD server code can be set to implement (or not) the SLI. Single Disconnect (SLO) and Silent Re-Authentication (SRA) are derived from SLI.

Single Identification Identification (SLI)

When the SLI is authorized (ENABLE_SLI = true) AND the client application has been registered on the server with the scope ’sli’, the authorize controller processes a authorization request without a prompt parameter like this :

 The presence of a SLI cookie} recorded on the agent in the server domain (and not in that of the application) is tested,
 if the SLI cookie is present, not expired and validated, it is used for authentication (the login form is not presented to the user), the controller returning the tokens to the client (the code authorization in the case of the authorization flow with code). At this time, the validity of the SLI cookie is refreshed to its initial value.
 In case of failure : either there is a standard return to the client with an error, or the controller presents the login form if the constant REAUTHENTICATE_NO_ROUNDTRIP is true. In either case, the SLI cookie is destroyed first.

 If the SLI cookie is missing :

• If the client application does not have the ’sli’ scope, the controller acts as standard.
• If the client application allows the SLI, and if the previously mentioned authentication succeeds, an SLI cookie is registered on the agent in the server domain. This is the only case where the SLI cookie is created.

Notes :
 Any "technical" error (other than the non-repeated errors of the user in the entry of his login or his password) leads to the destruction of the cookie SLI in order to protect the application against the attempts of intrusion. In such a case the server does not respond to not guide the attacker.
 An attempt to connect under a different user ID also causes the destruction of the SLI cookie, and leads to the presentation of the identification form.
 An attempt to connect from a different workstation has the same effect.
 SLI functionality is active in all three OpenID Connect streams, so with the most secure : Authorization with code. This is an advantage over often presented solutions using Implicit flow.
 The behavior of requests with prompt = ’none’, ’login’ and ’consent’ remains in compliance with the standard.
 When the user changes their application and benefits from SLI, consent requests will always be submitted once.

Single Logout Out (SLO)

The server exposes a new logout endpoint, which disconnects the user from all client applications.

The single disconnect request is done as an introspection request by providing the identity token.

When disconnection is performed, all access tokens stored on the server for the subject in question are erased. As a result, SLI cookies that may be present on the user’s agents will be destroyed if a connection attempt is made.

Note that client applications must handle the disconnect at their level, there is no miracle !

If you want to know the current connection status of an application, simply repeat the authentication request with prompt = ’none’. If the disconnection has occurred, the server will respond with ’login_required’. This solution has the advantage of fully meeting the OpenID Connect standard in its final state.

Silent Re-Authentication (SRA)

As part of the OAuthSD server, this feature is a direct result of the SLI [2].

For applications that do not allow SLI, they do not benefit from the SRA. But it is likely that the reasons that led to not allowing the SLI would lead to not authorizing the SRA.

Note that it is always possible to Rafraîchir (actualiser) un jeton d’accès.

See also : id_token_hint : Silent Re-authentication of subject with ID Token.

The SLI Cookie

The SLI cookie is a DnC-specific concept that allows the OAuthSD server to offer all the features of single sign-on (SLI, SLO, SRA, SLO) without modifying client applications provided they are already interfaced with OpenID Connect. Given the complexity and diversity of the solutions proposed elsewhere, which have not made a definitive specification (early 2019), this is a major contribution of OAuthSD to OpenID Connect.

The SLI cookie is created by the Authorize controller if the SLI is authorized for the client application (scope ’sli’).

Introduction

OAuthSD, following OAuth 2.0, considers that the end user is connected to an application as long as the associated access token is valid.

There is no "naturally" direct relationship between this token and the local connection state of an application. Each application will have to set up a monitoring, client side, in order to :
 monitor the validity of the access token,
 complete the Single Logout (SLO) mechanism by causing local disconnection of the application when the access token has expired.

1. The community is offered a "standard" for managing the OpenID Connect session (see : OpenID Connect Session Management ) which relies on iframes on the server side and on the application side.

In version 30 published in August 2020, a section disappears that was present in version 28 and was entitled "Back-Channel Logout".
Indeed, a new proposal "OpenID Connect Back-Channel Logout" avoid the malfunctions that were mentionned in paragraph "User Agents Blocking Access to Third-Party Content" :

Note that at the time of this writing, some User Agents (browsers) are starting to block access to third-party content by default to block some mechanisms used to track the End-User’s activity across sites. Specifically, the third-party content being blocked is website content with an origin different that the origin of the focused User Agent window. Site data includes cookies and any web storage APIs (sessionStorage, localStorage, etc.).

This can prevent the ability for notifications from the OP at the RP from being able to access the RP’s User Agent state to implement local logout actions. In particular, cookies and web storage APIs may not be available in the OP frame loaded in the RP context. The side effect here is that, depending on the used mechanism (cookies or web storage), the data needed to recalculate session_state might not be available. Cookie based implementations might then return changed for every single call, resulting in infinite loops of re-authentications. Therefore, deployments of this specification are recommended to include defensive code to detect this situation, and if possible, notify the End-User that the requested RP logouts could not be performed. The details of the defensive code needed are beyond the scope of this specification ; it may vary per User Agent and may vary over time, as the User Agent tracking prevention situation is fluid and continues to evolve. ".

A specification proposal which has undergone 30 modifications but which has not changed since August 2020, and which also ends with a finding of malfunction, is dead !

Moreover, we think (maybe wrongly ?) that a "standard" for a protocol-level ISO layer should not impose a process on a lower-level layer.

2. Our solution presented here : Implementation of monitoring with Javascript : examples for SPIP and WordPress therefore interrogate the Authorize controller with the parameter display = "none".
A client-side implementation based on the OpenID Connect standard as it currently exists is much preferable to a further complication of client applications and helps avoid violation of the principle of ISO layer independence.

In support of this statement, we present monitoring methods implemented for SPIP and WordPress :

Implementation of the monitoring in the OpenID Connect client plugin for SPIP

The oa.dnc.global site uses this plugin (it is OIDC client, the snake is biting its tail !). You can see a label at the top left of the window that reflects the status of the access token linked to the current connection :

icon	Meaning
	The end user connection is not established with the OIDC server. Note that the user may have logged in to the application using the classic SPIP login method.
	The end user and the application are connected by OIDC.
	General error, unfortunately translates multiple situations :  loss of Internet communication,  default configuration of the plugin,  failure to register the client application on the OAuthSD server,  registration of the application on another server, not compatible with OAuthSD,  unknown login of the OAuthSD server (the end user is not registered on this server),  etc. The message may be more explicit : "authentication error", ...

The Monitoring also allows to manage the OIDC session and in particular to perform the global disconnection (SLO).
By clicking on the icon, popups appear depending on the connection status.

Example of the Javascript code (with jQuery) used for SPIP. The plugin inserts this code at the bottom of each page.
[SPIP]

Implementing monitoring in a Wordpress app

  The plugin is available on Github.

The Javascript code is inserted into a hook called by the bootstrap () function of the extension :

[PHP]

Note that you must insert a div block at the bottom of the page, which is done by means of an action in the bootstrap function at the same time as the hook of the previous function :

[PHP]