Déconnexion unique pour les applications OIDC

Modifier en ligne

Grâce à la déconnexion unique (SLO), les utilisateurs peuvent se déconnecter simultanément de toutes les applications utilisant l'authentification unique. Cette fonctionnalité renforce la sécurité en empêchant tout accès non autorisé à une session restée ouverte, notamment lorsqu'un appareil est partagé avec d'autres personnes.

Lorsque vous mettez en place les fonctionnalités de déconnexion unique (SLO), trois types de sessions existent.

Séance de candidature: Bien que l'application utilise le protocole OP ( OpenID ) pour authentifier les utilisateurs, elle peut suivre l'utilisateur qui s'est connecté à l'application. En général, une application suit les sessions à l'aide d'un cookie de navigateur. L'application doit effacer la session lors de la déconnexion.
Fournisseur d' OpenID s (OP) du serveur d'autorisation (session): Un serveur d'autorisation gère également la session d'un utilisateur et la stocke dans un cookie. Lors de la déconnexion, le serveur d'autorisation met fin à la session de l'utilisateur, ainsi qu'aux autorisations et aux jetons associés à cette session.
Identité - Source - Session: Les utilisateurs peuvent se connecter à l'aide d'une session provenant d'une source d'identité. Lors de la déconnexion, l'utilisateur peut également souhaiter se déconnecter de cette session.

Remarque : la déconnexion unique ne prend pas en charge la déconnexion d'une session auprès d'un fournisseur d'identité. Il ne prend pas non plus en charge la déconnexion des applications SAML. Bien que SAML dispose d'un point de terminaison similaire pour effectuer l' IdP-initiated ation et la déconnexion initiée par le fournisseur de services (SP), il n'est pas intégré à la déconnexion unique OIDC.

Il existe deux mécanismes permettant à un serveur d'autorisation (OP) d'informer l'application qu'une déconnexion a été déclenchée : le canal direct et le canal indirect. Dans les deux mécanismes, l'application enregistre un point de terminaison de déconnexion que le serveur d'autorisation appelle. Cet endpoint encapsule le code utilisé par l'application pour effacer sa session. L'appel du point de terminaison de déconnexion de l'application n'est pas fiable, car IBM® Verify n'est pas tenu de réessayer ni de s'assurer que l'application a bien effacé sa session. La déconnexion via le canal de communication latéral est le mécanisme privilégié.

Déconnexion du canal principal

La déconnexion par canal frontal, ou déconnexion côté client, est une méthode de déconnexion unique (SLO) dans laquelle le client (généralement un navigateur web) communique directement avec le serveur pour mettre fin à la session de l'utilisateur. Cela se fait généralement en envoyant une requête au serveur pour qu'il supprime le cookie de session ou le jeton. Le serveur répond ensuite pour confirmer la déconnexion. Cette méthode est simple et fonctionne bien dans les cas où il n'y a qu'un seul domaine. Toutefois, cette solution pourrait ne pas convenir aux environnements complexes, multi-domaines ou multi-protocoles en raison de problèmes potentiels liés à la communication inter-origines et à la sécurité. Lorsque vous utilisez le mécanisme de canal frontal, le serveur d'autorisation (OP) affiche

<iframe
src="frontchannel_logout_uri">

une page afin de déclencher un HTTP GET appel vers le point de terminaison de déconnexion de l'application. L'application peut demander au serveur d'autorisation d'envoyer l'identifiant de session (sid) et les informations relatives à l'émetteur (iss) sous forme de paramètres de requête supplémentaires. Si le client de l'application est créé à l'aide de l'enregistrement dynamique des clients, définissez frontchannel_logout_session_required la métadonnée client sur « true ». IBM VerifyEn effet, lorsque vous configurez l'application « OpenID » dans l'interface d'administration, ce paramètre est accessible dans l'onglet « Connexion ». Faites défiler jusqu'à la section « Paramètres de déconnexion unique » et cochez la case « Session requise ». L'application peut utiliser ces informations pour valider la demande et déterminer les sessions dont il faut se déconnecter. Si le sid ne correspond pas à la session en cours ou à une session récente avec le serveur d'autorisation (OP), l'application pourrait ignorer la demande de déconnexion.

Remarque : OIDC Front-channel Logout recommande d'utiliser un iframe pour appeler le point de terminaison de déconnexion par canal frontal. iframeLes navigateurs modernes bloquent par défaut la transmission des cookies tiers. Si le domaine de l'application diffère de celui du serveur d'autorisation, celle-ci ne reçoit aucun cookie, ce qui peut empêcher l'application de déconnecter correctement l'utilisateur. L'utilisateur devra configurer son navigateur pour autoriser les cookies tiers provenant du domaine du serveur d'autorisation.

Déconnexion du canal secondaire

La déconnexion par canal secondaire, ou déconnexion côté serveur, est une méthode de déconnexion unique (SLO) dans laquelle le fournisseur d'identité ( IdP ) communique directement avec le fournisseur de services (SP) afin d'invalider la session de l'utilisateur. Cela s'effectue généralement via un canal sécurisé établi entre l' IdP e et le fournisseur de services lors du processus d'authentification initial. Lorsque vous utilisez le mécanisme de canal de retour, le serveur d'autorisation (n) envoie une requête POST de type « HTTP » vers le point de terminaison de déconnexion de l'application via une API de canal de retour directe. Le serveur d'autorisation émet un jeton JWT de déconnexion contenant les informations suivantes.

Nom de la réclamation	Utilisation	Descriptif
`iss`	Obligatoire	Identifiant de l'émetteur.
`sub`	Facultatif	Identificateur d'objet. Doit être présent lorsque `sid` n'est pas présent.
`aud`	Obligatoire	Public ou publics.
`iat`	Obligatoire	Publié à l'époque.
`exp`	Obligatoire	Heure d'expiration.
`jti`	Obligatoire	Identifiant unique du jeton.
`events`	Obligatoire	http://schemas.openid.net/event/backchannel-logoutObjet JSON contenant le nom du membre.
`sid`	Facultatif	Identifiant de session. Doit être présent lorsque `sub` n'est pas présent.

Le serveur d'autorisation (OP) utilise la même configuration pour signer, chiffrer ou les deux le jeton JWT de déconnexion que pour le jeton d'identification.

end_session_endpointDans un scénario de déconnexion initié par une partie dépendante de l'application (RP), l'application déclenche la déconnexion en redirigeant vers le serveur d'autorisation, dont l'adresse est publiée dans le point de terminaison de découverte du serveur d'autorisation. L'application peut envoyer les paramètres de requête suivants.

Nom du paramètre	Utilisation	Descriptif
`id_token_hint`	Recommandé	Le jeton d'identification émis par le serveur d'autorisation, qui sert d'indicateur de la session authentifiée de l'utilisateur auprès de l'application.
`logout_hint`	Facultatif	Une indication fournie au serveur d'autorisation concernant l'utilisateur qui se déconnecte.
client_id	Facultatif	L'identifiant client de l'application.
`post_logout_redirect_uri`	Facultatif	L'URI vers lequel l'application demande que l'agent utilisateur de l'utilisateur soit redirigé une fois la déconnexion effectuée.
`state`	Facultatif	Une valeur opaque utilisée par l'application pour conserver l'état entre la demande de déconnexion et le rappel vers le `post_logout_redirect_uri` point de terminaison.
`ui_locales`	Facultatif	Les langues et les scripts préférés de l'utilisateur pour l'interface utilisateur.

Lorsque le id_token_hint n'est pas spécifié ou que le jeton d'identification n'appartient pas à l'utilisateur actuellement connecté, le serveur d'autorisation demande à l'utilisateur s'il souhaite mettre fin à la session du serveur d'autorisation. Ensuite, comme dans le scénario de déconnexion initiée par l'OP, le serveur d'autorisation recherche la liste des applications qui se sont connectées via la même session du serveur d'autorisation (OP). Il en informe les applications en utilisant l'un des mécanismes de déconnexion du canal. Ensuite, si l'utilisateur donne son consentement, le serveur d'autorisation efface sa propre session. Si l'URI post_logout_redirect_uri est spécifié et peut être validé par rapport à la configuration du client, une redirection vers cet URI est effectuée à la fin du processus de déconnexion. Sinon, le serveur d'autorisation affiche le rapport récapitulatif de déconnexion.

Conseil : si vous développez un point de terminaison de déconnexion pour une application personnalisée,

Pour la déconnexion du canal avant

Verify s'attend à ce que le point de terminaison de déconnexion de l'application réponde dans un délai de 3 secondes.

Pour se déconnecter du canal secondaire

Verify s'attend à ce que le point de terminaison renvoie le code 2xx en cas de réussite et le code 400 en cas d'erreur.
Verify s'attend à ce que le point de terminaison de déconnexion de l'application réponde dans un délai de 3 secondes.
Afin d'accélérer la validation du jeton de déconnexion JWT, le point de terminaison de déconnexion de l'application met en cache le Verify point de terminaison JWKS.