> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> Décrit comment configurer Express Configuration avec Auth0 et l’Okta Integration Network (OIN).
# Express Configuration with Okta
L’[Okta Integration Network (OIN)](https://www.okta.com/integrations/) est un catalogue d’applications SaaS pour lesquelles Okta propose une expérience de configuration express afin d’activer le Single Sign-On (SSO) avec OpenID Connect, le Provisioning automatisé des utilisateurs avec SCIM et [Universal Logout](https://developer.okta.com/docs/guides/oin-universal-logout-overview). Les administrateurs Okta utilisent l’[Okta Admin Console](https://www.okta.com/okta-administrator-experience) pour configurer ces intégrations dans leur tenant Okta :
Express Configuration permet aux clients d’entreprise de configurer de façon sécurisée des intégrations d’identité avec des applications SaaS, sans avoir à copier-coller des valeurs de configuration propres au protocole.
Express Configuration offre les avantages suivants aux administrateurs Okta et aux développeurs d’applications SaaS :
* Réduit le temps nécessaire à la configuration d’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 informations d’authentification et aux paramètres de configuration.
* Simplifie et normalise le processus de déploiement de l’intégration. Ce flux de travail automatisé permet des déploiements uniformes et reproductibles des intégrations d’application chez plusieurs clients ou dans plusieurs environnements, tout en favorisant un écosystème applicatif évolutif et en réduisant les risques d’erreur humaine.
* Élimine la complexité de la configuration manuelle, ce qui permet aux administrateurs clients d’Okta d’ajouter rapidement des instances d’intégrations OIN prises en charge par Auth0.
## Fonctionnement
L’API Express Configuration permet aux applications Auth0 publiées dans l’OIN pour les 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 Universal Logout au sein d’une Auth0 Organization.
Consultez le flux de travail d’Express Configuration pour une application Auth0 dans l’OIN :
* Un administrateur Okta ouvre une session dans le portail Okta et sélectionne l’application compatible avec Express Configuration dans l’OIN.
* 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 identifiants d’un utilisateur de l’application autorisé à effectuer Express Configuration. Dans Auth0, il s’agit d’un utilisateur membre d’une [organisation](/docs/fr-ca/manage-users/organizations) et autorisé à effectuer Express Configuration au moyen 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.
* Après avoir donné son consentement, 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 de l’application et constater que l’authentification unique fonctionne immédiatement.
Les développeurs Auth0 peuvent aussi configurer leur intégration OIN pour permettre la configuration Express de SCIM et d’Universal Logout, qui sont tous deux recommandés :
* Lorsque SCIM est activé, les administrateurs Okta peuvent configurer SCIM en accédant à la section **Provisioning** des détails de l’application et en sélectionnant **Express Configure SCIM**.
* Lorsque Universal Logout est activé, il est automatiquement configuré dans le cadre de l’intégration OpenID Connect.
## Prérequis
Pour publier une application dans l’OIN avec Express Configuration activée, vous devez disposer de ce qui suit :
* Une [Okta Integrator Free Plan org](https://developer.okta.com/signup/), avec accès soit au rôle Super Admin, soit aux rôles App and Org Admin.
* Un [abonnement Auth0](https://auth0.com/pricing) qui vous 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 à l’aide d’une architecture multi-organisation.
* Cela comprend 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, ainsi que la possibilité, pour chacun de vos clients, de se connecter à cette application à l’aide de ses propres [fournisseurs d’identité](/docs/fr-ca/authenticate/enterprise-connections).
* Une [Auth0 Organization](/docs/fr-ca/manage-users/organizations) doit être déployée, ou pouvoir l’être, pour chaque client utilisant Express Configuration. Les Organizations et les rôles organisationnels servent à autoriser certains utilisateurs à effectuer la configuration express et à créer des connexions Okta uniquement au sein des organisations auxquelles ils appartiennent.
* Votre tenant Auth0 doit avoir le paramètre de tenant [Enable Application Connections](/docs/fr-ca/get-started/tenant-settings#recommended-settings) désactivé.
**Conseil** : Pour voir un exemple d’application qui implémente une architecture multilocataire comprenant 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/).
## Configurez 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 d’Auth0](/docs/fr-ca/get-started/manage-dashboard-access/feature-access-by-role) dans un tenant Auth0 de production est requis pour réaliser 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 Initiate Login URI Template
* Un [Connection Profile (CP)](/docs/fr-ca/authenticate/enterprise-connections/connection-profile)
* Un [User Attribute Profile](/docs/fr-ca/authenticate/enterprise-connections/user-attribute-profile)
* Les paramètres de connexion de l’organisation
* Les paramètres de connexion et de consentement de l’administrateur
### Enregistrer une application avec Initiate Login URI Template
1. Enregistrez 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 Dashboard.
2. Une fois l’application enregistrée, sélectionnez l’application que vous avez créée et accédez à l’onglet **Okta Integration Network** pour démarrer l’assistant de configuration Express Configuration.
3. Sélectionnez **Get Started**.
4. Passez en revue les prérequis et sélectionnez **Continue**.
5. Enregistrez un **Initiate Login URI Template**. Ce modèle met en place un endpoint dans votre application afin de rediriger automatiquement les utilisateurs finaux vers l’endpoint `/authorize` d’Auth0 pour l’authentification. Pour voir un exemple de Login endpoint, consultez la route `/login` dans le [Express SDK Quickstart](/docs/fr-ca/quickstart/webapp/express/interactive).
* Une fois Express Configuration lancée pour une instance d’application, Okta utilise le **Initiate Login URI Template** pour lancer l’application à partir du [end-user dashboard](https://help.okta.com/en-us/content/topics/settings/new-dashboard-overview.htm).
* (Facultatif) Définissez `organization_name`, `organization_id,` et `connection_name` pour l’endpoint `/authorize` d’Auth0 afin d’identifier l’organization ou la connection à utiliser. Okta remplace dynamiquement ces variables lorsque l’URL est lancée à partir du end-user dashboard. Exemple : `https://{organization_name}.your-app.com?connection={connection_name}`.
**Exemples d’Initiate Login URI :**
`https://your-app.com/login`
`https://your-app.com/login?connection={connection_name}`
`https://{organization_name}.your-app.com?connection={connection_name}`
#### Connection Profile
Dans l’Initiate Login URI Template, vous pouvez ajouter un **Connection Profile**. Le [Connection Profile](/docs/fr-ca/authenticate/enterprise-connections/connection-profile) permet à Auth0 de préciser comment les paramètres privés de vos connexions doivent être configurés lorsqu’elles sont créées à l’aide 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 pour déterminer comment 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** de la connexion sur la page Universal Login d’Auth0
Si vous n’avez pas configuré de Connection Profile, Auth0 fournit un Connection Profile par défaut avec des paramètres courants et recommandés appliqués aux connexions configurées avec Express Configuration.
Pour savoir comment personnaliser le CP par défaut, consultez [Connection Profile](/docs/fr-ca/authenticate/enterprise-connections/connection-profile).
#### User Attribute Profile
Dans le champ Initiate Login URI Template, vous pouvez ajouter un **User Attribute Profile**. Le [User Attribute Profile (UAP)](/docs/fr-ca/authenticate/enterprise-connections/user-attribute-profile) permet aux développeurs Auth0 de définir, de gérer et de mapper les attributs utilisateur de manière cohérente dans les différents protocoles pris en charge par Auth0. Lorsqu’il est utilisé avec Express Configuration, le User Attribute Profile permet aux développeurs de personnaliser les mappages d’attributs OpenID Connect et SCIM qui seront inscrits dans la connexion Okta générée par Express Configuration.
Si vous n’avez pas configuré de User Attribute Profile, Auth0 fournit un User Attribute Profile 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 le UAP par défaut, consultez [User Attribute Profile](/docs/fr-ca/authenticate/enterprise-connections/user-attribute-profile).
### Paramètres de connexion de l’organisation
Auth0 Organizations est nécessaire pour autoriser certains utilisateurs d’une organisation à créer des connexions isolées, mais n’est pas nécessaire pour modifier le flux de connexion actuel 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 Identifier-First](/docs/fr-ca/authenticate/login/auth0-universal-login/identifier-first) et Home Realm Discovery pour vos applications, consultez la section [Activation de Home Realm Discovery](/docs/fr-ca/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#enable-home-realm-discovery) pour savoir comment activer Home Realm Discovery.
* Si vous souhaitez utiliser plusieurs applications dans `enabled_clients` 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 **Activer cette application pour les connexions créées**. Lorsque ce paramètre est activé, chaque Express Configuration d’une connexion Okta est associée directement à votre application. Utilisez le paramètre `enabled_clients` requis sur la connexion.
### Paramètres de connexion et de consentement de l’administrateur
Lorsque Express Configuration est activé, Auth0 crée un ID d’application cliente supplémentaire, 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 connexion et de consentement de l’administrateur dans l’application que vous souhaitez publier dans l’OIN, sous **Configurer le profil d’intégration**.
1. Accédez à [Auth0 Dashboard > Applications](https://manage.auth0.com/dashboard/#/applications).
2. Choisissez l’application que vous souhaitez publier dans l’OIN.
3. Sélectionnez Okta Integration Network.
4. Vérifiez que vous disposez des prérequis nécessaires et sélectionnez **Continue**.
5. Dans la section **Configurer le profil d’intégration**, configurez les options dans **Paramètres d’administration**.
* **Domaine de connexion administrateur** : 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 [Domaines personnalisés](docs/customize/custom-domains).
* **Nom d’affichage de l’application Express Configuration de l’OIN** : nom de l’application cliente OIN affiché dans la boîte de dialogue de consentement.
* **Flux de connexion administrateur** : définit le flux de [connexion d’organisation](/docs/fr-ca/manage-users/organizations/login-flows-for-organizations) pour l’application cliente OIN et est utilisé lorsqu’un administrateur Okta exécute Express Configuration depuis la console Okta. Sélectionnez l’une des options suivantes :
* **Demander l’organisation** : les administrateurs doivent d’abord sélectionner leur organisation, puis l’expérience de connexion de leur Auth0 organisation leur est présentée. Les administrateurs peuvent se connecter à l’aide d’une [connexion existante](/docs/fr-ca/manage-users/organizations/configure-organizations/enable-connections) configurée dans cette organisation.
* **Demander les identifiants** : les administrateurs doivent d’abord fournir leurs identifiants de connexion. Lorsque 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 de base de données partagée, d’une connexion Passwordless par courriel ou d’une autre connexion pouvant être associée à toutes les Auth0 organisations.
* **Rôle d’administrateur** : pour exécuter Express Configuration, l’administrateur doit se voir attribuer les permissions appropriées. Consultez [Attribuer des permissions Express Configuration aux utilisateurs](/docs/fr-ca/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#assign-permissions-to-users) pour savoir comment autoriser les administrateurs de la façon la mieux adaptée à votre déploiement Auth0 actuel.
Pour une expérience de consentement optimale, définissez l’indicateur `use_scope_descriptions_for_consent` de votre tenant sur `true`, comme décrit dans [Personnaliser les invites de consentement](/docs/fr-ca/customize/login-pages/customize-consent-prompts). Vous aurez l’occasion de voir votre invite de consentement plus tard, lorsque vous testerez et vérifierez votre intégration.
## Attribuer des permissions aux utilisateurs
Pour Okta, les administrateurs doivent avoir un compte d’utilisateur d’application doté des permissions requises pour effectuer Express Configuration pour une application SaaS propulsée par Auth0.
Pour Auth0, cette permission peut être accordée à tout utilisateur d’application, à condition que l’utilisateur soit membre d’une [Auth0 Organization](/docs/fr-ca/manage-users/organizations) dans laquelle les connexions configurées avec Express Configuration sont créées, notamment :
* Un utilisateur dans une connexion de base de données dédiée, créée exclusivement pour une seule Organization
* Un utilisateur dans une connexion de base de données partagée qui est membre d’une ou de plusieurs Organizations
* Un utilisateur ayant une connexion Passwordless par courriel qui est membre d’une ou de plusieurs Organizations
* Un utilisateur dans une connexion sociale ou une connexion d’entreprise existante qui est membre d’une ou de plusieurs Organizations
Une fois ces conditions remplies, Auth0 offre des moyens souples d’attribuer les permissions Express Configuration et permet aux développeurs de choisir la méthode la mieux adaptée à leur déploiement Auth0 actuel :
| **Méthode** | **Recommandée pour...** |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Attribuer les permissions Express Configuration à un rôle utilisateur existant | Les clients qui ont déjà un [rôle](/docs/fr-ca/manage-users/access-control/configure-core-rbac/roles) d’utilisateur d’application dans leur tenant Auth0. |
| Attribuer un nouveau rôle aux utilisateurs d’application qui ont besoin des permissions Express Configuration, comme illustré dans l’[application de référence SaaStart](https://auth0.com/blog/speed-up-your-customer-identity-journey-with-auth0-saastart/). | Les clients qui veulent utiliser la fonctionnalité de [rôle](/docs/fr-ca/manage-users/access-control/configure-core-rbac/roles) d’Auth0 pour accorder des permissions Express Configuration à des utilisateurs individuels. Cela peut être fait avec l’Auth0 Dashboard ou la Management API. |
| Utiliser une Post-Login Action pour attribuer dynamiquement des permissions à l’aide du contrôle d’accès basé sur les attributs | Les 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 préfèrent utiliser une Post-Login Action pour attribuer dynamiquement des permissions en fonction des attributs de l’utilisateur, plutôt que d’utiliser l’Auth0 Dashboard ou d’effectuer des appels à la Management API pour attribuer des rôles. |
Pour obtenir des conseils sur l’approvisionnement de comptes administrateur afin d’utiliser Express Configuration, consultez [Customer Enablement](/docs/fr-ca/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#customer-enablement).
### Attribuer des permissions à un rôle utilisateur d’application existant
Utilisez cette méthode pour attribuer des permissions d’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 avez déjà un ou plusieurs rôles représentant un utilisateur administratif à attribuer à un administrateur des TI chargé de déployer l’application.
Permissions d’API requises :
| **Nom de la permission** | **Identifiant de l’API (Resource Server)** |
| ------------------------ | ------------------------------------------ |
| `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 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, mais que vous n’avez pas de rôle correspondant à un utilisateur administratif, comme un administrateur TI, à qui l’on attribuerait le déploiement de l’application.
Cette méthode convient aussi aux développeurs Auth0 qui n’utilisent pas actuellement la [fonctionnalité RBAC d’Auth0](/docs/fr-ca/manage-users/access-control/configure-core-rbac/roles), mais qui souhaitent s’en servir pour obtenir un contrôle granulaire sur les utilisateurs autorisés à y accéder, soit au moyen de l’Auth0 Dashboard, soit de la Management API.
#### Créer un rôle
Utilisez Auth0 Dashboard, Management API ou [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 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 indiqué. Remplacez `$ROLE_ID` par l’ID du rôle auquel vous voulez attribuer ces permissions.
Si vous utilisez cette méthode, vous devrez mettre à jour votre processus d’intégration des clients afin d’attribuer ce rôle à tout nouvel utilisateur de l’organisation ayant 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 de l’organisation, consultez [Ajouter des rôles de membre](/docs/fr-ca/manage-users/organizations/configure-organizations/add-member-roles).
### Attribuer des permissions en fonction des attributs utilisateur à l’aide d’une Action post-login
Utilisez cette méthode pour attribuer 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 afin d’attribuer dynamiquement des permissions selon les attributs utilisateur, plutôt que d’utiliser le contrôle d’accès basé sur les rôles (RBAC), la Management API ou l’Auth0 Dashboard pour attribuer des rôles aux utilisateurs.
Cette méthode convient aux clients Auth0 qui ont déployé Auth0 selon 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 autorisations Express Configuration selon une logique personnalisée plutôt que par attribution de rôle
*/
exports.onExecutePostLogin = async (event, api) => {
//vérifier si la requête concerne un jeton d'accès à l'API EC
if (event.resource_server && event.resource_server.identifier === "urn:auth0:express-configure") {
//ajouter des autorisations selon une condition personnalisée
if (event.user.app_metadata && event.user.app_metadata.is_admin === true) {
api.accessToken.addScope("express_configure:sso");
api.accessToken.addScope("express_configure:scim");
}
//sinon rejeter l'accès si un jeton d'accès EC est demandé
else {
api.access.deny('Access denied');
}
}
};
```
## Activer Home Realm Discovery
Avant d’exécuter Express Configuration, vous devez recueillir et vérifier les adresses courriel des clients dans le cadre du processus d’onboarding afin d’activer HRD.
Vous pouvez utiliser Express Configuration avec Auth0 Actions si votre application repose sur l’[Identifier-First login experience](/docs/fr-ca/authenticate/login/auth0-universal-login/identifier-first) et utilise Home Realm Discovery (HRD) pour associer les utilisateurs à leurs fournisseurs d’identité (IdP) en fonction de leur adresse courriel.
Les adresses courriel doivent être stockées dans un emplacement accessible aux Actions post-login pendant le workflow Express Configuration, notamment :
* Un ou plusieurs domaines de courriel peuvent être stockés dans les [métadonnées de l’organisation](/docs/fr-ca/manage-users/organizations/configure-organizations/create-organizations) de l’Auth0 Organization du client.
* Votre action post-login peut effectuer un appel d’API pour récupérer les domaines vérifiés à partir de n’importe quel système de votre environnement où ils sont stockés.
Lorsque l’utilisateur administrateur lance la configuration express dans le portail Okta et s’authentifie, ces actions ajoutent les domaines de courriel au token qu’Okta reçoit. Okta les extrait ensuite et les utilise pour configurer la connexion Okta avec la bonne configuration HRD.
**Exemple 1**
Dans cet exemple, les domaines vérifiés sont stockés dans les métadonnées de connexion de l’Auth0 Organization, ce qui nécessite une chaîne délimitée 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?.resource_server?.identifier === "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 d’API pour récupérer les domaines vérifiés depuis un système de stockage de votre environnement.
```javascript theme={null}
/**
*/
exports.onExecutePostLogin = async (event, api) => {
if (event?.resource_server?.identifier === "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’administrateur entre les connexions
Auth0 permet de provisionner des comptes d’utilisateur avec la même adresse courriel dans différentes connexions. Un utilisateur final peut avoir un compte de connexion de base de données, Social ou sans mot de passe avec son adresse courriel professionnelle, tout en ayant aussi la même adresse courriel dans son compte Okta fédéré.
Lorsque vous utilisez l’option **Prompt for Credentials** dans le [flux de connexion et de consentement de l’administrateur](/docs/fr-ca/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#provision-admin-accounts), Home Realm Discovery commence à faire correspondre les utilisateurs ayant un suffixe de domaine donné à la nouvelle connexion Okta plutôt qu’à d’autres types de connexion après son ajout à l’organisation. Pour en savoir plus sur ce comportement de connexion de l’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 la session initiale de l’utilisateur administrateur Auth0. Si l’identifiant du compte administrateur est une adresse courriel correspondant à la nouvelle connexion Okta, l’administrateur y sera redirigé.
Ce comportement peut être géré ou évité de l’une des façons suivantes :
* Utilisez l’option **Prompt for Organization** dans le [flux de connexion et de consentement de l’administrateur](/docs/fr-ca/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#provision-admin-accounts).
* Activez les permissions d’Express Configuration pour le nouveau compte Okta qui contient l’adresse courriel vérifiée correspondante après son provisionnement.
* Si vous utilisez Auth0 Organizations uniquement pour le flux de consentement de l’administrateur d’Express Configuration, et non dans 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).
* Il ne s’agit pas d’un problème si l’identifiant de l’utilisateur administrateur n’est pas une adresse courriel, par exemple un nom d’utilisateur dans une connexion de base de données.
## Activer plusieurs applications dans une seule intégration
Si vous voulez que les utilisateurs finaux d’une même Express Configuration sur une connexion Okta puissent accéder à 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 le Client ID de votre application enregistrée et `{yourAccessToken}` par un jeton d’accès pour Management APIv2. Pour savoir comment obtenir un jeton d’accès à utiliser avec la 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’application supplémentaires à la 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 Express Configuration est lancée, tous ces ID d’application figurant dans la propriété linked\_clients seront ajoutés à la propriété `enabled_clients` de la connexion Okta.
## Publiez votre intégration dans l’OIN
Après avoir créé une configuration de base, vous êtes prêt à entamer le processus de soumission à l’OIN. Dans le cadre de ce processus, vous pourrez effectuer un test de bout en bout complet d’Express Configuration avant la mise en ligne :
1. Enregistrez votre application dans l’OIN
2\. Ajoutez Express Configuration à votre intégration OIN
3\. Configurez votre clé publique OIN
4\. Testez et vérifiez votre intégration Express Configuration
5\. Finalisez votre soumission à l’OIN
### Enregistrez votre application dans l’OIN
Pour ajouter Express Configuration à une application nouvelle ou existante dans l’OIN, vous devez disposer des éléments suivants :
* Une instance de votre application web compatible avec Auth0 à utiliser pour les tests
* Une [Okta Integrator Free Plan org](https://developer.okta.com/signup/), avec accès soit au rôle Super Admin, soit aux rôles App Admin et Org Admin
* Votre Okta Integrator Free Plan org doit être configurée comme une [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 d’effectuer les tests de base
* Le navigateur Google Chrome avec le Okta Browser Plugin installé (consultez les [exigences de l’assistant OIN](https://developer.okta.com/docs/guides/submit-app-prereq/main/#oin-wizard-requirements))
1. Ouvrez une session dans votre Okta Integrator Free Plan org avec le compte d’utilisateur que vous avez utilisé pour vous inscrire, ou avec un compte auquel le rôle `SUPER_ADMIN` ou les rôles d’administrateur `APP_ADMIN` et `ORG_ADMIN` dans Okta ont été attribués.
2. Accédez à **Applications > Your OIN Integrations** dans l’Admin Console.
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 aussi sélectionner **Universal Logout** et **SCIM 2.0**; ces deux options sont fortement recommandées pour toutes les intégrations Okta et sont prises en charge avec Express Configuration.
6. Sélectionnez **Add integration details**.
7. Remplissez la section **OIN Catalog Properties** selon vos besoins. Pour en savoir plus, consultez [OIN Catalog Properties](https://developer.okta.com/docs/guides/submit-oin-app/openidconnect/main/#oin-catalog-properties).
8. Sélectionnez **Configure your integration**. C’est sur cet écran que vous activez Express Configuration pour votre application.
#### Ajouter Express Configuration à votre intégration OIN
Pour activer les capacités d’Express Configuration pour votre intégration OIN enregistrée :
1. À l’écran **Configure your integration** de l’assistant OIN, sélectionnez **Enable Express Configuration**. Une fenêtre s’affiche et vous demande des renseignements à récupérer depuis votre tenant Auth0.
2. Dans une nouvelle fenêtre de navigateur, accédez à [Auth0 Dashboard > Applications > \[Application\] > Okta Integration Network > Create OIN Integration](https://manage.auth0.com/dashboard/#/applications/#/okta-integration-network/wizard) et copiez les renseignements indiqués à l’écran.
3. Revenez à l’écran **Configure your integration** de l’assistant OIN, puis collez les renseignements dans le champ **Express Configuration Information**.
4. Sélectionnez **Continue**.
#### Configurer votre clé publique OIN
Ensuite, suivez les instructions pour télécharger depuis Okta un fichier de clé publique que vous devrez téléverser dans Auth0.
1. Dans la fenêtre **Configuration Express pour les apps Auth0** de l’assistant OIN, choisissez **Télécharger la clé (.pem)** pour enregistrer la clé sur votre appareil.
2. Téléversez le fichier dans **[Auth0 Dashboard > Applications > \[Application\] > Okta Integration Network > Créer une intégration OIN](https://manage.auth0.com/dashboard/#/applications/#/okta-integration-network/wizard)**.
3. Sélectionnez **Enregistrer**.
4. Revenez à l’écran **Configurer votre intégration** du portail Okta, puis choisissez **Terminer**. Cela préremplit automatiquement plusieurs des champs de configuration requis pour votre intégration.
#### Terminez la configuration de votre intégration
1. Sous **OIDC Properties**, définissez les champs suivants :
* **Redirect URIs** devrait être automatiquement défini sur l’URI de rappel de votre tenant Auth0. Vous pouvez utiliser le domaine personnalisé de votre tenant ou votre domaine `auth0.com`. Exemple : `https://tenant.auth0.com/login/callback`
* **Initiate Login URI** devrait être automatiquement défini sur la valeur que vous avez configurée pour votre application dans Auth0, comme décrit dans [Enregistrer une application avec Initiate Login URI Template](/docs/fr-ca/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#register-an-application-with-initiate-login-uri-template). Okta utilisera cette URL pour lancer votre application à partir du tableau de bord de l’utilisateur final. Notez que les noms des variables ont été modifiés pour correspondre aux variables d’intégration affichées sur cet écran.
* (Facultatif). Définissez **Post-Logout URL** sur les URI de redirection de déconnexion de votre application. Il s’agit de l’emplacement vers lequel vous voulez rediriger 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éfinissez **Configuration guide URL** pour créer un lien vers vos instructions destinées aux clients expliquant comment configurer l’SSO entre Okta et votre application avec Express Configuration. Pour en savoir plus, consultez [Directives sur le document de configuration client](https://developer.okta.com/docs/guides/submit-app-prereq/main/#customer-configuration-document-guidelines).
2. Si **Universal Logout** est sélectionné, confirmez que les valeurs suivantes sont définies sous les propriétés de déconnexion universelle :
* Le **endpoint** **Global token revocation** devrait être automatiquement défini. Cette valeur sera remplacée dynamiquement lorsque Express Configuration s’exécutera.
* Le **format du sujet** devrait être automatiquement défini sur **Issuer and Subject identifier**.
* 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 [refresh tokens](/docs/fr-ca/secure/tokens/refresh-tokens).
3. Si **SCIM 2.0** est sélectionné, confirmez que les valeurs suivantes sont définies sous **SCIM provisioning properties** :
* **Base URL** devrait être défini sur une variable d’intégration. Cette valeur sera remplacée dynamiquement lorsque Express Configuration s’exécutera.
* **User Operations** devrait être automatiquement défini sur **Create**, **Read**, **Update** et **Deactivate**.
* Définissez le lien vers vos instructions destinées aux clients expliquant comment configurer l’SSO entre Okta et votre application avec Express Configuration. Consultez [Directives sur le document de configuration client](https://developer.okta.com/docs/guides/submit-app-prereq/main/#customer-configuration-document-guidelines).
4. Sélectionnez **Get started with testing**.
### Tester et vérifier votre intégration
Après avoir téléversé la clé publique dans Auth0, vous pouvez tester Express Configuration en utilisant votre organisation Okta Free Integrator :
1. Créez une Auth0 organisation et un compte avec nom d’utilisateur et mot de passe que vous pourrez partager avec l’équipe des opérations OIN d’Okta.
* Suivez les instructions du [flux d’activation d’un client exemple](/docs/fr-ca/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#example-customer-enablement-flow) pour créer une Auth0 organisation et un compte avec nom d’utilisateur et mot de passe à cette fin.
* Au besoin, effectuez toute configuration supplémentaire requise dans votre application pour permettre à l’organisation de test de se connecter, par exemple en créant un nouveau tenant d’application.
2. Une fois le compte de test créé, connectez-vous à votre organisation Okta Integrator Free en tant qu’utilisateur ayant soit le rôle de superadministrateur (`SUPER_ADMIN`), soit les [rôles](https://developer.okta.com/docs/api/openapi/okta-management/guides/roles/#standard-roles) d’administrateur de l’application (`APP_ADMIN`) et de l’organisation (`ORG_ADMIN`).
3. Accédez à **Applications > Your OIN Integrations** dans la console d’administration Okta. Sélectionnez le nom de votre intégration OIN.
4. Choisissez **Configure your integration**. Choisissez ensuite **Get started with testing.**
5. Définissez **Account URL** comme étant la login page de votre application. Un ingénieur des opérations OIN d’Okta accède à cette URL et utilise l’information d’identification du compte que vous fournissez dans les champs suivants pour se connecter à votre application.
6. Définissez **Username** et **Password** comme étant le nom d’utilisateur et le mot de passe d’un compte administrateur de l’organisation de test que vous avez configuré pour tester Express Configuration.
7. Définissez **Support Contact** comme étant l’adresse courriel qu’Okta utilisera pour communiquer avec votre entreprise au sujet de votre intégration. Cette adresse courriel n’est pas affichée dans le catalogue OIN ni à vos clients. Elle est visible uniquement par l’équipe interne d’Okta.
8. Sous **OIDC Tests**, sélectionnez **No** pour Just-In Time Provisioning afin d’ignorer ce test, puis définissez **SP Initiate URL** comme étant l’URL de démarrage du login 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 redirigé vers la Universal Login Page d’Auth0, connectez-vous avec votre compte administrateur de l’organisation et acceptez le partage des données.
14. Pour tester SCIM : sélectionnez **Provisioning**, puis **Express Configure SCIM**. Lorsque vous êtes redirigé vers Universal Login d’Auth0, poursuivez jusqu’à l’écran de consentement. Une fois l’opération terminée, l’intégration SCIM est configurée.
15. Ensuite, sélectionnez l’onglet **Assignments** et attribuez un utilisateur de votre organisation Okta Free Integrator pour lequel vous avez l’information d’identification. S’il n’existe pas d’utilisateur approprié, suivez les instructions pour [ajouter des utilisateurs manuellement](https://help.okta.com/en-us/content/topics/users-groups-profiles/usgp-add-users.htm). Si SCIM est activé, l’utilisateur devrait être provisionné dans votre Auth0 tenant. Confirmez-le dans l’Auth0 Dashboard.
16. Pour tester le SSO : utilisez le compte d’utilisateur que vous venez d’attribuer et l’instance de test. Connectez-vous avec l’information d’identification du compte d’utilisateur.
17. Pour tester Universal Logout : suivez les instructions dans [Tester Universal Logout](/docs/fr-ca/authenticate/login/logout/universal-logout#test-universal-logout).
### Finalisez votre soumission
Les tests de base ont été effectués dans la section précédente. Pour finaliser votre soumission, votre configuration doit passer certains 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 effectuer les tests SSO automatisés, sélectionnez **Run test** pour les tests de **flux IdP** et/ou de **flux SP**. Ces tests nécessitent le Okta Browser Plugin. Pour en savoir plus, consultez [Exigences de l’assistant OIN](https://developer.okta.com/docs/guides/submit-app-prereq/main/#oin-wizard-requirements).
* Ouvrez une session avec l’utilisateur de l’Organization d’intégration Okta Free que vous avez attribué à l’instance d’application. Les tests réussissent dès que le plugin détecte que vous pouvez ouvrir une session dans votre application. Pour en savoir plus sur ces tests, consultez [Tester votre intégration](https://developer.okta.com/docs/guides/submit-oin-app/openidconnect/main/#test-your-integration).
* Si vous recevez le message d’erreur `invalid_request (no connections enabled for the client)` pendant le test de login, attendez quelques minutes, puis réessayez. Les connexions nouvellement créées peuvent prendre quelques minutes avant de fonctionner avec des fonctionnalités comme HRD.
4. Pour effectuer les tests Runscope requis pour **SCIM**, suivez les instructions de [Tester votre API SCIM](https://developer.okta.com/docs/guides/submit-oin-app/scim/main/#generate-an-instance-for) à l’aide de [Okta SCIM 2.0 Spec Tests](https://developer.okta.com/standards/SCIM/SCIMFiles/Okta-SCIM-20-SPEC-Test.json).
* Pour un deuxième SCIM token, utilisez la section **Authentication > Enterprise > Okta > \[your-express-configred-connection] > Provisioning > Sync user profiles using SCIM > Setup**.
* Une fois terminé, entrez l’URL partageable du test Runscope dans les champs **Link to Runscope spec test results** et **Link to Runscope CRUD test results** de l’assistant OIN.
5. Une fois terminé, sélectionnez **Submit Integration**.
## Activation client
Lorsque votre application est publiée dans l’OIN, vous pouvez mettre à jour la documentation de votre produit pour indiquer qu’elle prend en charge Express Configuration with Okta. La documentation de votre produit doit préciser quels rôles ou types d’utilisateur ont l’autorisation d’effectuer Express Configuration.
Si votre application utilise déjà les Organisations Auth0 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 à ce rôle les autorisations nécessaires à Express Configuration.
Si vous n’avez pas encore déployé les Organisations Auth0 pour vos clients, ou si vous n’implémentez pas d’utilisateurs administratifs dans votre application, consultez l’exemple de flux d’intégration client.
### Exemple de flux d’activation client
Dans le cadre de votre processus d’onboarding client, vous devriez recueillir :
* Le nom de l’organisation du client
* L’adresse courriel de l’administrateur client qui devrait avoir les permissions nécessaires pour effectuer Express Configuration
* Les domaines de courriel vérifiés que l’IdP du client attribue aux utilisateurs, y compris ceux de l’administrateur
Recueillez ces renseignements manuellement ou au moyen de l’expérience d’inscription ou d’onboarding de 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, par exemple Database ou Email passwordless.
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 à l’utilisateur administrateur un rôle organisationnel avec les permissions nécessaires pour effectuer Express Configuration.
#### Exemple avec Auth0 CLI
**Initialisez Auth0 CLI et authentifiez-vous**
Authentifiez-vous auprès d’Auth0 à l’aide d’[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 Auth0 organisation**
Saisissez le nom de l’organisation et un nom abrégé sans espaces. Si vous avez recueilli plusieurs suffixes de courriel, ajoutez-les comme 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"]'
```
Récupérez le `org_id` renvoyé.
**Créez le compte administrateur de l’Organisation**
Dans cet exemple, vous créez un utilisateur dans une connexion Passwordless par courriel, ce qui requiert une connexion de type [`email`](/docs/fr-ca/authenticate/passwordless/authentication-methods/email-otp). La commande exige que vous saisissiez l’adresse courriel de l’utilisateur que vous autorisez à effectuer Express Configuration.
```bash theme={null}
auth0 api users \
--data '{"email":"user@example.com","connection":"email", "email_verified":true}'
```
Si vous créez cette organisation afin de fournir à l’équipe des opérations Okta OIN un compte de test avec nom d’utilisateur et mot de passe, créez ce compte 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 le `user_id` renvoyé.
**Associez 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 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" };
```
**Ajoutez l’utilisateur admin 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 Express Configuration**
Récupérez l’ID du rôle comportant les autorisations Express Configuration, comme indiqué dans [Attribuer les autorisations Express Configuration 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 `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 cette étape terminée, votre client peut utiliser le compte d’administrateur de l’organisation pour effectuer l’Express Configuration 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 provisionner des comptes Admin
Que vous utilisiez des comptes d’utilisateur existants ou que vous déployiez de nouveaux comptes pour activer Express Configuration, suivez les recommandations ci-dessous.
#### Utiliser une adresse courriel professionnelle
Que le compte Admin non fédéré soit un compte Database, un compte Passwordless Email ou un compte d’utilisateur d’un fournisseur d’identité sociale, il vaut mieux que la valeur de l’attribut `email` corresponde à l’adresse courriel professionnelle de l’utilisateur, celle qui sera provisionnée dans son compte d’utilisateur Okta Enterprise (exemple : `john@mycompany.com`).
Auth0 recommande également de vérifier ces adresses courriel au moyen d’un [flux de vérification de l’adresse 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 l’authentification multifacteur à 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 demander conditionnellement 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 [un 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’exemple d’Action exige [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 **Personnaliser les facteurs MFA à l’aide d’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 suivie dans les [journaux du tenant Auth0](/docs/fr-ca/deploy-monitor/logs) en filtrant selon le **OIN Client ID** de chaque application que vous avez configurée. Cela comprend toute l’activité de connexion des utilisateurs administrateurs, ainsi que toutes les opérations d’API servant à créer et à gérer les connexions Okta Enterprise.
L’OIN Client ID de votre application peut être consulté aux endroits suivants :
* Dans la section **Applications > \[Application] > Okta Integration Network > Create OIN Integration** de l’Auth0 Dashboard.
* Dans la propriété `express_configuration.okta_oin_client_id` de votre application lorsqu’elle est consultée dans l’[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 par Client ID, consultez [Syntaxe des requêtes de recherche de journaux](/docs/fr-ca/deploy-monitor/logs/log-search-query-syntax).
## Limitations
* Un seul tenant Auth0 peut être utilisé dans une même 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 seule connexion Okta unique dans l’organisation Auth0 correspondante. Express Configuration n’est pas prise en charge pour plus d’une instance d’une application OIN dans une organisation Okta.
* Chaque intégration unique répertoriée dans l’OIN crée une connexion Okta distincte. Si vous avez plusieurs applications qui nécessitent une [Identifier-First login experience](https://auth0.com/docs/authenticate/login/auth0-universal-login/identifier-first) avec Home Realm Discovery, nous vous 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 n’affiche que l’application OIN principale dans son [tableau de bord de l’utilisateur final](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 afin d’activer Express Configuration pour une application donnée, consultez les exemples ci-dessous.
### Créer l’API système Okta OIN Express Configuration
Enregistre le serveur de ressources qui sera utilisé pour authentifier les Admins d’organisation. Cela n’est requis que si le dashboard n’a jamais servi à configurer Express Configuration pour des apps 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 de l’endpoint](/docs/fr-ca/api/management/v2/resource-servers/post-resource-servers)
### Créer un User Attribute Profile
Crée un [User Attribute Profile](/docs/fr-ca/authenticate/enterprise-connections/user-attribute-profile). Cette étape n’est requise 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 User Attribute Profile, envoyez d’abord une requête à l’endpoint `GET /api/v2/user-attribute-profiles/templates`, puis utilisez la réponse dans le corps de la requête pour créer le User Attribute Profile.
Exemple :
```curl theme={null}
GET /api/v2/user-attribute-profiles/templates
```
[Référence de l’endpoint](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 Connection Profile
Créez un Connection Profile. Cette étape n'est requise 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 Connection Profile, envoyez une requête à l'endpoint `GET /api/v2/connection-profiles/templates` et utilisez la réponse dans le corps de la requête pour créer le Connection Profile.
Exemple :
```curl theme={null}
GET /api/v2/connection-profiles/templates
```
[Référence de l’endpoint](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 de l’endpoint](https://auth0.com/docs/api/management/v2/connection-profiles/post-connection-profiles)
### Créer un client OIN Express Configuration
Créez l’application de service qu’Okta utilisera pendant Express Configuration pour une application donnée. Ce client doit être créé avec les propriétés indiquées dans l’exemple ci-dessous.
L’attribut `organization_require_behavior` peut être personnalisé avec l’une des valeurs ci-dessous, qui sont également 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` : Demande l’organisation de l’administrateur avant de demander ses informations d’identification.
* `post_login_prompt` : Demande les informations d’identification de l’administrateur. Pour cette option, utilisez le point de terminaison `PATCH /api/v2/connections/{id}` pour ajouter le Client ID 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 de l’endpoint](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 de la propriété `express_configuration` pour l’application enregistrée qui sera publiée sur l’OIN. Remplacez les valeurs des exemples par un ID de Connection Profile valide, un ID de User Attribute Profile valide, un ID d’application cliente OIN, un URI d’initiation de connexion et le domaine du tenant Auth0 à utiliser pour cette intégration.
L’attribut `linked_clients` correspond au paramètre décrit dans [Activer plusieurs applications au sein d’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 de l’organisation](/docs/fr-ca/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration#organization-login-settings).
L’attribut `enable_organization` devrait normalement être défini sur `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’Auth0 Organization. Définir cette valeur sur `false` peut être utile dans le cas décrit dans [Maintenir la correspondance des comptes 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 de l’endpoint](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 d’Okta comme information d’authentification de l’application cliente 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 de l’endpoint](https://auth0.com/docs/api/management/v2/clients/post-credentials)
### Attribuer des clés à l’application cliente OIN
Attribuez au client de service de l’OIN les clés publiques téléversées depuis Okta. Remplacez `yourCredentialId` par l’ID du justificatif 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)
### Personnalisez l’écran de consentement de vos tenants
Mettez à jour les paramètres du tenant pour afficher les détails des scopes sur la page de consentement. Ces paramètres améliorent l’expérience 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 de l’endpoint](https://auth0.com/docs/api/management/v2/tenants/patch-settings)