SLI, SLO and SRA are in a boat: OAuthSD

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

As part of OpenID Connect flows, in addition to the Single Sign On (SSO) function, the OAuthSD server implements the Single Login Identification (SLI) function, the Single Login Out (SLO). as well as Silent Re-Authentication (SRA) [1]. This without modifying the application interface code with OIDC, all being taken into account at the authorize controller.

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.

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’).

There is more information, sign in to view them.