Passer au contenu principal
L’Okta Integration Network (OIN) est un catalogue d’applications SaaS pour lesquelles Okta offre une expérience de configuration express afin d’activer l’authentification unique avec OpenID Connect, le provisioning automatisé des utilisateurs avec SCIM et la déconnexion universelle. Les administrateurs Okta utilisent la console d’administration d’Okta pour configurer ces intégrations dans leur tenant Okta :
Console d’administration Okta
La Configuration Express permet aux clients d’entreprise de configurer en toute sécurité des intégrations d’identité avec des applications SaaS sans devoir copier-coller des valeurs de configuration propres aux protocoles. La Configuration Express offre les avantages suivants aux administrateurs Okta et aux développeurs d’applications SaaS :
  • Réduit le temps nécessaire pour configurer une instance d’application en automatisant l’échange d’informations de configuration entre Okta et Auth0.
  • Utilise les flux de consentement OAuth 2.0 pour le partage sécurisé et autorisé de données de configuration sensibles, ce qui réduit les erreurs potentielles liées aux identifiants et aux paramètres de configuration.
  • Simplifie et normalise le processus de déploiement des intégrations. Le flux de travail automatisé permet des déploiements cohérents et reproductibles des intégrations d’applications pour plusieurs clients ou environnements, soutenant un écosystème d’applications évolutif avec moins de risques d’erreurs humaines.
  • Élimine la complexité de la configuration manuelle, permettant aux administrateurs des clients Okta d’ajouter rapidement des instances d’intégrations OIN compatibles avec Auth0.

​
Fonctionnement

L’API Express Configuration permet aux applications Auth0 publiées dans l’OIN et destinées aux clients d’utiliser Express Configuration sur une connexion Okta. Express Configuration prend en charge OpenID Connect, SCIM et la déconnexion universelle (Universal Logout) au sein d’une organisation Auth0. Passez en revue le flux de travail Express Configuration pour une application Auth0 dans l’OIN :
flux de travail Express Configuration pour une application Auth0 dans l’OIN.
  • Un administrateur Okta se connecte au portail Okta et sélectionne dans l’OIN l’application prenant en charge Express Configuration.
  • L’administrateur Okta accède à la section Sign On et sélectionne Express Configure SSO & UL. Il est alors redirigé vers un écran Auth0 Universal Login.
Console d’administrateur Okta > Sign On > Express Configuration
  • L’administrateur Okta saisit les informations d’identification d’un utilisateur de l’application autorisé à effectuer Express Configuration. Dans Auth0, il s’agit d’un utilisateur qui est membre d’une organisation et autorisé à effectuer Express Configuration à l’aide d’un rôle organisationnel ou d’une autre méthode d’autorisation.
Connexion à l’organisation Auth0
  • Après l’authentification, Auth0 demande le consentement de l’administrateur Okta.
Consentement Auth0
  • Une fois le consentement accordé, Okta utilise l’API Express Configuration pour configurer automatiquement une connexion Okta au sein de l’organisation Auth0 à laquelle appartient l’administrateur Okta.
  • L’administrateur Okta peut ensuite attribuer des utilisateurs à l’instance d’application et constater immédiatement le bon fonctionnement de l’authentification unique (SSO).
Les développeurs Auth0 peuvent également configurer leur intégration OIN pour autoriser l’Express Configuration de SCIM et de la déconnexion universelle (Universal Logout), toutes deux fortement recommandées :
  • Lorsque SCIM est activé, les administrateurs Okta peuvent le configurer en accédant à la section Provisioning des détails de l’application et en sélectionnant Express Configure SCIM.
  • Lorsque la déconnexion universelle (Universal Logout) est activée, elle est automatiquement configurée dans le cadre de l’intégration OpenID Connect.

​
Conditions préalables

Pour publier une application dans l’OIN avec Express Configuration activée, vous devez disposer des éléments suivants :
  • Une organisation Okta Integrator Free Plan, avec accès soit au rôle Super Admin, soit aux rôles App Admin et Org Admin.
  • Un abonnement Auth0 qui permet d’utiliser le type de connexion Okta et la fonctionnalité Organizations pour autant de clients que nécessaire.
  • Une application SaaS intégrée à Auth0 au moyen d’une architecture multi‑organisation.
  • Une Auth0 Organization est ou peut être déployée pour chaque client utilisant Express Configuration. Les organisations et les rôles organisationnels servent à autoriser certains utilisateurs à effectuer Express Configuration et à créer des connexions Okta uniquement au sein des organisations auxquelles ils appartiennent.
  • Dans votre tenant Auth0, le paramètre de tenant Enable Application Connections doit être désactivé.
Conseil : Pour consulter un exemple d’application qui implémente une architecture multi‑tenant incluant Auth0 Organizations et des rôles organisationnels, consultez l’application de référence SaaStart.

​
Configurer votre application pour Express Configuration

L’Auth0 Dashboard guide un développeur Auth0 dans l’activation d’Express Configuration pour son application et sa publication dans l’OIN. Un rôle Admin Auth0 dans un tenant Auth0 de production est requis pour terminer le processus complet de configuration et de publication.
OIN dans Auth0 Dashboard
Configurez les composants Auth0 suivants pour mettre en place Express Configuration dans votre tenant :
  • Une Application enregistrée avec un Initiate Login URI Template
  • Un profil de connexion
  • Un profil d’attributs utilisateur
  • Les paramètres de connexion de l’organisation
  • Les paramètres de connexion et de consentement de l’administrateur

​
Enregistrer une application avec le modèle d’URI de démarrage de connexion

  1. Enregistrez votre application comme Regular Web Application ou Single-Page Application dans Auth0 Dashboard.
  2. Une fois l’application enregistrée, sélectionnez celle que vous avez créée et accédez à l’onglet Okta Integration Network pour lancer l’assistant de configuration Express Configuration.
  3. Sélectionnez Get Started.
  4. Passez en revue les conditions préalables et sélectionnez Continue.
  5. Enregistrez un Initiate Login URI Template. Ce modèle implémente un point de terminaison dans votre application afin de rediriger automatiquement les utilisateurs finaux vers le point de terminaison /authorize d’Auth0 pour l’authentification. Pour voir un exemple de point de terminaison de connexion, consultez la route /login dans le Démarrage rapide Express SDK.
    • Une fois qu’Express Configuration est lancée pour une instance d’application, Okta utilise le Initiate Login URI Template pour ouvrir l’application à partir du tableau de bord de l’utilisateur final.
    • (Facultatif) Définissez organization_name, organization_id, et connection_name pour le point de terminaison /authorize d’Auth0 afin d’identifier l’organisation ou la connexion à utiliser. Okta remplace dynamiquement ces variables lorsque l’URL est lancée à partir du tableau de bord de l’utilisateur final. Exemple : https://{organization_name}.your-app.com?connection={connection_name}.
Dashboard>Applications>OIN>URI-template
Exemples d’URI de démarrage de connexion : https://your-app.com/login
https://your-app.com/login?connection={connection_name}
https://{organization_name}.your-app.com?connection={connection_name}

​
Profil de connexion

Dans le gabarit d’URI Initiate Login, vous avez la possibilité d’ajouter un Profil de connexion. Le Profil de connexion (CP) permet à Auth0 de définir comment les paramètres privés de vos connexions doivent être configurés lorsqu’elles sont créées au moyen d’Express Configuration, y compris les paramètres qui régissent la façon dont la connexion interagit avec les fonctionnalités Universal Login et Organizations d’Auth0 :
  • Options concernant la façon dont le nom de la connexion doit être créé dans Auth0
    • Options pour utiliser SCIM et/ou Universal Logout avec la connexion (recommandé)
    • Options pour permettre aux utilisateurs finaux de la connexion de devenir automatiquement membres de l’organisation de l’administrateur ayant donné son consentement
    • Options pour le paramètre Afficher comme bouton pour la connexion sur la page Universal Login d’Auth0
Si vous n’avez pas configuré de Profil de connexion, Auth0 fournit un Profil de connexion par défaut avec des paramètres courants et recommandés déjà appliqués pour les connexions configurées avec Express.
Pour savoir comment personnaliser le CP par défaut, consultez Profil de connexion.

​
Profil d’attributs utilisateur

Dans le modèle d’URI Initiate Login, vous avez l’option d’ajouter un Profil d’attributs utilisateur. Le Profil d’attributs utilisateur (UAP) permet aux développeurs Auth0 de définir, gérer et mapper les attributs utilisateur de façon cohérente dans les différents protocoles pris en charge par Auth0. Lorsqu’il est utilisé avec Express Configuration, le Profil d’attributs utilisateur permet aux développeurs de personnaliser les mappages d’attributs OpenID Connect et SCIM qui seront appliqués à la connexion Okta générée par Express Configuration.
Si vous n’avez pas de Profil d’attributs utilisateur configuré, Auth0 fournit un Profil d’attributs utilisateur par défaut avec des mappages courants et recommandés pour tous les protocoles, y compris OpenID Connect et SCIM, qui sont utilisés par le type de connexion Okta.
Pour savoir comment personnaliser l’UAP par défaut, consultez User Attribute Profile.

​
Paramètres de connexion d’organisation

Les organisations Auth0 sont nécessaires pour autoriser certains utilisateurs d’organisation à créer des Connexions isolées, mais ne sont pas nécessaires pour modifier le flux de connexion existant de votre Application afin de prendre en charge le flux de connexion basé sur l’organisation pour les utilisateurs professionnels.
  • Si votre Application utilise actuellement une expérience de connexion de type Identifier-First et la détection du domaine d’authentification (home realm discovery) avec vos Applications, consultez la section Enabling Home Realm Discovery pour savoir comment activer la détection du domaine d’authentification.
  • Si vous souhaitez activer plusieurs Applications dans enabled_clients pour qu’elles soient utilisées avec vos Connexions Express Configuration, consultez Enabling Multiple Auth0 Applications Under a Single Integration.
Si la configuration de votre Application n’utilise pas actuellement un flux de connexion basé sur l’organisation, vous pouvez sélectionner le paramètre Enable this application for created connections. Lorsqu’il est activé, chaque configuration Express sur une Connexion Okta est associée directement à votre Application. Utilisez le paramètre enabled_clients requis sur la Connexion. Quand la configuration Express est activée, Auth0 crée un id d’application client supplémentaire qui est utilisé par l’OIN pendant le flux de consentement de l’administrateur entre Okta et Auth0. Okta crée un client OIN pour chaque intégration d’application distincte publiée dans l’OIN. Configurez les paramètres de consentement et de connexion de l’administrateur dans l’application que vous voulez publier dans l’OIN sous Configure Integration Profile.
  1. Accédez à Auth0 Dashboard > Applications.
  2. Choisissez l’application que vous voulez publier dans l’OIN.
  3. Sélectionnez Okta Integration Network.
  4. Vérifiez que vous avez les prérequis nécessaires et sélectionnez Continue.
  5. Dans la section Configure Integration Profile, configurez les options dans Admin Settings.
Express Configuration Admin Settings
  • Admin Login Domain : domaine du tenant Auth0 vers lequel Okta redirige dans le cadre du flux de consentement dans un navigateur Web. Utilisez le nom de domaine personnalisé si vous en avez un configuré dans Auth0. Pour en savoir plus, consultez Custom Domains.
    • Display Name of the OIN Express Configuration Application : nom de l’application client OIN affiché dans la boîte de dialogue de consentement.
    • Admin Login Flow : définit le flux de connexion d’organisation pour l’application client OIN et est utilisé lorsqu’un administrateur Okta exécute la configuration Express à partir de la console Okta. Sélectionnez parmi :
      • Prompt for Organization : on demande d’abord aux administrateurs de sélectionner leur organisation, puis on leur présente l’expérience de connexion pour leur organisation Auth0. Les administrateurs peuvent ouvrir une session à l’aide d’une connexion préexistante configurée dans cette organisation.
      • Prompt for Credentials : on demande d’abord aux administrateurs de fournir leurs informations de connexion. Quand cette option est sélectionnée, un bouton apparaît et vous permet de sélectionner les connexions qui contiennent les utilisateurs administrateurs. Il peut s’agir d’une connexion à une base de données partagée, d’une connexion de courriel d’Authentification sans mot de passe, ou d’une autre connexion qui peut être associée à toutes les organisations Auth0.
    • Admin Role : Pour effectuer la configuration Express, l’administrateur doit se voir attribuer les autorisations appropriées. Lisez Assign express configuration permissions to users pour obtenir des instructions sur la façon d’autoriser les administrateurs de la manière qui a le plus de sens pour votre déploiement Auth0 actuel.
Pour offrir la meilleure expérience de consentement possible, définissez le paramètre use_scope_descriptions_for_consent de votre tenant à true, comme décrit dans Customize Consent Prompts. Vous aurez la possibilité de voir votre invite de consentement plus tard, lorsque vous testerez et vérifierez votre intégration.

​
Attribuer des autorisations aux utilisateurs

Pour Okta, les administrateurs doivent disposer d’un compte utilisateur d’application avec les autorisations nécessaires pour effectuer la configuration Express d’une application SaaS utilisant Auth0. Pour Auth0, tout utilisateur de l’application peut se voir accorder cette autorisation, tant que l’utilisateur est membre d’une organisation Auth0 dans laquelle les connexions configurées avec Express sont créées, notamment :
  • Un utilisateur dans une connexion de base de données dédiée qui a été créée exclusivement pour une seule organisation
  • Un utilisateur dans une connexion de base de données partagée qui est membre d’une ou de plusieurs organisations
  • Un utilisateur avec une connexion de courriel sans mot de passe qui est membre d’une ou de plusieurs organisations
  • Un utilisateur dans une connexion sociale ou d’entreprise existante qui est membre d’une ou de plusieurs organisations
Une fois ces conditions remplies, Auth0 offre des moyens flexibles d’attribuer des autorisations de configuration Express et permet aux développeurs de choisir la méthode la plus appropriée pour leur déploiement Auth0 actuel :
MéthodeRecommandé pour…
Attribuer des autorisations de configuration Express à un rôle utilisateur existantClients possédant un rôle d’utilisateur d’application existant dans leur tenant Auth0.
Attribuer un nouveau rôle aux utilisateurs d’application qui ont besoin d’autorisations de configuration Express, comme illustré dans l’application de référence SaaStart.Clients qui souhaitent utiliser la fonctionnalité de rôle d’Auth0 pour accorder des autorisations de configuration Express à des utilisateurs individuels. Cela peut être fait avec Auth0 Dashboard ou la Management API.
Utiliser une Action Post-Login pour attribuer dynamiquement des autorisations en utilisant le contrôle d’accès basé sur les attributsClients qui n’utilisent pas actuellement la fonctionnalité de rôle d’Auth0 et qui préfèrent utiliser une Action Post-Login pour attribuer dynamiquement des autorisations en fonction des attributs de l’utilisateur, plutôt que d’utiliser Auth0 Dashboard ou d’effectuer des appels à la Management API pour attribuer des rôles.
Pour des conseils sur l’approvisionnement de comptes d’administrateur pour utiliser la configuration Express, consultez la section Activation du client.

​
Attribuer des permissions à un rôle d’utilisateur d’application existant

Utilisez cette méthode d’attribution des permissions Express Configuration si vous utilisez la fonctionnalité RBAC d’Auth0 pour les rôles d’application et les permissions d’API et que vous disposez déjà d’un ou de plusieurs rôles représentant un utilisateur administrateur, à attribuer à un administrateur TI chargé du déploiement de l’application. Permissions d’API requises :
Nom de la permissionIdentifiant de l’API (serveur de ressources)
express_configure:ssourn:auth0:express-configure
express_configure:scimurn:auth0:express-configure
Pour en savoir plus sur l’attribution de rôles dans Auth0 Dashboard et Management API, consultez Ajouter des permissions aux rôles.

​
Attribuer un nouveau rôle aux utilisateurs de l’application

Utilisez cette méthode pour attribuer les autorisations Express Configuration si vous utilisez la fonctionnalité RBAC d’Auth0 pour les rôles d’application et les autorisations d’API, mais que vous n’avez pas de rôle représentant un utilisateur ayant un rôle d’administrateur, comme un administrateur TI, chargé de déployer l’application. Cette méthode convient également aux développeurs Auth0 qui n’utilisent pas encore la fonctionnalité RBAC d’Auth0, mais qui souhaitent l’utiliser pour obtenir un contrôle fin sur les utilisateurs autorisés à accéder à l’application, en utilisant soit l’Auth0 Dashboard, soit la Management API.

​
Créer un rôle

Utilisez l’Auth0 Dashboard, la Management API ou l’Auth0 CLI pour créer des rôles. Cet exemple utilise l’Auth0 CLI : 
auth0 roles create \
  --name "EXPRESS_CONFIGURE_ADMIN_ROLE" \
  --description "Administrator role for Express Configuration"

​
Attribuer des permissions au rôle

Attribuez les permissions express_configuration:sso et express_configuration:scim au rôle spécifié. Remplacez $ROLE_ID par l’ID du rôle auquel vous souhaitez accorder les permissions.
Lorsque vous utilisez cette méthode, vous devrez mettre à jour votre processus d’intégration des clients afin d’attribuer ce rôle à tous les nouveaux utilisateurs de l’organisation qui ont besoin des permissions Express Configuration.
auth0 roles permissions add "$ROLE_ID" \
  --api-id "urn:auth0:express-configure" \
  --permissions "express_configure:sso"

auth0 roles permissions add "$ROLE_ID" \
  --api-id "urn:auth0:express-configure" \
  --permissions "express_configure:scim"
Pour en savoir plus sur l’attribution de rôles aux utilisateurs existants d’une organisation, consultez Ajouter des rôles aux membres.

​
Attribuer des permissions en fonction des attributs des utilisateurs à l’aide d’une Action post-login

Utilisez cette méthode d’attribution des permissions Express Configuration si vous utilisez une Action post-login Auth0 pour attribuer dynamiquement des permissions en fonction des attributs des utilisateurs, plutôt que d’utiliser le contrôle d’accès basé sur les rôles (RBAC), la Management API ou Auth0 Dashboard pour attribuer des rôles aux utilisateurs. Cette approche convient aux clients Auth0 qui ont déployé Auth0 en utilisant un modèle d’autorisation basé sur les attributs avec des permissions personnalisées dans les métadonnées Auth0. Exemple
L’exemple suivant utilise une Action post-login pour attribuer des permissions en fonction de la valeur d’un attribut utilisateur personnalisé existant, user.app_metadata.is_admin. 
/**
* Attribue les permissions Express Configuration en fonction d'une logique personnalisée au lieu d'une attribution de rôle
*/
exports.onExecutePostLogin = async (event, api) => {


 //check if request is for EC API access token
 if (event.resource_server && event.resource_server.identifier === "urn:auth0:express-configure") {


   //add permissions based on a custom condition
   if (event.user.app_metadata && event.user.app_metadata.is_admin === true) {
     api.accessToken.addScope("express_configure:sso");
     api.accessToken.addScope("express_configure:scim");
   }
   //else deny access if EC access token is requested
   else {
     api.access.deny('Access denied');
   }
 }
};

​
Activer la détection du domaine d’origine (home realm discovery)

Avant d’exécuter Express Configuration, vous devez recueillir et vérifier les adresses de courriel des clients dans le cadre du processus d’intégration client afin d’activer la HRD.
Vous pouvez utiliser Express Configuration avec les Actions Auth0 si votre application repose sur l’expérience de connexion axée sur l’identifiant (Identifier-First) et utilise la détection du domaine d’origine (HRD) pour faire correspondre les utilisateurs à leurs fournisseurs d’identité (IdP) en fonction de l’adresse de courriel. Les adresses de courriel doivent être stockées à un emplacement accessible par les Actions post-connexion durant le flux de travail Express Configuration, notamment :
  • Un ou plusieurs domaines de courriel peuvent être stockés dans les métadonnées d’organisation sur l’Organisation Auth0 du client.
  • Votre Action post-connexion peut effectuer un appel d’API pour récupérer les domaines vérifiés à partir de tout système de votre environnement qui les stocke.
Lorsque l’utilisateur administratif lance la configuration express dans le portail Okta et s’authentifie, ces Actions ajoutent les domaines de courriel au jeton qu’Okta reçoit, qu’Okta extrait et utilise pour configurer la connexion Okta avec la configuration HRD appropriée. Exemple 1
Dans cet exemple, les domaines vérifiés sont stockés dans les métadonnées de connexion de l’Organisation Auth0, ce qui exige une chaîne à valeurs séparées par des virgules contenant un ou plusieurs domaines de courriel, stockée dans les métadonnées de l’organisation sous une clé nommée domains. Valeurs d’exemple : test.com,test2.com 
exports.onExecutePostLogin = async (event, api) => {
if (event.request.query.audience === "urn:auth0:express-configure") {
  if (event.organization && event.organization.metadata && event.organization.metadata.domains)
  {
    var domain_aliases = event.organization.metadata.domains.replace(/ /g,'').split(',');
    var express_configuration = {
      "domain_aliases": domain_aliases
     };
     api.accessToken.setCustomClaim("express_configuration", express_configuration);
  }
}
};
Exemple 2
Dans cet exemple, l’Action Post-Login effectue un appel à une API pour récupérer les domaines vérifiés à partir d’un système de stockage de votre environnement. 
/**
*/
exports.onExecutePostLogin = async (event, api) => {
 if (event.request.query.audience === "urn:auth0:express-configure") {
    const axios = require("axios");
    // configurez votre appel d'API personnalisé ici 
    const domains = await axios.get("https://example.org/endpoint");
     var express_configuration = {
     "domain_aliases": domains
      };
      api.accessToken.setCustomClaim("express_configuration", express_configuration);
  
 }
};

​
Maintenir la correspondance des comptes d’admin entre les connexions

Auth0 permet l’approvisionnement de comptes d’utilisateurs avec la même adresse de courriel dans différentes connexions. Un utilisateur final peut avoir une connexion de base de données, un compte social ou un compte d’authentification sans mot de passe avec son adresse de courriel professionnelle, et aussi avoir la même adresse de courriel dans son compte Okta fédéré. Lorsque vous utilisez l’option Prompt for Credentials dans le flux de connexion et de consentement d’admin, la découverte du domaine d’appartenance commence à associer les utilisateurs dont l’adresse de courriel a un suffixe de domaine particulier à la nouvelle connexion Okta plutôt qu’à d’autres types de connexions, une fois qu’elle a été ajoutée à l’Organisation. Pour en savoir plus sur ce comportement de connexion d’Organisation, consultez Identifier First Authentication with prompt for credentials. Ce comportement ne prend effet que lorsque les clients exécutent Express Configuration une deuxième fois après l’expiration de leur session utilisateur d’admin Auth0 initiale. Si l’identifiant du compte d’admin est une adresse de courriel qui correspond à la nouvelle connexion Okta, l’admin sera alors redirigé vers celle-ci. Vous pouvez gérer ou éviter ce comportement à l’aide de l’une des méthodes suivantes :
  • Utilisez l’option Prompt for Organization dans le flux de connexion et de consentement d’admin.
    • Activez les autorisations Express Configuration pour le nouveau compte Okta qui contient l’adresse de courriel vérifiée correspondante après son approvisionnement.
    • Si vous utilisez les Organisations Auth0 uniquement pour le flux de consentement d’admin d’Express Configuration et non pour l’expérience de votre application, vous pouvez résoudre le problème en désactivant la propriété enable_organization décrite dans Configurer les propriétés de l’Application SaaS.
    • Ce n’est pas un problème si l’identifiant de l’utilisateur admin n’est pas une adresse de courriel, par exemple un nom d’utilisateur dans une connexion de base de données.

​
Activer plusieurs applications sous une même intégration

Si vous voulez que les utilisateurs finaux d’une seule configuration Express sur une connexion Okta accèdent à plusieurs applications dans votre tenant, vous pouvez définir une propriété linked_clients sur votre application web enregistrée. Pour modifier ce paramètre, utilisez l’Auth0 Management API pour récupérer votre application web enregistrée. Remplacez {yourAppId} par l’ID client de votre application enregistrée et {yourAccessToken} par un jeton d’accès à l’Auth0 Management API v2. Pour savoir comment obtenir un jeton d’accès à utiliser avec l’Auth0 Management API, consultez Management API Access Tokens. 
curl --request GET \
  --url 'https://{yourDomain}/api/v2/clients/{yourAppId}' \
  --header 'authorization: Bearer {yourAccessToken}'
Extrayez la propriété express_configuration de la réponse, ajoutez un tableau d’ID d’applications supplémentaires à une propriété linked_clients, puis mettez à jour votre application Web enregistrée : 
curl --request PATCH \
  --url 'https://{yourDomain}/api/v2/clients/{yourAppId}' \
  --data '{"express_configuration": 
  {"admin_login_domain":"TENANT.auth0.com",
    "connection_profile_id":"cop_xxxxxxxxxxxxxxx",
    "enable_client":true,
    "enable_organization":true,
    "initiate_login_uri_template":"https://example.org",
    "okta_oin_client_id":"LDiGbUeiAYjRB5a4yOGfBvxxxxxxxxxxx",
    "user_attribute_profile_id":"uap_1ctMVQUg8jxxxxxxxxxxxx",   

     "linked_clients": [ 
        { "client_id": "KJM86F2susguvsasSeAsIxxxxxxxxxxx" }, 
	  { "client_id": "FIXwZCf5iUElvqy6eidlfxxxxxxxxxxx" }
      ] 
     }
  }' \
  --header 'cache-control: no-cache' \
  --header 'content-type: application/json' \
  --header 'authorization: Bearer {yourAccessToken}'
Lorsque vous exécutez la configuration Express, tous les ID d’application figurant dans la propriété linked_clients sont ajoutés à la propriété enabled_clients de la connexion Okta.

​
Publier votre intégration dans l’OIN

Après avoir créé une configuration initiale, vous êtes prêt à commencer le processus de soumission à l’OIN. Dans le cadre de ce processus, vous pourrez tester intégralement Express Configuration de bout en bout avant la mise en production :
  1. Inscrivez votre application dans l’OIN 2. Demandez une intégration de type Express Configuration 3. Configurez votre clé publique OIN 4. Testez et validez votre intégration Express Configuration 5. Finalisez votre soumission à l’OIN

​
Enregistrer votre application dans l’OIN

Pour ajouter Express Configuration à une nouvelle application ou à une application existante dans l’OIN, vous avez besoin de :
  • Une instance de votre application web compatible avec Auth0 à utiliser pour les tests
  • Une organisation Okta Integrator Free Plan, avec accès soit au rôle Super Admin, soit aux rôles App et Org Admin
    • Votre organisation Okta Integrator Free Plan doit être configurée comme connexion Okta dans votre tenant Auth0 et activée pour être utilisée avec votre application web compatible avec Auth0 afin de pouvoir effectuer les tests de base
  • Le navigateur Google Chrome avec l’extension Okta Browser Plugin installée (consultez les exigences de l’assistant OIN)
  1. Connectez-vous à votre organisation Okta Integrator Free Plan avec le compte utilisateur que vous avez utilisé pour vous inscrire, ou avec un compte auquel le rôle SUPER_ADMIN ou les rôles d’administration APP_ADMIN et ORG_ADMIN dans Okta ont été attribués.
  2. Accédez à Applications > Your OIN Integrations dans la console d’administration.
  3. S’il s’agit d’une nouvelle application, sélectionnez Build new OIN integration. Sinon, sélectionnez votre intégration OIN existante. L’assistant OIN s’affiche :
Configurer Okta OIN
  1. Sous Add integration capabilities, sélectionnez OpenID Connect (OIDC) comme protocole SSO.
  2. Vous pouvez éventuellement sélectionner Universal Logout et SCIM 2.0, qui sont tous deux fortement recommandés pour toutes les intégrations Okta et pris en charge avec Express Configuration.
  3. Sélectionnez Configure your integration.
  4. Remplissez la section OIN Catalog Properties comme vous le souhaitez. À titre de référence, consultez OIN Catalog Properties.
  5. Sous OIDC Properties, configurez les champs suivants :

    A. Le champ Redirect URIs doit contenir l’URI de rappel (callback) pour votre tenant Auth0. Cela peut utiliser le Domaine personnalisé de votre tenant ou votre Domaine auth0.com.
    Exemple : https://tenant.auth0.com/login/callback

    B. (Facultatif) Définissez Initiate Login URI avec la même valeur que celle que vous avez configurée pour votre Application dans Auth0, comme décrit dans l’Application Auth0 et l’URI d’initiation de connexion. Okta utilisera cette URL pour lancer votre application à partir du tableau de bord de l’utilisateur final.
    Exemple : https://{organization_name}.your-app.com?connection={connection_name}

    C. (Facultatif) Définissez Post-Logout URL sur les URI de redirection après déconnexion pour votre application. Il s’agit de l’emplacement où vous souhaitez envoyer votre utilisateur final après sa déconnexion de votre application. Vous pouvez utiliser des variables d’intégration si votre URI de déconnexion varie selon le tenant.

    D. Définissez Configuration guide URL pour pointer vers vos instructions destinées aux clients expliquant comment configurer le SSO entre Okta et votre application avec Express Configuration. Pour en savoir plus, consultez Customer configuration document guidelines.
    OIN OIDC Settings
  6. Si Universal Logout est sélectionné, configurez les champs suivants sous Universal logout properties :

    A. Définissez l’endpoint Global token revocation sur le nom de votre tenant Auth0. Cette valeur sera remplacée dynamiquement lorsque Express Configuration s’exécutera.

    B. Sous Subject format, sélectionnez issuer et Subject identifier.

    C. Cochez Partial support si vous n’utilisez pas la déconnexion OIDC back-channel entre Auth0 et votre application, mais que votre application utilise des Jetons d’actualisation.
    Okta Admin Console Universal Logout Settings
  7. Si SCIM 2.0 est sélectionné, configurez les champs suivants sous SCIM provisioning properties :

    A. Définissez Base URL sur le nom de votre tenant Auth0. Cette valeur sera remplacée dynamiquement lorsque Express Configuration s’exécutera.

    B. Sous User Operations, sélectionnez Create, Update et Deactivate.

    C. Définissez le lien vers vos instructions destinées aux clients expliquant comment configurer le SSO entre Okta et votre application avec Express Configuration. Consultez Customer configuration document guidelines.
    OIN Express Configuration SCIM Provisioning
  8. Sélectionnez Get started with testing.
  9. Passez à la section Request an express configuration integration.

​
Demander une intégration Express Configuration

Pour activer les fonctionnalités d’Express Configuration pour votre intégration OIN enregistrée, vous devez envoyer un courriel à l’équipe Okta Express Configuration à expressconfig@okta.com avec des renseignements copiés à la fois du portail Okta et du portail Auth0. Pour demander une intégration Express Configuration :
  1. Ouvrez l’application de courriel de votre choix et rédigez un nouveau courriel.
  2. Ajoutez le destinataire : expressconfig@okta.com.
  3. Ajoutez comme objet : Express configuration integration request.
  4. Accédez à la section Auth0 Dashboard > Applications > Okta Integration Network > Request Integration dans Auth0 Dashboard et copiez les renseignements suivants dans le corps du courriel.
Dashboard > Applications > OIN > Request Integrations
  1. Ajoutez le nom de votre organisation Okta Free Integrator, p. ex. : trial-7513274, ainsi que le nom d’affichage de votre intégration OIN dans Okta dans le courriel.
  2. Envoyez le courriel.
Après réception du courriel, l’équipe Okta Express Configuration active Express Configuration pour votre intégration OIN enregistrée et vous renvoie une clé publique que vous devez téléverser dans Auth0 Dashboard.

​
Configurez votre clé publique OIN

Après avoir reçu la clé publique de l’équipe Okta Express Configuration à l’étape précédente, téléversez-la dans la section Auth0 Dashboard > Applications > Okta Integration Network > Request Integration de l’Auth0 Dashboard. Cliquez sur Save.
Téléversement de la clé publique OIN

​
Tester et vérifier votre intégration

Une fois la clé publique téléversée, vous pouvez tester Express Configuration en utilisant votre organisation Okta Free Integrator :
  1. Créez une Auth0 Organization et un compte avec nom d’utilisateur et mot de passe que vous pouvez partager avec l’équipe Okta OIN Operations.
    • Suivez les instructions de l’exemple de flux d’activation client pour créer une Auth0 Organization et un compte avec nom d’utilisateur et mot de passe à cette fin.
    • Au besoin, effectuez les tâches supplémentaires nécessaires dans votre application pour permettre à l’organisation de test d’ouvrir une session, par exemple en créant un nouveau tenant d’application.
  2. Une fois que vous avez créé un compte de test, ouvrez une session dans votre organisation Okta Integrator Free en tant qu’utilisateur ayant soit le rôle de super admin (SUPER_ADMIN), soit les rôles d’admin d’application (APP_ADMIN) et d’admin d’organisation (ORG_ADMIN) rôles.
  3. Dans la console d’administration Okta, accédez à Applications > Your OIN Integrations. Sélectionnez le nom de votre intégration OIN.
  4. Choisissez Configure your integration. Puis choisissez Get started with testing.
  5. Définissez Account URL sur la page de connexion de votre application. Un ingénieur Okta OIN operations se rendra à cette URL et utilisera les identifiants de compte que vous fournissez dans les champs suivants pour ouvrir une session dans votre application.
  6. Définissez Username et Password sur le nom d’utilisateur et le mot de passe d’un compte d’administrateur d’organisation de test que vous avez configuré pour tester Express Configuration.
  7. Définissez Support Contact sur le courriel qu’Okta utilisera pour contacter votre entreprise à propos de votre intégration. Ce courriel n’est pas exposé dans le catalogue OIN ni à vos clients. Il est uniquement visible par l’équipe interne d’Okta.
  8. Sous OIDC Tests, sélectionnez No pour Just-In Time Provisioning afin de passer ce test, et définissez SP Initiate URL sur l’URL de connexion initiée par le fournisseur de services de votre instance d’application.
    Test OIDC de l'intégration OIN
  9. Sélectionnez Test your integration.
  10. Sélectionnez Generate Instance, puis Done.
  11. Accédez à l’onglet Sign On.
  12. Pour tester Express Configuration de Single Sign-On et Universal Logout, sélectionnez Express Configure SSO & UL.
    Express Configuration pour SuperSaaS
  13. Une fois que vous êtes redirigé vers la page Universal Login d’Auth0, ouvrez une session avec votre compte d’administrateur d’organisation et consentez au partage des données.
  14. Pour tester SCIM : sélectionnez Provisioning, puis Express Configure SCIM. Une fois redirigé vers Universal Login d’Auth0, poursuivez le flux de consentement. Une fois terminé, l’intégration SCIM est configurée.
  15. Ensuite, sélectionnez l’onglet Assignments et affectez un utilisateur de votre organisation Okta Free Integrator pour lequel vous avez des identifiants. Si aucun utilisateur approprié n’existe, suivez les instructions pour Add users manually. Si SCIM est activé, l’utilisateur devrait être approvisionné dans votre tenant Auth0. Confirmez à l’aide de l’Auth0 Dashboard.
  16. Pour tester le SSO : utilisez le compte d’utilisateur que vous venez d’affecter et l’instance de test. Ouvrez une session avec les identifiants de ce compte d’utilisateur.
  17. Pour tester Universal Logout : suivez les instructions de Test Universal Logout.

​
Finaliser votre soumission

Les tests de base sont terminés dans la section précédente. Pour finaliser votre soumission, votre configuration doit réussir des tests automatisés :
  1. Dans votre instance d’application, sélectionnez Begin Testing pour finaliser votre soumission.
  2. À côté du nom de l’instance que vous venez de tester avec Express Configuration, sélectionnez Add to Tester.
  3. Pour terminer les tests SSO automatisés, sélectionnez Run test pour les tests IDP flow et/ou SP flow. Ces tests nécessitent le module d’extension de navigateur Okta Browser Plugin. Pour en savoir plus, consultez OIN Wizard Requirements.

    A. Connectez-vous avec l’utilisateur de l’organisation Okta Free Integration que vous avez affecté à l’instance de l’application. Les tests réussissent dès que le module d’extension détecte que vous pouvez vous connecter à votre application avec succès. Pour plus d’informations sur ces tests, consultez Test your integration.

    B. Si vous recevez le message d’erreur invalid_request (no connections enabled for the client) pendant le test de connexion, attendez quelques minutes, puis essayez de nouveau. Les connexions nouvellement créées peuvent prendre quelques minutes avant de fonctionner avec des fonctionnalités comme HRD.

  4. Pour terminer le test Runscope requis pour SCIM, suivez les instructions de la page Test your SCIM API en utilisant Okta SCIM 2.0 Spec Tests.

    A. Pour un deuxième jeton SCIM, utilisez la section Authentication > Enterprise > Okta > [your-express-configred-connection] > Provisioning > Sync user profiles using SCIM > Setup.

    B. Une fois terminé, saisissez l’URL de test Runscope partageable dans les champs Link to Runscope spec test results et Link to Runscope CRUD test results dans l’OIN Wizard.

  5. Lorsque tout est terminé, sélectionnez Submit Integration.

​
Activation des clients

Lorsque votre application est publiée dans l’OIN, vous pouvez mettre à jour la documentation de votre produit pour indiquer que vous prenez en charge Express Configuration avec Okta. La documentation de votre produit doit préciser quels rôles ou types d’utilisateurs sont autorisés à effectuer Express Configuration. Si votre application utilise déjà la fonctionnalité Auth0 Organizations avec des rôles d’administrateur d’organisation, comme dans l’application de référence SaaStart, vous pouvez ajouter les autorisations Express Configuration à ce rôle. Si vous n’avez pas encore déployé Auth0 Organizations pour vos clients, ou si vous n’implémentez pas d’utilisateurs administrateurs dans votre application, consultez l’exemple de flux d’intégration client.

​
Exemple de flux d’habilitation client

Dans votre processus d’intégration client, vous devez recueillir :
  • Le nom de l’organisation du client
  • L’adresse de courriel de l’administrateur du client qui doit avoir les autorisations pour effectuer l’Express Configuration
  • Les domaines de courriel vérifiés que l’IdP du client émet pour les utilisateurs, y compris les domaines de l’administrateur
Recueillez ces renseignements manuellement ou à l’aide de l’expérience d’inscription ou d’intégration destinée à vos clients. Utilisez ces renseignements pour créer une Organisation Auth0 et un compte d’utilisateur administrateur pour ce client :
  1. Créez une Organisation Auth0.
  2. Créez le compte d’utilisateur administrateur dans une connexion Auth0, comme une base de données ou une connexion d’authentification sans mot de passe par courriel.
  3. Associez la connexion à l’Organisation Auth0. Désactivez Membership On Authentication.
  4. Ajoutez le compte d’utilisateur administrateur comme membre de l’Organisation Auth0.
  5. Attribuez un rôle organisationnel à l’utilisateur administrateur avec les autorisations nécessaires pour effectuer l’Express Configuration.

​
Exemple d’Auth0 CLI

Initialisez Auth0 CLI et authentifiez-vous Authentifiez-vous auprès d’Auth0 avec Auth0 CLI. 
auth0 login --scopes "create:users,create:organizations,create:organization_members,create:organization_member_roles,create:organization_connections"
Créer une organisation Auth0 Saisissez le nom de l’organisation et un nom abrégé sans espaces. Si vous avez recueilli plusieurs suffixes de courriel, ajoutez-les en tant que métadonnées d’organisation. 
auth0 orgs create --json \
--display "organization_display_name" \
--name "organization_short_name" \
--metadata 'domains=["domain1.com", "domain2.com"]'
Relevez la valeur de org_id retournée. Créer le compte d’administrateur de l’organisation Dans cet exemple, vous créez un utilisateur dans une connexion d’authentification sans mot de passe par courriel, qui requiert le type de connexion email. La commande vous demande de saisir l’adresse de courriel de l’utilisateur que vous autorisez à effectuer la Configuration Express. 
auth0 api users \
--data '{"email":"user@example.com","connection":"email", "email_verified":true}'

Conseil

Si vous créez cette Organisation pour fournir un compte de test avec un nom d’utilisateur et un mot de passe à l’équipe des opérations Okta OIN, créez le compte de test dans une connexion de base de données partagée ou dédiée :
auth0 api users \
--data '{"email":"user@example.com","connection":"db_connection_name_here", "password": "add_a_long_password_here"}'
Notez l’user_id renvoyé. Associer la connexion à l’Organisation Récupérez l’ID de la connexion : 
auth0 api get "connections" -q "name=connection_name_here"
Associez l’ID de la connexion à l’ID de l’organisation (org_id). 
auth0 api post "organizations/org_id_here/enabled_connections" \
--data '{ "connection_id": "connection_id_here" };
Ajouter l’utilisateur administrateur comme membre de l’organisation Vous avez besoin de org_id et de user_id. 
auth0 api post "organizations/org_id_here/members" \
--data '{ "members": ["user_id__here"] }'
Attribuer le rôle d’organisation avec les autorisations de configuration Express Récupérez l’ID du rôle disposant des autorisations de configuration Express, telles que configurées dans Attribuer des autorisations de configuration Express aux utilisateurs. 
auth0 api get "roles" -q "name_filter=role_name_here"
Attribuez l’ID du rôle aux champs user_id et org_id. 
auth0 api post "organizations/org_id_here/members/user_id_here/roles" --data '{ "roles": ["role_id_here"] }'
Une fois l’opération terminée, votre client peut utiliser le compte d’administrateur de l’organisation pour effectuer la configuration Express dans son organisation Okta avec votre intégration OIN.

​
Recommandations pour l’approvisionnement des comptes administrateur

Que vous utilisiez des comptes utilisateur existants ou que vous en créiez de nouveaux pour activer la Configuration Express, suivez les recommandations ci-dessous.

​
Utiliser un courriel professionnel

Qu’il s’agisse d’un compte administrateur non fédéré basé sur une base de données, d’un compte d’Authentification sans mot de passe par courriel ou d’un compte utilisateur de réseau social, il est préférable que la valeur de l’attribut email corresponde à l’adresse de courriel professionnelle de l’utilisateur qui sera provisionnée avec son compte utilisateur Okta Enterprise (par exemple : john@mycompany.com). Auth0 recommande également de vérifier ces adresses de courriel à l’aide d’un processus de vérification de courriel.

​
Utiliser l’authentification multifacteur

Vous pouvez ajouter une couche de sécurité supplémentaire au flux Express Configuration en exigeant une authentification multifacteur (AMF, MFA) à chaque connexion. L’exemple d’Action Post-Login montre comment vous pouvez, de façon conditionnelle, exiger des facteurs comme WebAuthN avec biométrie de l’appareil et mot de passe à usage unique envoyé par courriel chaque fois qu’Express Configuration s’exécute. L’Action de l’exemple nécessite l’activation de ces facteurs dans votre tenant Auth0 et la sélection de l’option Customize MFA Factors using Actions. 
exports.onExecutePostLogin = async (event, api) => {


if (event.resource_server && event.resource_server.identifier === "urn:auth0:express-configure") {


   api.multifactor.enable('any');
  api.authentication.challengeWith({ type: 'email' });


  if (!event.user.enrolledFactors.some(m => m.type === 'webauthn-platform')) {
     api.authentication.enrollWith({type: 'webauthn-platform'});
   } else {
     api.authentication.challengeWith({type: 'webauthn-platform'});
  }
 }
}

​
Surveiller l’utilisation d’Express Configuration

L’utilisation d’Express Configuration peut être observée dans les journaux du tenant Auth0 en filtrant par OIN Client ID pour chaque Application que vous avez configurée. Cela inclut l’ensemble de l’activité de connexion des administrateurs, ainsi que toutes les opérations d’API visant à créer et gérer les connexions Okta Enterprise. L’OIN Client ID de votre Application peut être consulté aux emplacements suivants :
  • Dans la section Applications > [Application] > Okta Integration Network > Request Integration > Request Express Configuration de l’Auth0 Dashboard.
    • Dans la propriété express_configuration.okta_oin_client_id de votre Application lorsque vous la consultez dans la Auth0 Management API.
Pour en savoir plus sur la recherche dans les journaux avec l’ID client, consultez Log Search Query Syntax.

​
Limitations

​
Référence de la Management API

Pour utiliser la Management API au lieu d’Auth0 Dashboard pour activer Express Configuration pour une application donnée, utilisez les exemples ci-dessous.

​
Créer l’API Okta OIN Express Configuration System

Enregistre le serveur de ressources qui sera utilisé pour authentifier les administrateurs d’organisation. Cette opération n’est requise que si le tableau de bord n’a jamais été utilisé pour configurer Express Configuration pour des applications dans un tenant. Exemple : 
POST /api/v2/resource-servers
{
    "name": "Okta OIN Express Configuration API",
    "identifier": "urn:auth0:express-configure"
  }
Référence du point de terminaison

​
Créer un profil d’attributs d’utilisateur

Crée un profil d’attributs d’utilisateur. Cette étape est requise uniquement s’il n’existe aucun profil ou si le développeur souhaite utiliser un profil personnalisé. Pour partir d’un ensemble de valeurs par défaut pour le profil d’attributs d’utilisateur, appelez d’abord l’endpoint GET /api/v2/user-attribute-profiles/templates et utilisez la réponse comme corps de la requête pour créer le profil d’attributs d’utilisateur. Exemple : 
GET /api/v2/user-attribute-profiles/templates
Référence du point de terminaison 
POST /api/v2/user-attribute-profiles
{
    "name": "Okta OIN Express Configuration API",
    "identifier": "urn:auth0:express-configure"
}
Référence de l’endpoint

​
Créer un profil de Connexion

Créez un profil de Connexion. Cette étape n’est nécessaire que s’il n’existe aucun profil ou si le développeur souhaite utiliser un profil personnalisé. Pour partir d’un ensemble de valeurs par défaut pour le profil de Connexion, appelez le point de terminaison GET /api/v2/connection-profiles/templates et utilisez la réponse dans le corps de la requête pour créer le profil de Connexion. Exemple : 
GET /api/v2/connection-profiles/templates
Référence du point de terminaison 
POST /api/v2/connection-profile
{
    "name": "Okta OIN Express Configuration API",
    "identifier": "urn:auth0:express-configure"
}
Référence du point de terminaison

​
Créer le client de Configuration Express OIN

Créez l’Application de service qu’Okta utilisera pendant la Configuration Express pour une Application donnée. Ce client doit être créé avec les propriétés présentées dans l’exemple ci-dessous. L’attribut organization_require_behavior peut être personnalisé avec l’une des valeurs ci-dessous, qui sont aussi expliquées dans Paramètres de connexion et de consentement de l’administrateur.
  • pre_login_prompt : invite à saisir l’organisation de l’administrateur avant de demander les identifiants.
    • post_login_prompt : invite à saisir les identifiants de l’administrateur. Pour cette option, utilisez le point de terminaison PATCH /api/v2/connections/{id} pour ajouter l’ID client du Client OIN à la propriété enabled_clients de la ou des connexions contenant les comptes d’administrateur.
Exemple : 
POST /api/v2/clients
{
    "name": "Okta OIN Express Configuration",
    "app_type": "express_configuration",
    "organization_require_behavior": "pre_login_prompt",
    "client_authentication_methods": {
      "private_key_jwt": {
        "credentials": []
      }
    }
}
Référence du point de terminaison

​
Configurer les propriétés de l’application SaaS

Définissez les valeurs de configuration pour la propriété express_configuration sur l’application enregistrée qui sera publiée vers l’OIN. Remplacez les valeurs dans les exemples par un Connection Profile ID valide, un User Attribute Profile ID, un OIN client application ID, un URI d’amorçage de la connexion (initiate login URI) et le domaine de tenant Auth0 à utiliser pour cette intégration. L’attribut linked_clients correspond au paramètre décrit dans Activer plusieurs applications sous une seule intégration. L’attribut enable_client correspond au paramètre enabled_clients décrit dans Paramètres de connexion des organisations. L’attribut enable_organization doit normalement être défini à true, sauf si vous n’assignez pas les connexions créées à leurs organisations. L’instance d’application Okta peut tout de même gérer la connexion, mais les utilisateurs Okta ne deviendront pas membres de l’Organisation Auth0. Définir cette valeur à false peut être utile dans le cas décrit dans Maintenir la correspondance des comptes d’administrateur entre les connexions. Exemple : 
PATCH /api/v2/clients/{id}
{
  "express_configuration": {
      "admin_login_domain": "yourAuth0TenantDomain",
      "connection_profile_id": "yourConnectionProfileId",
      "enable_client": true,
      "enable_organization": true,
      "initiate_login_uri_template": "yourInitiateLoginUriTemplate",
      "okta_oin_client_id": "yourOinClientId",
      "user_attribute_profile_id": "yourConnectionProfileId",
"linked_clients": [ 
    { "client_id": "KJM86F2susguvsasSeAsIxxxxxxxxxxx" }, 
    { "client_id": "FIXwZCf5iUElvqy6eidlfxxxxxxxxxxx" }
 ] 
    }
}
Référence du point de terminaison

​
Téléverser la clé publique

Téléversez la clé publique fournie par l’équipe Okta comme information d’identification de l’application client OIN. Exemple : 
POST /api/v2/clients/{oin_client_id}/credentials
{
  "credential_type": "public_key",
  "pem": "-----BEGIN PUBLIC KEY-----\nMIGf..."
}
Référence du point de terminaison

​
Attribuer des clés à l’application cliente OIN

Attribuez les clés publiques importées depuis Okta au client de service OIN. Remplacez yourCredentialId par l’ID des informations d’identification (credential ID) reçu à l’étape précédente. Exemple : 
PATCH /api/v2/clients/{oin_client_id}
{
 "client_authentication_methods": {
    "private_key_jwt": {
      "credentials": [
        {
          "id": "yourCredentialId",
        }
      ]
    }
  }
}
Référence du point de terminaison Mettez à jour les paramètres du tenant afin d’afficher les détails de la portée sur la page de consentement. Ces paramètres améliorent l’expérience de l’utilisateur en fournissant des renseignements sur les autorisations accordées. Ce n’est pas obligatoire, mais c’est recommandé. Exemple : 
PATCH /api/v2/tenants/settings
{ 
  "flags": { "use_scope_descriptions_for_consent": true } 
}
Référence du point de terminaison