Accéder au contenu principal Passer au contenu complémentaire

OpenID Connect pour l'intégration à des fournisseurs d'identité

OpenID Connect (OIDC) est utilisé pour l'intégration de Qlik Cloud à des fournisseurs d'identité. OIDC est une couche d'identité fine par-dessus le protocole OAuth 2.0. OAuth 2.0 est le protocole standard pour l'autorisation et OIDC le protocole standard pour l'authentification des utilisateurs. Ensemble, ces deux protocoles vous permettent d'accéder à différentes applications et différents sites Web en toute sécurité, sans avoir à vous connecter à plusieurs reprises, via Authentification unique (SSO).

OAuth 2.0 est conçu uniquement pour l'autorisation. Vous pouvez accorder l'accès aux données et aux fonctions d'une application à une autre, en fournissant une clé au client qui le demande. Grâce à cette clé, vous n'avez pas à divulguer vos informations d'identification. En revanche, vous réutilisez vos informations d'identification avec une application dont vous êtes déjà un utilisateur enregistré, par exemple, un fournisseur de messagerie. La clé garantit que vous partagez uniquement des informations que vous avez accepté de partager. Vous pouvez également retirer la clé quand bon vous semble.

La clé est utile, mais elle ne fournit aucune information sur vous en tant qu'utilisateur. OIDC ajoute une fonctionnalité relative aux informations de connexion et de profil de la personne qui est connectée à l'aide de jetons d'ID. OIDC permet à différents clients (basés sur le Web, mobiles, Javascript, etc.) de vérifier l'identité de l'utilisateur en fonction de l'authentification effectuée par un serveur d'autorisation. Les clients peuvent également demander des informations de profil de base sur l'utilisateur.

Pour une introduction à OAuth et à OpenID Connect, visionnez la vidéo suivante : Guide illustré d'OAuth et d'OpenID Connect.

Jetons d'ID

OpenID Connect utilise des jetons d'ID qui simplifient l'intégration et prennent en charge une grande variété d'applications.

Un jeton d'ID est une chaîne de caractères spécifiquement formatée connue sous le nom de JSON Web Token ou de JWT. Les JWT sont polyvalents et prennent en charge une large gamme d'algorithmes de signature et de chiffrement. Les clients peuvent extraire des informations incorporées dans le JWT, telles que l'ID, le nom, le moment où vous vous êtes connecté, l'expiration du jeton d'ID et s'il y a eu des tentatives de falsification du JWT. Les données à l'intérieur du jeton d'ID sont appelées des revendications.

Comme susmentionné, les clients utilisent des flux OAuth 2.0 pour obtenir des jetons d'ID qui fonctionnent à la fois avec les applications Web et les applications mobiles natives.

Jetons d'accès

Outre les jetons d'ID, il existe des jetons d'accès : des informations d'identification qui peuvent être utilisées par une application pour accéder à une API. Un jeton d'accès peut être un jeton JWT ou un jeton non JWT. Le jeton est utilisé pour informer l'API que l'accès à l'API a été accordé au porteur de ce jeton.

Revendications

Les jetons JWT contiennent des revendications, qui sont des instructions (telles que le nom ou l'adresse e-mail) sur une entité (généralement, l'utilisateur) et des métadonnées supplémentaires.

La spécification OIDC définit un ensemble de revendications standard. L'ensemble de revendications standard incluent le nom, l'adresse e-mail, le sexe, la date de naissance, etc. Si vous souhaitez collecter des informations sur un utilisateur non couvert par une revendication standard, vous pouvez créer des revendications personnalisées et les ajouter à vos jetons.

Spécification OpenID Connect

La spécification OpenID Connect 1.0 se compose des documents suivants. Qlik prend en charge cette spécification, pas l'ensemble de l'implémentation personnalisée spécifique des fournisseurs de la spécification. Qlik peut choisir d'ajouter une configuration pratique pour nos clients pour les produits et plates-formes de gestion des identités populaires.

  • Core : Définit la fonctionnalité OpenID Connect essentielle : l'authentification bâtie par-dessus OAuth 2.0 et l'utilisation de revendications pour communiquer des informations sur l'utilisateur
  • Discovery (en option) : Définit la manière dont les clients découvrent dynamiquement des informations sur les fournisseurs OpenID
  • Dynamic Registration (en option) : Définit la manière dont les clients s'enregistrent dynamiquement auprès des fournisseurs OpenID
  • OAuth 2.0 Multiple Response Types : Définit plusieurs nouveaux types de réponse OAuth 2.0 spécifiques
  • OAuth 2.0 Form Post Response Mode (en option) : Définit la manière de renvoyer les paramètres de réponse d'autorisation OAuth 2.0 (notamment les paramètres de réponse d'authentification OpenID Connect) à l'aide de valeurs de formulaire HTML qui sont automatiquement soumises par l'agent utilisateur via HTTP POST
  • Session Management (en option) : Définit la manière de gérer les sessions OpenID Connect, notamment la fonctionnalité de déconnexion basée sur postMessage et la fonctionnalité de déconnexion initiée par RP
  • Front-Channel Logout (en option) : Définit un mécanisme de déconnexion de canal avant qui n'utilise pas d'iframe OP sur les pages RP
  • Back-Channel Logout (en option) : Définit un mécanisme de déconnexion qui utilse une communication de canal arrière directe entre l'OP et les RP en cours de déconnexion
  • OpenID Connect Federation (en option) : Définit la manière dont les ensembles d'OP et de RP peuvent établir la confiance en utilisant un Federation Operator

Pour accéder aux documents, accédez à la section Bienvenue dans OpenID Connect.

Cette page vous a-t-elle aidé ?

Si vous rencontrez des problèmes sur cette page ou dans son contenu – une faute de frappe, une étape manquante ou une erreur technique – dites-nous comment nous améliorer !