> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.generaltranslation.app/llms.txt
> Use this file to discover all available pages before exploring further.
> Décrit comment configurer la Configuration Express avec Auth0 et l’Okta Integration Network (OIN).
# Configuration Express avec Okta
L’[Okta Integration Network (OIN)](https://www.okta.com/integrations/) 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](https://developer.okta.com/docs/guides/oin-universal-logout-overview). Les administrateurs Okta utilisent la [console d’administration d’Okta](https://www.okta.com/okta-administrator-experience) pour configurer ces intégrations dans leur tenant 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](/docs/fr-CA/authenticate/identity-providers/enterprise-identity-providers/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 :
* 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](/docs/fr-CA/authenticate/login/auth0-universal-login/universal-login-vs-classic-login/universal-experience#universal-login-experience).
* 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](/docs/fr-CA/manage-users/organizations) et autorisé à effectuer Express Configuration à l’aide d’un [rôle organisationnel](/docs/fr-CA/manage-users/organizations/configure-organizations/add-member-roles) ou d’une autre méthode d’autorisation.
* Après l’authentification, Auth0 demande le consentement de l’administrateur Okta.
* Une fois le consentement accordé, Okta utilise l’API Express Configuration pour configurer automatiquement une [connexion Okta](/docs/fr-CA/authenticate/identity-providers/enterprise-identity-providers/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](https://developer.okta.com/signup/), avec accès soit au rôle Super Admin, soit aux rôles App Admin et Org Admin.
* Un [abonnement Auth0](https://auth0.com/pricing) 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.
* Cela inclut l’enregistrement de votre application en tant que [Regular Web Application](/docs/fr-CA/get-started/auth0-overview/create-applications/regular-web-apps) ou [Single-Page Application](/docs/fr-CA/get-started/auth0-overview/create-applications/single-page-web-apps) dans Auth0, et la possibilité pour chacun de vos clients de se connecter à cette application à l’aide de son propre [fournisseur d'identité](/docs/fr-CA/authenticate/enterprise-connections) distinct.
* Une [Auth0 Organization](/docs/fr-CA/manage-users/organizations) 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](/docs/fr-CA/get-started/tenant-settings#recommended-settings) 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](https://auth0.com/blog/speed-up-your-customer-identity-journey-with-auth0-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](/docs/fr-CA/get-started/manage-dashboard-access/feature-access-by-role) dans un tenant Auth0 de production est requis pour terminer le processus complet de configuration et de publication.
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](/docs/fr-CA/get-started/auth0-overview/create-applications/regular-web-apps) ou [Single-Page Application](/docs/fr-CA/get-started/auth0-overview/create-applications/single-page-web-apps) 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](/docs/fr-CA/quickstart/webapp/express/interactive).
* 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](https://help.okta.com/en-us/content/topics/settings/new-dashboard-overview.htm).
* (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}`.
**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](/docs/fr-CA/authenticate/enterprise-connections/connection-profile).
#### 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](/docs/fr-CA/authenticate/enterprise-connections/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](/docs/fr-CA/manage-users/organizations/configure-organizations/define-organization-behavior).
* Si votre Application utilise actuellement une [expérience de connexion de type Identifier-First](/docs/fr-CA/authenticate/login/auth0-universal-login/identifier-first) et la détection du domaine d’authentification (home realm discovery) avec vos Applications, consultez la section [Enabling Home Realm Discovery](/docs/fr-CA/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#enable-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.
### Paramètres de consentement et de connexion de l’administrateur
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](https://manage.auth0.com/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**.
* **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](docs/customize/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](/docs/fr-CA/manage-users/organizations/login-flows-for-organizations) 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](/docs/fr-CA/manage-users/organizations/configure-organizations/enable-connections) 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](/docs/fr-CA/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#assign-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](/docs/fr-CA/customize/login-pages/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](/docs/fr-CA/manage-users/organizations) 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éthode** | **Recommandé pour…** |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Attribuer des autorisations de configuration Express à un rôle utilisateur existant | Clients possédant un [rôle](/docs/fr-CA/manage-users/access-control/configure-core-rbac/roles) 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](https://auth0.com/blog/speed-up-your-customer-identity-journey-with-auth0-saastart/). | Clients qui souhaitent utiliser la fonctionnalité de [rôle](/docs/fr-CA/manage-users/access-control/configure-core-rbac/roles) 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 attributs | Clients qui n’utilisent pas actuellement la fonctionnalité de [rôle](/docs/fr-CA/manage-users/access-control/configure-core-rbac/roles) 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](/docs/fr-CA/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#customer-enablement).
### 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](/docs/fr-CA/manage-users/access-control/configure-core-rbac/roles) 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 permission** | **Identifiant de l’API (serveur de ressources)** |
| ------------------------ | ------------------------------------------------ |
| `express_configure:sso` | `urn:auth0:express-configure` |
| `express_configure:scim` | `urn: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](/docs/fr-CA/manage-users/access-control/configure-core-rbac/roles/add-permissions-to-roles).
### 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](/docs/fr-CA/manage-users/access-control/configure-core-rbac/roles) 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](/docs/fr-CA/manage-users/access-control/configure-core-rbac/roles), 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](https://auth0.github.io/auth0-cli/auth0_roles_create.html) pour [créer des rôles](/docs/fr-CA/manage-users/access-control/configure-core-rbac/roles/create-roles). Cet exemple utilise l'Auth0 CLI :
```bash theme={null}
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.
```bash theme={null}
auth0 roles permissions add "$ROLE_ID" \
--api-id "urn:auth0:express-configure" \
--permissions "express_configure:sso"
```
```bash theme={null}
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](/docs/fr-CA/manage-users/organizations/configure-organizations/add-member-roles).
### 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](/docs/fr-CA/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger) 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](/docs/fr-CA/manage-users/user-accounts/metadata).
**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`.
```bash theme={null}
/**
* 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)](/docs/fr-CA/authenticate/login/auth0-universal-login/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](/docs/fr-CA/manage-users/organizations/configure-organizations/create-organizations) 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`
```javascript theme={null}
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.
```javascript theme={null}
/**
*/
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](/docs/fr-CA/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#provision-admin-accounts), 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](/docs/fr-CA/manage-users/organizations/login-flows-for-organizations#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](/docs/fr-CA/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#provision-admin-accounts).
* 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](/docs/fr-CA/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#configure-saas-application-properties).
* 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](https://auth0.com/docs/api/management/v2/clients/get-clients-by-id). 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](/docs/fr-CA/secure/tokens/access-tokens/management-api-access-tokens).
```curl theme={null}
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](https://auth0.com/docs/api/management/v2/clients/patch-clients-by-id) :
```curl theme={null}
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](https://developer.okta.com/signup/), 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](/docs/fr-CA/authenticate/identity-providers/enterprise-identity-providers/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](https://developer.okta.com/docs/guides/submit-app-prereq/main/#oin-wizard-requirements))
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 :
4. Sous **Add integration capabilities**, sélectionnez **OpenID Connect (OIDC)** comme protocole SSO.
5. 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.
6. Sélectionnez **Configure your integration**.
7. Remplissez la section **OIN Catalog Properties** comme vous le souhaitez. À titre de référence, consultez [OIN Catalog Properties](https://developer.okta.com/docs/guides/submit-oin-app/openidconnect/main/#oin-catalog-properties).
8. 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](https://help.okta.com/en-us/content/topics/settings/new-dashboard-overview.htm).
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](https://developer.okta.com/docs/guides/submit-app-prereq/main/#customer-configuration-document-guidelines).
9. 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](https://auth0.com/docs/authenticate/login/logout/universal-logout#revoke-application-user-sessions) entre Auth0 et votre application, mais que votre application utilise des [Jetons d’actualisation](/docs/fr-CA/secure/tokens/refresh-tokens).
10. 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](https://developer.okta.com/docs/guides/submit-app-prereq/main/#customer-configuration-document-guidelines).
11. Sélectionnez **Get started with testing**.
12. Passez à la section [Request an express configuration integration](/docs/fr-CA/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#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](mailto:expressconfig@okta.com)**.
3. Ajoutez comme objet : **Express configuration integration request**.
4. Accédez à la section [Auth0 Dashboard > Applications > Okta Integration Network > Request Integration](https://manage.auth0.com/dashboard/#/applications/#/okta-integration-network/wizard) dans Auth0 Dashboard et copiez les renseignements suivants dans le corps du courriel.
5. 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.
6. 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](https://manage.auth0.com/dashboard/#/applications/#/okta-integration-network/wizard) de l'Auth0 Dashboard. Cliquez sur **Save**.
### 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](/docs/fr-CA/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#example-customer-enablement-flow) 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](https://developer.okta.com/docs/api/openapi/okta-management/guides/roles/#standard-roles).
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.
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**.
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](https://help.okta.com/en-us/content/topics/users-groups-profiles/usgp-add-users.htm). 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](/docs/fr-CA/authenticate/login/logout/universal-logout#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](https://developer.okta.com/docs/guides/submit-app-prereq/main/#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](https://developer.okta.com/docs/guides/submit-oin-app/openidconnect/main/#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](https://developer.okta.com/docs/guides/submit-oin-app/scim/main/#generate-an-instance-for) en utilisant [Okta SCIM 2.0 Spec Tests](https://developer.okta.com/standards/SCIM/SCIMFiles/Okta-SCIM-20-SPEC-Test.json).
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](https://auth0.com/blog/speed-up-your-customer-identity-journey-with-auth0-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](https://auth0.github.io/auth0-cli/auth0_roles_create.html).
```bash theme={null}
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.
```bash theme={null}
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`](/docs/fr-CA/authenticate/passwordless/authentication-methods/email-otp). La commande vous demande de saisir l’adresse de courriel de l’utilisateur que vous autorisez à effectuer la Configuration Express.
```bash theme={null}
auth0 api users \
--data '{"email":"user@example.com","connection":"email", "email_verified":true}'
```
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 :
```bash theme={null}
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 :
```bash theme={null}
auth0 api get "connections" -q "name=connection_name_here"
```
Associez l’ID de la connexion à l’ID de l’organisation (`org_id`).
```bash theme={null}
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`.
```bash theme={null}
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](/docs/fr-CA/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#assign-permissions-to-users).
```bash theme={null}
auth0 api get "roles" -q "name_filter=role_name_here"
```
Attribuez l’ID du rôle aux champs `user_id` et `org_id`.
```bash theme={null}
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](/docs/fr-CA/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#publish-your-integration-to-the-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](/docs/fr-CA/manage-users/user-accounts/verify-emails).
#### 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](/docs/fr-CA/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger) montre comment vous pouvez, de façon conditionnelle, exiger des facteurs comme [WebAuthN avec biométrie de l’appareil](/docs/fr-CA/secure/multi-factor-authentication/fido-authentication-with-webauthn/configure-webauthn-device-biometrics-for-mfa) et [mot de passe à usage unique envoyé par courriel](/docs/fr-CA/secure/multi-factor-authentication/multi-factor-authentication-factors/configure-email-notifications-for-mfa) chaque fois qu’Express Configuration s’exécute.
L’Action de l’exemple nécessite l’[activation de ces facteurs](/docs/fr-CA/secure/multi-factor-authentication/enable-mfa#enable-mfa-in-the-auth0-dashboard) dans votre tenant Auth0 et la sélection de l’option **Customize MFA Factors using Actions**.
```javascript theme={null}
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](/docs/fr-CA/deploy-monitor/logs) 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](https://auth0.com/docs/api/management/v2/clients/get-clients-by-id).
Pour en savoir plus sur la recherche dans les journaux avec l’ID client, consultez [Log Search Query Syntax](/docs/fr-CA/deploy-monitor/logs/log-search-query-syntax).
## Limitations
* Un seul tenant Auth0 peut être utilisé dans une seule intégration OIN. Si la même application est déployée dans plusieurs régions Auth0, chaque région nécessite sa propre intégration OIN.
* Une intégration OIN dans une organisation Okta peut créer une connexion Okta unique dans une organisation Auth0 correspondante. La fonctionnalité Express Configuration n’est pas prise en charge pour plus d’une instance d’une application OIN au sein d’une organisation Okta.
* Chaque intégration unique répertoriée dans l’OIN crée une connexion Okta indépendante. Si vous avez plusieurs applications qui nécessitent une [expérience de connexion axée sur l’identifiant (Identifier-First)](https://auth0.com/docs/authenticate/login/auth0-universal-login/identifier-first) avec découverte du domaine d’origine (home realm discovery), nous recommandons de publier [plusieurs applications sous une seule intégration](/docs/fr-CA/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#enable-multiple-applications-under-a-single-integration).
* Lorsque vous activez [plusieurs applications sous une seule intégration](/docs/fr-CA/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#enable-multiple-applications-under-a-single-integration), Okta affiche seulement l’application OIN principale dans son [tableau de bord des utilisateurs finaux](https://help.okta.com/en-us/content/topics/settings/new-dashboard-overview.htm).
## Référence de la Management API
Pour utiliser la [Management API](https://auth0.com/docs/api/management/v2) 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 :
```curl theme={null}
POST /api/v2/resource-servers
{
"name": "Okta OIN Express Configuration API",
"identifier": "urn:auth0:express-configure"
}
```
[Référence du point de terminaison](/docs/fr-CA/api/management/v2/resource-servers/post-resource-servers)
### Créer un profil d’attributs d’utilisateur
Crée un [profil d’attributs d’utilisateur](/docs/fr-CA/authenticate/enterprise-connections/user-attribute-profile). 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 :
```curl theme={null}
GET /api/v2/user-attribute-profiles/templates
```
[Référence du point de terminaison](https://auth0.com/docs/api/management/v2/user-attribute-profiles/post-user-attribute-profiles)
```curl theme={null}
POST /api/v2/user-attribute-profiles
{
"name": "Okta OIN Express Configuration API",
"identifier": "urn:auth0:express-configure"
}
```
[Référence de l’endpoint](https://auth0.com/docs/api/management/v2/user-attribute-profiles/post-user-attribute-profiles)
### 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 :
```curl theme={null}
GET /api/v2/connection-profiles/templates
```
[Référence du point de terminaison](https://auth0.com/docs/api/management/v2/connection-profiles/get-connection-profile-templates)
```curl theme={null}
POST /api/v2/connection-profile
{
"name": "Okta OIN Express Configuration API",
"identifier": "urn:auth0:express-configure"
}
```
[Référence du point de terminaison](https://auth0.com/docs/api/management/v2/connection-profiles/post-connection-profiles)
### 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](/docs/fr-CA/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#administrator-login-and-consent-settings).
* `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 :
```curl theme={null}
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](https://auth0.com/docs/api/management/v2/clients/post-clients)
### 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](/docs/fr-CA/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#enable-multiple-applications-under-a-single-integration).
L’attribut `enable_client` correspond au paramètre `enabled_clients` décrit dans [Paramètres de connexion des organisations](/docs/fr-CA/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#organization-login-settings).
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](/docs/fr-CA/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#maintain-admin-account-matching-across-connections).
Exemple :
```curl theme={null}
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](https://auth0.com/docs/api/management/v2/clients/patch-clients-by-id)
### 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 :
```curl theme={null}
POST /api/v2/clients/{oin_client_id}/credentials
{
"credential_type": "public_key",
"pem": "-----BEGIN PUBLIC KEY-----\nMIGf..."
}
```
[Référence du point de terminaison](https://auth0.com/docs/api/management/v2/clients/post-credentials)
### 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 :
```curl theme={null}
PATCH /api/v2/clients/{oin_client_id}
{
"client_authentication_methods": {
"private_key_jwt": {
"credentials": [
{
"id": "yourCredentialId",
}
]
}
}
}
```
[Référence du point de terminaison](https://auth0.com/docs/api/management/v2/clients/patch-clients-by-id)
### Personnaliser l’invite de consentement de vos tenants
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 :
```curl theme={null}
PATCH /api/v2/tenants/settings
{
"flags": { "use_scope_descriptions_for_consent": true }
}
```
[Référence du point de terminaison](https://auth0.com/docs/api/management/v2/tenants/patch-settings)