Accueil > OpenID Connect OAuth Server par DnC > Développer > OpenID Connect > SSO et connexion unique (Single Login Identification, SLI)

SSO et connexion unique (Single Login Identification, SLI)

Une fonctionnalité attendue de la délégation d’autorisation, que l’on associe naturellement à l’inscription unique (Single Sign On, SSO) est la capacité donnée à l’utilisateur final de ne se connecter qu’une seule fois pour accéder à différentes applications (Single Login Identification, SLI).

De façon standard, les flux d’OpenID Connect ne permettent pas de réaliser directement le SLI, mais des possibilités existent. On est là sur une technique peu divulguée, qui nécessite des développement significatifs du côté des applications.

A côté de ces méthodes standard, OAuthSD offre l’option de gérer le SLI et la ré-authentification silencieuse sans nécessiter de code spécifique du côté des applications clientes. Ceci est traité dans cet article : SLI, SLO et SRA sont dans un bateau : OAuthSD.

SSO et SLI

Le SSO n’implique pas automatiquement le SLI
Lorsque l’on évoque SSO ( Single Sign On ), on englobe souvent deux fonctionnalités :
- le fait de ne s’enregistrer (sign on [1]) qu’une seule fois sur un serveur d’identité et de pouvoir se connecter (entrer son login et son mot de passe) sur différentes applications sans avoir à s’enregistrer sur chacune d’elle. C’est à proprement parler le SSO.
- le fait de se connecter à une application ( sign in ) et de naviguer vers une autre sans avoir à entrer à nouveau son login et son mot de passe. Il s’agit de la Connexion Unique Single Connection, Single Login Identification (SLI).

Si le SSO est dans la nature même de OAuth 2 et OpenID Connect, il n’en est pas de même pour le SLI. En revanche, OpenID Connect offre "tout ce qu’il faut" pour le réaliser. Sans pour autant présenter de flux particulier pour cela : c’est donc une fonctionalité à développer du côté des applications (voir : Draft : Management de session OpenID Connect), ou bien une nouvelle fonctionnalité à ajouter [2] à OpenID Connect. C’est ce qu’offre OAuthSD, voir : SLI, SLO et SRA sont dans un bateau : OAuthSD .

Bien entendu, le SLI n’est possible que dans un ensemble d’applications liées à un même serveur d’identité, c’est à dire dans un espace de réseau et d’applications contrôlé par une même entité (corporate realm).

Applications situées dans le même domaine

Dans le cas d’applications situées dans le même domaine (par exemple dans diférents sous-domaine d’un domaine principal, en plus de ce domaine lui_même), une solution simple est de partager le cookie de session entre les applications. Pour cela, le concepteur des applications enregistrera le cookie pour le domaine principal au lieu de l’enregistrer pour le sous-domaine des applications (paramètres cookie_domain et cookie_path).

Cependant, les scopes sont particuliers aux applications. L’application cible doit donc ré-interroger le serveur d’autorisation pour obtenir un JWT qui lui soit propre.

Applications situées dans des domaines différents

Dans le cas d’applications situées dans des domaines différents le problème est un peu plus complexe.
La transmission d’autorisation est réputée sans solution sûre avec les flux OpenID Connect standard. En effet, l’application cible doit obtenir la certitude de l’origine du jeton reçu, et donc de l’identité de l’utilisateur final, sans pouvoir lui imposer une nouvelle demande d’identification. C’est à cela que sert la demande d’authentification silencieuse.

Demande d’authentification silencieuse (Silent Re-Authentication, SRA)

Le protocole OpenID Connect prend en charge un paramètre prompt = none sur la demande d’authentification qui permet aux applications d’indiquer que le serveur d’autorisations ne doit afficher aucune interaction de l’utilisateur (telle que l’authentification, le consentement). OAuthSD renverra la réponse demandée à l’application ou renverra une erreur si l’utilisateur n’est pas déjà authentifié, ou si un type de consentement ou une invite est requis avant de continuer.

Erreurs et suites

Les valeurs possibles pour ERROR_CODE sont définies par la spécification OpenID Connect :

- login_required : l’utilisateur n’était pas connecté à OAuthSD, l’authentification silencieuse n’est pas possible.
L’utilisateur doit être redirigé vers la page de connexion OAuthSD (sans le paramètre prompt =’none’) afin de s’authentifier.

- consent_required : l’utilisateur était connecté à OAuthSD, mais l’application attend son consentement (pour lequel il faudrait afficher une invite, ce qui est exclu par prompt=’none’).
D’après la norme, l’utilisateur devrait être redirigé vers la page de connexion OAuthSD comme précédemment.

Nous avons deux solutions :

  • éviter cette situation en considérant que les applications sont des applications de confiance, connues des utilisateurs, ou que les utilisateurs sont suffisamment avertis par ailleurs (par exemple en leur présentant les conditions générales du site à approuver lors de leur première connexion directe à l’application). Il suffira de modifier le flux pour ne pas retourner une erreur.
  • modifier le flux pour présenter la demande de consentement plutôt que retourner une erreur.

- interaction_required : l’utilisateur était connecté à OAuthSD et a autorisé l’application, mais doit être redirigé ailleurs avant que l’authentification ne puisse être complétée, par exemple, lors de l’utilisation d’une règle de redirection.
D’après la norme, l’utilisateur devrait être redirigé vers la page de connexion OAuthSD.
Cette situation ne devrait pas se produire dans un espace contrôlé par une même organisation (corporate realm), dans lequel le SLI devrait être mis en œuvre pour toutes les applications clientes. On se ramène donc aux deux cas précédents.

Ces erreurs sont retournées à l’application cliente qui a tenté la connexion. Ceci implique des développements significatif des applications clientes. Heureusement, il y a OAuthSD !

Remarque de sécurité :
Interroger Authorize avec prompt = ’none’ sans id_token_hint ne peut être considéré comme une authentification de l’utilisateur, mais comme une simple information sur sa connexion.
Voir : id_token_hint : ré-authentification silencieuse du sujet avec l’ID Token.

OAuthSD va plus loin ...

A côté de ces méthodes standard, OAuthSD offre l’option de gérer le SLI et la ré-authentification silencieuse sans nécessiter de code spécifique du côté des applications clientes : c’est le controleur authorize qui se charge de tout le travail.