Accueil > OpenID Connect OAuth Serveur dédié > 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, SSO, 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 : OpenID Connect Session Management), ou bien une nouvelle fonctionnalité à ajouter [2] à OpenID Connect. C’est ce qu’offre OAuthSD, voir : SLI, SSO, 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-domaines 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.

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

En cas d’échec de l’authentification, il serait donc nécessaire de présenter un dialogue à l’utilisateur final. Mais c’est précisément ce que nous ne voulons pas.
Puisqu’il faut respecter la norme OIDC, il faut s’accommoder du fonctionnement du serveur et traiter les différents cas du côté de l’application, ou plus exactement au niveau du module d’interface (plugin) OIDC.

Première méthode (sans ID Token, avec cookie SLI) : dans un espace contrôlé par une même organisation (corporate realm), la technique du cookie SLI offert par OAuthSD devrait être mis en œuvre pour toutes les applications clientes. Il est alors possible de vérifier la connexion de l’utilisateur auprès du serveur puis de décider ce qui doit être fait en cas de non-connexion, ce qui peut conduire à rester silencieux. Cette méthode est celle que nous pratiquons dans le cadre du monitoring.

Deuxième méthode (avec ID Token) : On interroge Authorize avec prompt = ’none’ et id_token_hint, voir : id_token_hint : ré-authentification silencieuse du sujet avec l’ID Token.