OpenID Connect OAuth Server dédié

Durée de la session locale

La ’durée de la session locale’ est définie par l’application. Généralement, après authentification, une application définit une durée de validité de la connexion qui en résulte, ou "durée de la session". Lorsque celle-ci a dépassé sa fin de vie ("la session a expiré"), une nouvelle authentification est demandée à l’utilisateur s’il tente une nouvelle action nécessitant l’authentification.

L’utilisateur perçoit la durée de la session locale en ayant la mauvaise surprise de se voir présenter une nouvelle demande de connexion. L’objet de la ré-authentification silencieuse est de prolonger la session de façon transparente.

Ré-authentification silencieuse (Silent Re-Authentication, SRA)

Avec OAuthSD, si l’application a autorisé le SLI, et si la demande d’authentification est effectuée sans définir le paramètre prompt, il y a ré-authentification silencieuse (SRA) : plutôt que présenter un dialogue d’authentification, le contrôleur OpenID Authorize :
 vérifie l’existence d’un cookie SLI valide,
 vérifie que le jeton d’accès associé à l’authentification n’a pas expiré
pour répondre immédiatement avec un nouveau code d’accès [1].

L’application cliente poursuit normalement avec une demande de jetons.

Les effets de bord sont les suivants :
 le serveur rafraîchit le cookie SLI dont la durée de vie est étendue de SLI_COOKIE_LIFETIME [2] secondes,
 le jeton d’accès (Access Token) est renouvelé avec une durée de vie étendue de ACCESS_TOKEN_LIFETIME secondes,
 le jeton d’identité (ID Token) est renouvelé avec une durée de vie étendue de ID_TOKEN_LIFETIME secondes.

Rapport entre les durées de vie

Le contrôleur Authorize considère que l’utilisateur final est connecté si le jeton d’accès n’a pas expiré. On en déduit une première règle :
 Le SRA ne peut fonctionner que si ACCESS_TOKEN_LIFETIME > ’durée de la session locale’.

Si l’utilisateur n’effectue plus d’action nécessitant l’authentification (sur une des applications authentifiées avec SLI), le cookie SLI expirera SLI_COOKIE_LIFETIME après le dernier SRA, ce qui est un terme mal déterminé pour l’utilisateur [3]. Ceci incite à :
 fixer une durée de vie du cookie SLI assez importante, typiquement plusieurs fois la ’durée de la session locale’.

Pour ce qui est de la durée de vie du jeton d’identité (ID Token), qui joue le même rôle que le jeton d’accès, il parait adéquat de :
 fixer la durée de vie ID_TOKEN_LIFETIME égale à celle du jeton d’accès.

Valeurs par défaut de la configuration d’OAuthSD

Le valeurs suivantes sont adoptées par défaut dans le fichier configure.php :
ACCESS_TOKEN_LIFETIME : 7200s
ID_TOKEN_LIFETIME : 7200s
SLI_COOKIE_LIFETIME : 7200s x 3
Une ’durée de la session locale’ de 3600s serait cohérente avec ces valeurs.

Notons que le SRA sondera le contrôleur Authorize au rythme de ’durée de la session locale’ tant que l’utilisateur effectue des actions nécessitant l’authentification.

Considérations relatives à la sécurité

Si l’utilisateur n’effectue plus d’action nécessitant l’authentification sur une application donnée, celle-ci se déconnectera localement après ’durée de la session locale’. En effet, le SRA ne fonctionne que sur une demande d’authentification, elle-même déclenchée par une action de l’utilisateur après la fin de vie de la session locale. Pour autant, le serveur considérera l’utilisateur comme connecté tant que le jeton d’accès n’a pas expiré, et effectuera une reconnexion silencieuse à la première action nécessitant l’authentification. Dans ce cas, il est important de se rendre compte que la déconnexion locale n’est qu’apparente.

On pourrait donc considérer que le SRA ne va pas dans le sens de la sécurité. En effet, la limitation de durée des sessions a pour objet de déconnecter automatiquement les applications ouvertes sur un un poste de travail abandonné par son utilisateur.
Cependant, même les durées de session les plus courte sont rarement inférieures à 15mn. Ce temps est largement suffisant pour permettre une compromission.
Ce n’est donc pas tant le SRA qui est en cause, mais le fait d’abandonner sans surveillance une session ouverte.

La seule bonne parade est de déconnecter systématiquement toutes les applications avant de quitter son poste de travail, c’est le but de la Déconnexion unique (Single LogOut, SLO).

Que faire si la durée de session locale est mal connue ou non maîtrisée ?

Il arrive que la durée de la session locale soit variable ou extensible. C’est par exemple le cas lorsque le dialogue de connexion à l’application comporte une option du genre "Conserver ma connexion" ou "Se souvenir de moi" etc.
Dans ce cas, la ’durée de la session locale’ peut être beaucoup plus grande que la durée de vie fixée pour les jetons et le mécanisme SRA ne fonctionne pas, ou n’a pas vraiment d’objet.

Si malgré tout on veut absolument faire fonctionner le SRA, y compris sur de très longues ’durée de la session locale’, il est toujours possible de programmer l’application cliente pour qu’elle rafraîchisse systématiquement le jeton d’accès. Cela doit être fait avant qu’il n’arrive à péremption, sinon la déconnexion unique ne fonctionnera pas pour cette application.

Du point de vue de la sécurité, notons que le mécanisme SLI + SRA fera en sorte que toutes les applications pour lesquelles le SLI est autorisé, et auxquelles l’utilisateur sera connecté à partir du même poste de travail, hériteront de cette extension de la durée de vie apparente de leur session.