Gérer Self-Service Enterprise Configuration

Self-Service Enterprise Configuration fournit aux clients interentreprises (B2B) les outils nécessaires pour déléguer la configuration du SSO à leurs clients d’entreprise, et ne requiert qu’une configuration minimale dans votre tenant Auth0 pour leur offrir un assistant libre-service qui les guidera tout au long du processus d’activation. Une fois qu’un client a terminé sa configuration, l’intégration SSO est automatiquement ajoutée à votre tenant en tant que connexion Enterprise.

Les utilisateurs ayant les rôles Dashboard suivants peuvent utiliser cette fonctionnalité :

Les utilisateurs Admin et Editor - Connections peuvent créer et gérer des profils en libre-service.
Les utilisateurs Viewer - Config peuvent uniquement consulter les profils en libre-service.

Pour activer Self-Service Enterprise Configuration, vous configurez les composants suivants à l’aide de la ou de l’ :

Profil en libre-service : définit les principaux éléments des mises en œuvre SSO des clients, y compris les (IdPs) qu’ils peuvent utiliser ainsi que les attributs utilisateur qu’ils doivent recueillir, comme l’adresse courriel. Vous pouvez créer jusqu’à 20 profils dans votre tenant pour différents clients ou segments.
Ticket d’accès en libre-service : accorde aux administrateurs client l’accès à l’assistant en libre-service et définit certains détails de la connexion Enterprise qui en résultera. Les tickets d’accès permettent aux administrateurs client de créer de nouvelles connexions ou de modifier des connexions existantes.

Les sections ci-dessous présentent les étapes détaillées pour configurer des profils en libre-service et générer des tickets d’accès en libre-service à partager avec les administrateurs client.

Créer des profils en libre-service

Vous pouvez créer des profils en libre-service à l’aide de l’Auth0 Dashboard ou de la Management API. Les profils en libre-service servent à définir les principaux éléments des mises en œuvre des clients, notamment :

Les fournisseurs d’identité que les administrateurs clients peuvent utiliser pour le SSO.
Les attributs utilisateur qu’ils doivent recueillir au moyen du SSO, comme l’adresse courriel ou le nom de famille.
Les options d’image de marque qui personnalisent l’apparence de l’assistant libre-service.

Vous pouvez créer jusqu’à 20 profils, au besoin, pour répondre aux besoins de différents clients ou segments.

Auth0 Dashboard
Management API

Pour créer un profil en libre-service dans le Auth0 Dashboard :

Accédez à Authentication > Enterprise et ouvrez la section Self-Service Enterprise Configuration. Ensuite, sélectionnez Create Profile.
Facultatif Joignez un User Attribute Profile.
Si vous créez et joignez un User Attribute Profile, ou en activez un existant, vous n’avez pas l’option d’ajouter des attributs au moyen de l’onglet User Profile.
Sélectionnez un UAP existant ou créez-en un nouveau. Pour un nouvel UAP, ajoutez un nom et vérifiez les mappages pour vous assurer que les attributs du profil sont mappés aux attributs Auth0 de votre choix.
Dans l’espace prévu, saisissez un nom et une description facultative pour le profil. Ensuite, sélectionnez Create.
Dans l’onglet Settings, remplissez les sections ci-dessous. Ensuite, sélectionnez Save.
- Identity Providers (IdP) : Activez un ou plusieurs fournisseurs d’identité. Dans l’assistant en libre-service, les administrateurs clients peuvent sélectionner l’option de leur choix dans la liste des fournisseurs activés.
- Branding : Fournissez un logo et une couleur principale pour l’assistant en libre-service.
- Custom Introduction : Modifiez ou remplacez le message par défaut, au besoin. Ce texte d’introduction s’affiche aux administrateurs clients sur la landing page de l’assistant en libre-service. Votre message peut inclure des options de mise en forme de base, comme le gras ou des hyperliens, et est limité à 2000 caractères.
Dans l’onglet User Profile, ajoutez jusqu’à 20 attributs utilisateur que vos clients doivent recueillir par l’entremise du SSO, comme l’adresse courriel ou le nom de famille. Vous pouvez définir chaque attribut comme required ou optional. Pendant le parcours de l’assistant en libre-service, les administrateurs clients seront invités à mapper ces attributs utilisateur définis à leur fournisseur d’identité afin de s’assurer que les valeurs nécessaires sont transmises à Auth0.

Pour créer un profil en libre-service, effectuez une requête POST vers l’endpoint Self-Service Profiles, en indiquant les paramètres suivants dans le corps de la requête, au besoin :

Paramètre	Obligatoire ?	Description
`name`	Oui	String. Longueur maximale : 100. Un nom convivial pour le profil libre-service.
`description`	Non	String. Longueur maximale de 140. Description du profil libre-service.
`allowed_strategies`	Non	Tableau. Un ou plusieurs fournisseurs d’identité que les administrateurs du client peuvent utiliser pour mettre en place le SSO. Si aucun paramètre n’est sélectionné, tous sont transmis par défaut. Les options comprennent : `okta` pour Okta Workforce Identity `waad`pour Entra ID `google-apps` pour Google Workspace `keycloak-samlp` pour Keycloak `adfs` pour Microsoft Active Directory Federation Services `pingfederate` pour PingFederate `oidc` pour OIDC générique `samlp` pour SAML générique
`branding`	Non	Objet. Permet de personnaliser l’apparence de l’assistant en libre-service destiné aux administrateurs clients.
`branding.logo_url`	Non	String. La longueur maximale est de 1024. Une URL HTTPS menant à une image de logo. Si elle est fournie, le logo s’affiche dans le coin supérieur droit de l’assistant libre-service.
`branding.colors`	Non	Objet. Définit la couleur principale de certains éléments de l’assistant libre-service, comme les boutons interactifs.
`branding.colors.primary`	Oui, si branding.colors est défini.	String. Indique la valeur hexadécimale de la couleur principale utilisée pour l’assistant libre-service.
`user_attributes`	Non	Objet. Longueur maximale : 20. Stocke les informations de mappage présentées aux administrateurs client pendant le flux de l’assistant libre-service. Les administrateurs client doivent mapper ces attributs à leur fournisseur d’identité afin de s’assurer que les attributs indiqués sont transmis à Auth0.
`user_attributes[].name`	Oui, pour définir user_attributes.	String. Longueur maximale : 255. Nom de l’attribut utilisateur dans Auth0.
`user_attributes[].description`	Oui, pour définir les attributs utilisateur.	String. La longueur maximale est de 255. Description de l’attribut utilisateur, en langage clair.
`user_attributes[].is_optional`	Oui, pour définir les attributs utilisateur.	Booléen. Indique si un attribut est facultatif ou requis par le client pour que l’application fonctionne. Pour rendre un attribut obligatoire, utilisez `true`. Pour les attributs facultatifs, utilisez `false`.
`user_attribute_profile_id`	Non.	ID du User Attribute Profile à associer aux comptes libre-service.

Example request body

{
  "name": "Example Profile",
  "description": "An example profile for all customers",
  "allowed_strategies": ["okta","adfs","google-apps"],
  "user_attributes": [
    {
      "name": "email",
      "description": "User's email",
      "is_optional": false,
    }
  ],
  "branding": {
     "logo_url": "https://example.com/logo.png",
     "colors": {
       "primary": "#334455"
     }
  }
}

Lorsqu’un administrateur client accède à l’assistant libre-service, il arrive d’abord sur une page d’introduction qui lui souhaite la bienvenue. Par défaut, le message suivant est fourni :

Vous n’êtes qu’à quelques étapes simples de la configuration du SSO. Ce processus de configuration nécessite d’apporter certaines modifications à votre fournisseur d’identité. Avant de commencer, ouvrez votre fournisseur d’identité dans un onglet ou une fenêtre de navigateur séparés.

Vous pouvez modifier ce texte en effectuant un appel PUT vers le terminal Custom Text for Self-Service Profiles (PUT /api/v2/self-service-profiles/{id}/custom-text/{language}/{page}), où :

id correspond à l’ID du profil libre-service
language est défini sur en
page est défini sur get-started

Dans le corps de la requête, précisez les éléments suivants :

Propriété	Description
`introduction`	String. La longueur maximale est de 2000. Texte d’introduction complet à afficher sur la page d’accueil de l’assistant libre-service. Le texte peut inclure des options de mise en forme de base, comme le gras ou des hyperliens. Le texte personnalisé fourni par ce paramètre remplace entièrement tout message précédent. Pour de meilleurs résultats, assurez-vous de fournir le message complet que vous souhaitez afficher aux administrateurs clients. L’envoi d’un corps vide `\{}` rétablit le texte par défaut et supprime tout message personnalisé.

L’entité créée est renvoyée en réponse.

Cette requête écrase tout message actuellement défini pour le profil libre-service. Assurez-vous que votre requête comprend le texte complet que vous voulez afficher aux administrateurs de vos clients.

Example call

PUT /api/v2/self-service-profiles/ssp_1234567890/custom-text/en/get-started

{
  introduction: "Welcome! With <b>only a few steps</b>, you'll be able to setup your new connection. For assistance, contact <a href="https://www.examplesupportsite.com"> our support team </a>." 
}

Example response

{
  introduction: "Welcome! With <b>only a few steps</b>, you'll be able to setup your new connection. For assistance, contact <a href="https://www.examplesupportsite.com"> our support team </a>." 
}

Gérer les tickets d’accès en libre-service

Après avoir créé au moins un profil en libre-service, vous pouvez générer des tickets d’accès en libre-service dans l’Auth0 Dashboard ou à l’aide de la Management API. Les tickets d’accès en libre-service servent principalement à deux choses :

Donner aux administrateurs clients accès à l’assistant en libre-service, où ils peuvent configurer une nouvelle connexion SSO ou modifier une connexion existante.
Prédéfinir des détails et comportements clés des nouvelles connexions SSO que vos administrateurs clients configureront, par exemple les applications ou organisations qui seront activées pour la nouvelle connexion.

Lorsque vous générez des tickets d’accès, vous pouvez aussi activer certaines fonctionnalités, comme le SSO initié par l’IdP, configurer les domaines du fournisseur d’identité (qui pilotent la Home Realm Discovery) et la vérification de domaine.

SSO SAML initié par l’IdP

Le SSO SAML initié par l’IdP est un mode de mise en œuvre qui permet aux fournisseurs d’identité d’initier le SSO et de rediriger les utilisateurs vers le fournisseur de services pour l’authentification. Lorsque vous activez cette option pour Self-Service Enterprise Configuration, vous devez fournir votre application par défaut et votre protocole de réponse. Vous pouvez aussi fournir une chaîne de requête facultative afin de personnaliser davantage le comportement de la connexion. Pour en savoir plus sur ces options, consultez Configurer l’authentification unique SAML initiée par le fournisseur d’identité.

Vérification du domaine de courriel et domaines prévérifiés

Self-Service Enterprise Configuration prend en charge trois façons d’associer des domaines de courriel à une connexion Enterprise. Ces méthodes remplissent le même champ : options.domain_aliases , qui alimente Home Realm Discovery (HRD) et, selon le cas, Organization Domains for discovery :

Domaines prévérifiés (gérés par le tenant) : l’administrateur de tenant ajoute directement les domaines connus à la connexion.
Domaines à vérifier : l’administrateur de tenant précise les domaines que l’administrateur TI doit vérifier pendant la configuration. Ces domaines sont indiqués comme en attente dans l’organisation et/ou ne sont pas automatiquement associés à la connexion tant que l’administrateur TI n’a pas terminé la vérification.
Vérification du domaine de courriel (autogérée) : l’administrateur de votre client vérifie le domaine pendant la configuration dans l’assistant en libre-service.

Ces mécanismes d’association des domaines de courriel s’appliquent aux domaines de courriel utilisés pour le routage HRD et SSO. Ils ne sont pas liés à la vérification du Custom Domain au niveau du tenant. Pour qu’un domaine soit utilisé à la fois pour Organization Domains for Discovery et pour le HRD, le ticket doit :

Inclure un seul enabled_organization
Avoir soit des domaines prévérifiés, soit Email Verification Required défini sur Required ou Optional
Activer la case à cocher Allow the Use of Domains for Organization Discovery

Domaine prévérifié

Utilisez un domaine prévérifié pour associer des domaines de courriel à une connexion Enterprise à l’échelle du tenant. Les domaines ajoutés sont considérés comme fiables et sont inscrits directement dans options.domain_aliases. Vous pouvez fournir des domaines lorsque vous générez des tickets d’accès en libre-service, soit dans l’Auth0 Dashboard, soit au moyen de la Management API.

Auth0 Dashboard : Sur la page Generate Ticket, indiquez votre liste de domaines dans le champ Pre-verified Domains.
Management API : Définissez connection_config.options.domain_aliases avec la liste des domaines. Par défaut, use_for_organization_discovery est défini sur true. Au besoin, sélectionnez Allow the Use of Domains for Organization Discovery.

Les domaines ajoutés par des administrateurs de tenant sont considérés comme fiables et n’obligent pas l’administrateur client à effectuer la vérification. Si vous voulez plutôt que des administrateurs TI vérifient un domaine au lieu de le traiter comme fiable, définissez domain_aliases_config.domain_verification sur required ou optional afin de demander la vérification dans le assistant en libre-service. L’option Allow Use of Domains for Organization Discovery exige exactement un enabled_organization dans le ticket.

domaines à vérifier

Utilisez les domaines à vérifier pour indiquer les domaines que les administrateurs TI doivent vérifier pendant la configuration. Contrairement aux domaine prévérifié, les domaines en attente ne sont pas automatiquement associés à la connexion ou à l’Organization. Les administrateurs TI doivent terminer la vérification dans l’assistant de configuration avant qu’ils ne prennent effet. Vous pouvez fournir des domaines lors de la génération de tickets d’accès en libre-service au moyen de l’Auth0 Dashboard ou de la Management API :

Auth0 Dashboard : dans la page Generate Ticket, indiquez votre liste de domaines dans le champ domaines à vérifier.
Management API : définissez connection_config.options.domain_aliases sur la liste des domaines. Par défaut, use_for_organization_discovery est défini sur true. Au besoin, sélectionnez Allow the Use of Domains for Organization Discovery

Les limites suivantes s’appliquent :

Si une Organization est associée au ticket, le total combiné des Organization domains existants et en attente ne doit pas dépasser 100.
Si aucune Organization, ou plus d’une Organization, n’est associée au ticket, le total combiné des alias de domaine existants et en attente ne doit pas dépasser 1 000.

Si l’ajout des domaines en attente dépasse l’une ou l’autre de ces limites, la création du ticket échoue avec une erreur.

Vérification du domaine de courriel

Contrairement aux domaines prévérifiés, la vérification du domaine de courriel confirme qu’un administrateur TI est bien propriétaire du domaine qu’il fournit pendant la configuration en libre-service. Une fois la vérification terminée, le domaine vérifié est ajouté au même tableau options.domain_aliases de la connexion. Vous pouvez activer la vérification pour les administrateurs TI lorsque vous générez des tickets d’accès en libre-service :

Auth0 Dashboard : Sur la page Generate Ticket, utilisez le champ Domain Verification Requirement. Au besoin, sélectionnez aussi Allow the Use of Domains for Organization Discovery.
Management API : Utilisez domain_aliases_config.domain_verification et, au besoin, use_for_organization_discovery avec l’une des options suivantes :
- none (par défaut) : l’assistant en libre-service ne demande pas à l’administrateur client de vérifier son domaine.
- required : l’assistant en libre-service demande à l’administrateur client de vérifier ses domaines.
- optional : l’assistant en libre-service demande à l’administrateur client de vérifier son domaine. L’administrateur client peut choisir soit d’entrer son domaine pour le faire vérifier, soit d’ignorer cette étape.

L’option Allow the Use of Domains for Organization Discovery exige exactement une Organization dans le champ Enabled Organizations, et que Domain Verification soit défini sur Optional ou Required, ou qu’un ou plusieurs domaines prévérifiés soient utilisés. Dans certains cas, la vérification peut prendre jusqu’à 48 heures, et vous devrez peut-être émettre un ticket d’accès de suivi pour permettre à l’administrateur client de revenir et d’activer la connexion. Les tickets d’accès expirent cinq heures après leur première ouverture. Consultez Générer des tickets d’accès pour des connexions existantes.

Supprimer un domaine

Les administrateurs TI peuvent supprimer des domaines vérifiés dans l’assistant libre-service. Les règles suivantes s’appliquent selon le paramètre Domain Verification Requirement défini sur le ticket :

Facultatif : tous les domaines vérifiés peuvent être supprimés.
Obligatoire : au moins un domaine vérifié doit être conservé. Un avertissement s’affiche si l’administrateur TI tente de supprimer le dernier domaine vérifié.

Générer des tickets d’accès pour de nouvelles connexions

Vous pouvez générer des tickets d’accès pour de nouvelles connexions dans l’Auth0 Dashboard ou au moyen de la Management API.

Par défaut, les URL de ticket d’accès restent valides pendant cinq jours après leur génération. Après avoir accédé à l’URL du ticket, l’administrateur client dispose de cinq heures pour terminer la configuration. Une URL de ticket d’accès peut être consultée au maximum 10 fois ; une fois cette limite atteinte, un nouveau ticket d’accès doit être demandé.Au besoin, vous pouvez révoquer un ticket d’accès avant son expiration afin de mettre immédiatement fin à l’accès à l’assistant en libre-service.

Auth0 Dashboard
Management API

Pour générer un ticket d’accès pour une nouvelle connexion à partir de l’Auth0 Dashboard :

Accédez à Authentication > Enterprise et ouvrez la section Self-Service Enterprise Configuration. Ensuite, sélectionnez le profil en libre-service avec lequel vous voulez créer un ticket d’accès.
Sélectionnez Generate Ticket pour ouvrir le formulaire de ticket. Sous Select ticket type, choisissez Create a new connection.
Sous Ticket configuration, indiquez le nom requis de la connexion que l’administrateur du client configurera.
Dans la section Settings, configurez au besoin des options supplémentaires pour la nouvelle connexion :
- Domain : Sélectionnez le domaine personnalisé à utiliser dans l’URL du ticket. Disponible uniquement lorsque plusieurs domaines personnalisés sont présents.
- Display Name : Un nom convivial pour la connexion, qui s’affichera dans les invites de Universal Login.
- Enabled Clients : Une liste d’ID de clients séparés par des virgules à associer à la connexion.
- Enabled Organizations : Une liste d’ID d’organisations séparés par des virgules à associer à la connexion.
- Display connection a as button : Affiche la connexion comme option d’authentification sur l’écran de connexion.
- Display connection as a button for organizations : Affiche la connexion comme option d’authentification sur l’écran de connexion pour les organisations indiquées.
- Assign membership on login for organizations : Attribue automatiquement l’appartenance à l’organisation aux utilisateurs qui s’authentifient avec la connexion.
- Enable as a domain level connection : Permet aux applications tierces d’utiliser la connexion; utile pour les scénarios utilisant des applications créées au moyen du Client ID Metadata Document (CIMD) et de Dynamic Client Registration.
- Allow IT admin to configure third-party application access : Lorsqu’elle est activée, l’administrateur TI voit une option dans l’assistant de configuration pour permettre aux applications tierces d’utiliser la connexion. Si vous souhaitez définir cette valeur vous-même plutôt que de la déléguer, utilisez plutôt la bascule Enable as Domain Level Connection. Ces deux options s’excluent mutuellement.
- Accept SAML IdP-initiated SSO : Active le SSO initié par le fournisseur d’identité SAML.
Sous Domain-Based Discovery, fournissez au besoin une liste de domaines d’IdP déjà vérifiés ou à vérifier, séparés par des virgules, à comparer aux domaines de courriel des utilisateurs. Ces domaines sont stockés dans options.domain_aliases et pilotent le HRD. Pour en savoir plus, consultez Home Realm Discovery.
Sous Domain Verification Requirement, choisissez le niveau de vérification souhaité :
- Off : Les administrateurs du client ne sont pas invités à vérifier leur domaine lors de la configuration du SSO. Off est le paramètre par défaut pour les nouveaux tickets d’accès.
- Optional : Les administrateurs du client sont invités à vérifier leur domaine lors de la configuration du SSO. Toutefois, ils peuvent sauter cette étape et activer leur connexion sans terminer la vérification.
- Required : Les administrateurs du client doivent vérifier leur domaine lors de la configuration du SSO. Ils ne pourront pas activer leur connexion tant que la vérification ne sera pas terminée.
Vous pouvez aussi activer Allow IT admin to configure Cross App Access - Resource Application. Lorsque cette option est activée, l’administrateur TI voit une option dans l’assistant de configuration pour configurer la connexion comme application de ressources Cross App Access (XAA). C’est utile lorsque l’administrateur TI souhaite autoriser l’accès depuis des applications connectées directement dans son IdP d’entreprise en amont.
Sous Provisioning, activez au besoin Sync Users and Groups through Provisioning. Lorsque cette option est activée, des paramètres supplémentaires sont offerts :
- Bearer Token Expiration : Définissez une date d’expiration pour le bearer token SCIM. Par défaut, les bearer tokens n’expirent pas.
- Bearer Token Permissions (Scopes) : Choisissez les actions que le token peut effectuer. Par défaut, tous les scopes de provisioning sont activés :
  - get:users
  - post:users
  - put:users
  - patch:users
  - delete:users
  - get:groups
  - post:groups
  - put:groups
  - patch:groups
  - delete:groups
- Si le profil en libre-service autorise Google Workspace comme identity provider, une section Google Workspace Directory Sync Settings s’affiche également. Pour permettre à l’administrateur client de synchroniser les groups de son directory Google Workspace, sélectionnez Enable Google Workspace group sync. La synchronisation des groups exige que la synchronisation des utilisateurs soit aussi activée. Auth0 synchronise automatiquement le directory toutes les 30 minutes.
L’expiration du token et les scopes SCIM ne s’appliquent pas à la synchronisation de répertoire Google Workspace.
Sous Time to Live, définissez une période d’expiration pour le ticket d’accès en secondes. Par défaut, la durée de vie est de 432000 secondes (soit cinq jours).
- Time to Live détermine pendant combien de temps une URL de ticket d’accès reste active avant qu’un administrateur du client lance l’assistant en libre-service. Cela ne détermine pas combien de temps l’administrateur du client a accès à l’assistant après son lancement. L’expiration de l’assistant en libre-service lui-même est de 5 heures et ne peut pas être configurée.
Sous Metadata, ajoutez jusqu’à 10 éléments de métadonnées associés à la connexion.
Vérifiez l’exactitude de la configuration de votre ticket d’accès. Ensuite, sélectionnez Create Ticket.

Une fenêtre contextuelle « Informations sur le ticket » contenant l’URL du ticket d’accès s’affiche ensuite. Copiez et enregistrez cette URL dans un endroit sûr, car vous ne pourrez pas la récupérer après la fermeture de la fenêtre.Vous pouvez partager l’URL du ticket d’accès avec l’administrateur de votre client par courriel, clavardage ou tout autre canal de communication pour lui donner accès à l’assistant en libre-service. L’assistant le guide dans la configuration de la connexion SSO. Pour en savoir plus sur cette expérience, consultez Self-service assistant experience.

Pour générer un ticket d’accès via la Management API.

Récupérez l’ID du profil libre-service que vous souhaitez associer au ticket d’accès à l’aide du terminal Retrieve Self-Service Profiles.
Appelez le terminal SSO Access Ticket à l’aide de l’ID du profil libre-service approprié : POST /api/v2/self-service-profiles/{id}/sso-ticket

Utilisez l’en-tête auth0-custom-domain pour définir le domaine personnalisé à utiliser dans l’URL du ticket. Cette option est offerte uniquement lorsque la fonctionnalité Multiple Custom Domains est activée.

Dans le corps de la requête, indiquez les paramètres décrits dans le tableau ci-dessous.

Paramètre	Description
`connection_config`	Objet. Obligatoire lors de la génération d’un ticket d’accès pour une nouvelle connexion SSO. Les administrateurs du client pourront modifier certains éléments clés de la connexion, comme le certificat SAML ou l’ID ou le secret OIDC.
`connection_config.name`	Obligatoire. String. Nom de la connexion créée à l’aide de l’assistant de configuration SSO. Longueur maximale de 128 caractères.
`connection_config.display_name`	Facultatif. String. Nom d’affichage de la nouvelle connexion créée à l’aide de l’assistant libre-service. Ce nom s’affiche dans les écrans Universal Login. La longueur maximale est de 128.
`connection_config.is_domain_connection`	Facultatif. Booléen. Définissez cette valeur sur `true` si la connexion est au niveau du domaine ; Dynamic Client Registration est requis.
`connection_config.show_as_button`	Optionnel. Booléen. Lorsque `true`, la connexion s’affiche à l’écran de connexion de votre application comme option d’authentification.
`connection_config.metadata`	Facultatif. Object[]. Métadonnées associées à la nouvelle connexion. L’objet peut contenir jusqu’à 10 paires clé-valeur. Les valeurs de type String sont limitées à 255 caractères.
`connection_config.options`	Facultatif. Objet[]. Options de la nouvelle connexion, notamment : `icon_url` `domain_aliases[]` `idpinitiated`
`connection_config.options.icon_url`	Facultatif. String. URL de l’image d’icône à utiliser si `connection_config.show_as_button` est activé. L’URL doit utiliser HTTPS.
`connection_config.options.domain_aliases`	Facultatif. String[]. Domaines à utiliser pour le Home Realm Discovery. Les domaines saisis dans `domain_aliases` sont automatiquement marqués comme vérifiés. Pour qu’un administrateur client vérifie lui-même un domaine, ne précisez pas cet attribut et utilisez plutôt `domain_aliases_config` (décrit plus loin dans cette table). Cette option vous permet de demander à l’administrateur client de vérifier son domaine au moyen du self-service assistant.
`connection_config.options.idpinitiated`	Facultatif. Objet. Permet le SSO initié par l’IdP SAML et inclut les attributs suivants : `enabled` `client_id` `client_protocol` `client_authorizequery` Pour en savoir plus, consultez le point de terminaison ticket d’accès SSO dans le Management API Explorer.
`domain_aliases_config`	Facultatif. Objet. Contient les propriétés `domain_verification` et `pending_domains` pour configurer la vérification de domaine.
`domain_aliases_config.domain_verification`	Facultatif. String. Détermine si la vérification du domaine est requise, facultative ou désactivée. Les options sont les suivantes : `none` : Désactive la vérification du domaine. Vous pouvez aussi désactiver la vérification du domaine en omettant l’objet `domain_aliases_config` de votre requête. `optional` : Permet aux administrateurs du client d’ignorer la vérification du domaine lors de la configuration. `required` : Exige que les administrateurs du client vérifient leur domaine lors de la configuration.
`domain_aliases_config.pending_domains`	Facultatif. String[]. Domaines que l’admin TI doit vérifier pendant la configuration. Contrairement aux domaines pré-vérifiés, ces domaines sont affichés comme en attente dans l’organisation et ne sont pas automatiquement associés à la connexion — l’admin TI doit terminer la vérification dans l’assistant libre-service avant qu’ils soient pris en compte. `domain_aliases_config.domain_verification` doit être défini sur `optional` ou `required` pour utiliser ce paramètre. Les quotas suivants s’appliquent : Si une organisation est associée au ticket, le nombre total combiné de domaines d’organisation existants et en attente ne doit pas dépasser 100. Si aucune organisation ou plus d’une organisation est associée au ticket, le nombre total combiné d’alias de domaine existants et en attente ne doit pas dépasser 1 000.
`enabled_organizations`	Facultatif. Objet[]. Liste des organisations à associer à la nouvelle connexion.
`enabled_organizations[].organization_id`	Obligatoire lors de l’utilisation de `enabled_organizations`. String. ID d’une organization précise à associer à la nouvelle connexion. Vous pouvez récupérer les ID dans la section Organizations du Auth0 Dashboard, au point de terminaison Get Organizations, ou au point de terminaison Get Organization by Name.
`enabled_organizations[].assign_membership_on_login`	Facultatif. Booléen. Lorsque `true`, les utilisateurs qui se connectent avec la nouvelle connexion obtiennent automatiquement l’adhésion à l’organisation indiquée.
`enabled_organizations[].show_as_button`	Facultatif. Booléen. Lorsque `true`, la nouvelle connexion s’affiche comme option d’authentification sur l’écran de connexion de l’organisation pour votre application.
`provisioning_config`	Facultatif. Objet. Détermine si l’administrateur client peut configurer le provisionnement pendant le flow libre-service. Au moins un des paramètres `provisioning_config.scopes` ou `provisioning_config.google_workspace` doit être fourni lorsque cet objet est inclus.
`provisioning_config.scopes`	Facultatif. String[]. Permissions du bearer token SCIM. Portées offertes : `get:users`, `post:users`, `put:users`, `patch:users`, `delete:users`, `get:groups`, `post:groups`, `put:groups`, `patch:groups`, `delete:groups`. Si la connexion est créée sans toutes les portées de provisionnement des utilisateurs, SCIM ne sera pas activé. Les portées de groupe sont facultatives.
`provisioning_config.token_lifetime`	Facultatif. Nombre. Durée de vie du bearer token SCIM en secondes. Si aucune valeur n’est précisée, le token n’expire pas.
`provisioning_config.google_workspace`	Facultatif. Objet. Configuration de la synchronisation du répertoire Google Workspace. Valide uniquement lorsque le profil libre-service inclut Google Workspace (`google-apps`) comme identity provider autorisé. Pour en savoir plus, consultez Google Workspace Directory Sync.
`provisioning_config.google_workspace.sync_users`	Facultatif. Booléen. Lorsque `true`, l’administrateur client peut synchroniser les utilisateurs de son répertoire Google Workspace vers Auth0 dans le cadre du flow libre-service. Auth0 synchronise automatiquement le répertoire toutes les 30 minutes.
`provisioning_config.google_workspace.sync_groups`	Facultatif. Booléen. Lorsque `true`, l’administrateur client peut synchroniser les groupes de son répertoire Google Workspace avec Auth0 pendant le flux libre-service. Nécessite également que `provisioning_config.google_workspace.sync_users` soit défini sur `true`.
`ttl_sec`	Facultatif. Nombre. Nombre de secondes pendant lesquelles une URL de ticket d’accès reste active avant qu’un administrateur client lance l’assistant libre-service. Si aucune valeur n’est précisée ou si la valeur est définie à 0, la valeur par défaut est `432000` (maximum de 5 jours). Notez que cette période d’expiration ne détermine pas combien de temps un administrateur client a accès au libre-service après l’avoir lancé. L’assistant lui-même expire après 5 heures et cette durée ne peut pas être configurée.
`use_for_organization_discovery`	Facultatif. Booléen. Indique si un domaine vérifié doit servir à la découverte de l’organisation lors de l’authentification.
`third_party_client_access_config`	Facultatif. Objet. Détermine si l’admin TI peut configurer l’accès des applications tierces à la connexion dans l’assistant de configuration libre-service. Lorsqu’il est présent, l’assistant permet à l’admin TI d’activer la connexion pour que des applications tierces puissent l’utiliser. Ne peut pas être utilisé avec `connection_config.is_domain_connection: true`. Si les deux sont fournis, la requête est rejetée avec une erreur `400`. Lorsqu’il est omis, l’étape d’accès des applications tierces n’apparaît pas dans l’assistant.
`third_party_client_access_config.allow_configuration`	Obligatoire lorsque `third_party_client_access_config` est fourni. Booléen. Lorsque `true`, l’admin TI voit une étape dans l’assistant libre-service où il peut choisir d’autoriser les applications tierces à utiliser la connexion (`is_domain_connection`). Lorsque `false`, l’option n’est pas affichée et l’admin TI ne peut pas configurer ce paramètre.

Configuration supplémentaire requise lors de l’utilisation d’OrganizationsSi la connexion est associée à une organisation et que vous souhaitez permettre à des applications tierces d’authentifier des utilisateurs par l’intermédiaire de cette organisation, vous devez définir séparément le champ third_party_client_access de l’organisation sur allow. Cette étape n’est pas effectuée dans l’assistant libre-service : elle doit être réalisée par l’administrateur de tenant.Pour mettre à jour le paramètre d’accès des applications tierces d’une organisation, accédez au tableau de bord de l’organisation (Organization Dashboard) ou appelez la méthode Update an Organization et définissez third_party_client_access sur allow.

Example request body

{
   "connection_config":{
      "name":"string",
      "display_name":"string",
      "show_as_button":true,
      "metadata":{
         "key1":"value1",
         "key2":"value2"
      },
      "options":{
         "icon_url":"string",
         "domain_aliases":[
            "acme.corp",
            "okta.com"
         ],
         "idpinitiated": { 
            "enabled": true, 
            "client_id": "string", 
            "client_protocol": "string", 
            "client_authorizequery": "string" 
        }
      }
   },
   "enabled_organizations":[
      {
         "organization_id":"string",
         "assign_membership_on_login":true,
         "show_as_button":true
      }
   ],
   "ttl_sec":0,
   "domain_aliases_config": {
       "domain_verification": "string",
       "pending_domains": [
              "acme2.com"
       ]
    },
   "third_party_client_access_config": {
      "allow_configuration": true
   }
},

En réponse, vous recevez une URL vers le ticket d’accès en libre-service :

Example response

{
  "ticket": "https://{domain}/self-service/connections-flow?ticket={id}"
}

Après avoir reçu l’URL du ticket, partagez le lien avec l’administrateur client pour lui donner accès à l’assistant en libre-service. L’assistant le guide dans la configuration de la connexion SSO. Pour en savoir plus sur cette expérience, consultez Expérience de l’assistant en libre-service.Vous pouvez intégrer la génération de tickets d’accès dans votre propre portail libre-service ou envoyer les URL de tickets directement aux administrateurs de vos clients par courriel, clavardage ou d’autres canaux de communication.

Générer des tickets d’accès pour les connexions existantes

Vous pouvez générer des tickets d’accès pour les connexions existantes à partir de l’Auth0 Dashboard ou de la Management API.

Par défaut, les URL de tickets d’accès demeurent valides pendant cinq jours après leur génération. Une fois l’URL du ticket consultée, l’administrateur client dispose de cinq heures pour terminer la configuration. Une URL de ticket d’accès peut être consultée au maximum 10 fois; une fois cette limite atteinte, un nouveau ticket d’accès doit être demandé.Au besoin, vous pouvez révoquer un ticket d’accès avant son expiration afin de retirer immédiatement l’accès à l’assistant en libre-service.

Si un administrateur client lance la vérification du domaine à partir de l’assistant en libre-service, il pourrait avoir besoin d’un ticket d’accès supplémentaire pour terminer le processus de configuration.La vérification du domaine constitue la dernière étape de l’assistant en libre-service. À cette étape du processus, la connexion a été créée, mais elle n’est pas encore activée. Si la vérification du domaine est requise, l’administrateur client ne peut pas activer sa connexion tant que la vérification n’est pas terminée.Bien que la vérification se fasse généralement rapidement, elle peut prendre de 24 à 48 heures dans certains cas. Si cela se produit, l’administrateur client ne pourra pas utiliser son ticket d’accès initial pour activer sa connexion, puisque les tickets expirent cinq heures après leur première consultation.Pour terminer ce processus, vous pouvez générer un ticket d’accès qui permet à l’administrateur client de modifier la connexion qu’il a configurée avec son ticket initial. Lors de la création de ce ticket, assurez-vous d’indiquer l’ID de la connexion qu’il a configurée avec son premier ticket d’accès.

Auth0 Dashboard
Management API

Pour modifier un ticket d’accès dans l’Auth0 Dashboard :

Accédez à Authentication > Enterprise, puis ouvrez la section Self-Service Enterprise Configuration. Ensuite, sélectionnez le profil de libre-service avec lequel vous voulez créer un ticket d’accès.
Sélectionnez Generate Ticket pour ouvrir le formulaire de ticket. Sous Select ticket type, choisissez Edit an existing connection.
Sous Ticket configuration, indiquez l’ID de la connexion existante que vous voulez permettre à l’admin client de modifier.
Sélectionnez Next.
Sous Enabled features, choisissez les flux auxquels l’admin TI peut accéder. Toutes les options sont activées par défaut.
- Edit SSO connection : permet à l’admin TI de modifier la connexion SSO. Désactivez cette option pour donner à l’admin TI un accès uniquement au provisionnement ou à la configuration du domaine, sans lui permettre de modifier la connexion.
- Provisioning : permet à l’admin TI de configurer le provisionnement.
- Domain configuration : permet à l’admin TI de vérifier ou de gérer les domaines.
Sous Domain Verification, choisissez le niveau de vérification souhaité :
- Off : les admins clients ne sont pas invités à vérifier leur domaine lors de la configuration du SSO. Cette option est sélectionnée par défaut pour les nouveaux tickets d’accès.
- Optional : les admins clients sont invités à vérifier leur domaine lors de la configuration du SSO. Toutefois, ils peuvent passer cette étape et activer leur connexion sans terminer la vérification.
- Required : les admins clients doivent vérifier leur domaine lors de la configuration du SSO. Ils ne pourront pas activer leur connexion tant que la vérification ne sera pas terminée.
Au besoin, activez Allow IT admin to configure Cross App Access - Resource Application. Lorsque cette option est activée, l’admin TI voit apparaître dans l’assistant de configuration une option lui permettant de configurer la connexion comme Resource Application Cross App Access (XAA). C’est utile lorsque l’admin TI souhaite autoriser l’accès depuis les applications connectées directement dans son IdP d’entreprise en amont.
Sous Provisioning, activez au besoin Sync users and group profiles using provisioning. Lorsque cette option est activée, des paramètres supplémentaires sont offerts :
- Bearer Token Expiration : définissez une date d’expiration pour le jeton porteur SCIM. Par défaut, les jetons porteurs n’expirent pas.
- Bearer Token Permissions (Scopes) : choisissez les actions que le jeton peut effectuer. Par défaut, tous les scopes de provisionnement sont activés :
  - get:users
  - post:users
  - put:users
  - patch:users
  - delete:users
  - get:groups
  - post:groups
  - put:groups
  - patch:groups
  - delete:groups
Sous Time to Live, définissez une période d’expiration pour le ticket d’accès, en secondes. Par défaut, la durée de vie est définie à 432000 secondes (ce qui équivaut à cinq jours). A. La durée de vie détermine combien de temps une URL de ticket d’accès reste active avant qu’un admin client lance l’assistant en libre-service. Elle ne détermine pas combien de temps l’admin client a accès à l’assistant après son lancement. L’expiration de l’assistant en libre-service lui-même est de cinq heures et ne peut pas être configurée.
Vérifiez l’exactitude de la configuration de votre ticket d’accès. Ensuite, sélectionnez Create Ticket.

Une fenêtre contextuelle Ticket Information contenant l’URL du ticket d’accès s’affiche ensuite. Copiez et enregistrez cette URL dans un endroit sûr, car vous ne pourrez plus la récupérer après avoir fermé la fenêtre contextuelle.Vous pouvez transmettre l’URL du ticket d’accès à votre admin client par courriel, dans un chat ou par un autre canal de communication afin de lui accorder l’accès à l’assistant en libre-service. L’assistant le guide dans la configuration de la connexion SSO. Pour en savoir plus sur cette expérience, consultez Self-service assistant experience.

Pour générer un ticket d’accès via la Management API, suivez les étapes ci-dessous.

Vous ne pouvez pas mettre à jour les détails de connection_config d’une connection existante au moyen du endpoint SSO Access Ticket. Si vous devez modifier ces renseignements pour une connection existante, utilisez plutôt le endpoint Update a Connection.

Récupérez l’ID du profil libre-service que vous souhaitez associer au ticket d’accès à partir du point de terminaison Retrieve Self-Service Profiles.
Appelez le point de terminaison SSO Access Ticket en utilisant l’ID du profil libre-service approprié : POST /api/v2/self-service-profiles/{id}/sso-ticket Dans le corps de la requête, indiquez les paramètres suivants :

Paramètre	Description
`connection_id`	Obligatoire. String. ID de la connexion qu’un administrateur client peut mettre à jour à l’aide de l’assistant libre-service. Les administrateurs clients peuvent modifier des éléments clés de la connexion, comme le certificat SAML ou l’ID et le secret OIDC. Les IDs de connexion peuvent être récupérés dans la section Authentication de l’Auth0 Dashboard ou à partir du endpoint Get All Connections.**
`domain_aliases_config.pending_domains`	Facultatif. String[]. Domaines à vérifier par l’administrateur TI pendant la configuration. Ces domaines sont indiqués comme étant en attente dans l’organisation et ne sont pas automatiquement associés à la connexion — l’administrateur TI doit terminer la vérification dans l’assistant libre-service avant qu’ils entrent en vigueur. `domain_aliases_config.domain_verification` doit être défini sur `optional` ou `required` pour utiliser ce paramètre. Des quotas s’appliquent : Si une organisation est associée au ticket, le total combiné des domaines d’organisation existants et en attente ne doit pas dépasser 100. Si aucune organisation ou plus d’une organisation n’est associée au ticket, le total combiné des alias de domaine existants et en attente ne doit pas dépasser 1 000.
`enabled_features`	Facultatif. Objet. Contrôle les flux auxquels l’administrateur TI peut accéder. Pris en charge uniquement pour les tickets de modification de connexion. S’il est omis, les fonctionnalités actives sont déterminées en fonction de la présence d’autres propriétés de configuration dans la requête (le comportement existant est préservé). S’il est inclus, l’objet doit contenir au moins une propriété qui n’est pas explicitement définie à `false` par défaut, et il ne peut pas être null ni vide. Si `enabled_features.provisioning` est `true`, `provisioning_config` est requis dans le corps de la requête.
`enabled_features.sso`	Facultatif. Booléen. Lorsque la valeur est `true`, l’administrateur TI peut modifier la connexion SSO. Réglez-la à `false` pour autoriser l’accès uniquement aux flux de provisioning ou de vérification de domaine, sans pouvoir modifier la connexion.
`enabled_features.provisioning`	Facultatif. Booléen. Si la valeur est `true`, l’administrateur TI peut configurer le provisionnement. Nécessite `provisioning_config` dans le corps de la requête.
`enabled_features.domain_verification`	Facultatif. Booléen. Si la valeur est `true`, l’administrateur TI peut vérifier ou gérer des domaines.
`provisioning_config`	Facultatif. Objet. Détermine si l’administrateur du client peut configurer le provisionnement pendant le flux en libre-service. Au moins l’un des paramètres `provisioning_config.scopes` ou `provisioning_config.google_workspace` doit être fourni lorsque cet objet est inclus.
`provisioning_config.scopes`	Facultatif. String[]. Permissions du jeton porteur SCIM. Portées offertes : `get:users`, `post:users`, `put:users`, `patch:users`, `delete:users`, `get:groups`, `post:groups`, `put:groups`, `patch:groups`, `delete:groups`. Si la connexion est créée sans toutes les portées de provisionnement des utilisateurs, SCIM ne sera pas activé. Les portées des groupes sont facultatives.
`provisioning_config.token_lifetime`	Facultatif. Nombre. Durée de vie du jeton porteur SCIM, en secondes. Si aucune valeur n’est indiquée, le jeton n’expire pas.
`provisioning_config.google_workspace`	Facultatif. Objet. Configuration de la synchronisation du directory Google Workspace. Valide uniquement lorsque le profil libre-service inclut Google Workspace (`google-apps`) comme identity provider autorisé. Pour en savoir plus, consultez Google Workspace Directory Sync.
`provisioning_config.google_workspace.sync_users`	Facultatif. Booléen. Lorsque la valeur est `true`, l’administrateur client peut synchroniser les utilisateurs de son répertoire Google Workspace vers Auth0 pendant le flux libre-service. Auth0 synchronise automatiquement le répertoire toutes les 30 minutes.
`provisioning_config.google_workspace.sync_groups`	Facultatif. Booléen. Lorsque la valeur est `true`, l’administrateur du client peut synchroniser les groupes de son répertoire Google Workspace vers Auth0 pendant le flux en libre-service. Exige que `provisioning_config.google_workspace.sync_users` soit aussi défini à `true`.
`ttl_sec`	Facultatif. Nombre. Nombre de secondes pendant lesquelles l’URL d’un ticket d’accès reste active avant qu’un administrateur du client lance l’assistant en libre-service. Si aucune valeur n’est indiquée ou si la valeur est définie à `0`, la valeur par défaut est `432000` (ce qui équivaut à 5 jours). Notez que cette période d’expiration ne détermine pas combien de temps un administrateur du client a accès à l’assistant en libre-service après son lancement. La période d’expiration de l’assistant lui-même est de cinq heures et ne peut pas être configurée.
`domain_aliases_config`	Facultatif. Objet. Contient `domain_verification`, qui permet de déterminer si la vérification de domaine est requise, facultative ou désactivée. Les options de `domain_verification` sont les suivantes : `none` : Désactive la vérification de domaine. Vous pouvez aussi désactiver la vérification de domaine en omettant l’objet `domain_aliases_config` de votre requête. `optional` : Permet aux administrateurs clients de passer outre la vérification de domaine pendant la configuration. `required` : Exige que les administrateurs clients vérifient leur domaine pendant la configuration.
`use_for_organization_discovery`	Facultatif. Booléen. Indique si un domaine vérifié doit être utilisé pour la découverte de l’organisation lors de l’authentification.

Example request body

{
  "connection_id": "string",
   "ttl_sec":0,
   "domain_aliases_config": {
       "domain_verification": "string",
       "pending_domains": [
             "acme.com"
          ]
    }
}

En réponse, vous recevez une URL vers le ticket d’accès en libre-service :

Example response

{
  "ticket": "https://{domain}/self-service/connections-flow?ticket={id}"
}

Une fois que vous avez reçu l’URL du ticket, partagez le lien avec l’administrateur de votre client pour lui accorder l’accès à l’assistant en libre-service. L’assistant les guide dans la configuration de la connexion SSO. Pour en savoir plus sur cette expérience, consultez Expérience de l’assistant en libre-service.Vous pouvez intégrer la génération de tickets d’accès dans votre propre portail libre-service ou envoyer les URL de tickets directement aux administrateurs de vos clients par courriel, chat ou tout autre canal de communication.

Révoquer un ticket d’accès

Par défaut, l’URL d’un ticket d’accès reste valide pendant cinq jours. Après avoir accédé à l’URL, un administrateur client dispose de cinq heures pour terminer la configuration. Au besoin, vous pouvez révoquer un ticket d’accès avant son expiration. Par exemple, si un ticket d’accès est partagé avec le mauvais , vous pouvez révoquer le ticket pour empêcher tout accès non autorisé à l’assistant en libre-service. Lorsque vous révoquez un ticket d’accès, son URL devient immédiatement invalide et toutes les sessions associées sont interrompues. Les administrateurs clients qui disposent de l’URL ne pourront plus accéder à l’assistant en libre-service. Vous pourrez ensuite générer et partager de nouveaux tickets d’accès au besoin. Pour révoquer un ticket d’accès :

Récupérez l’ID du profil en libre-service associé au ticket d’accès à l’aide du point de terminaison Récupérer les profils libre-service.
Repérez l’ID du ticket d’accès que vous souhaitez révoquer. Les ID se trouvent à la fin de l’URL du ticket d’accès.
Envoyez une requête au point de terminaison Révoquer un ticket d’accès SSO en utilisant les ID appropriés : POST /api/v2/self-service-profiles/{id}/sso-ticket/{id}/revoke

En réponse, le point de terminaison renvoie un code 202 Accepted.

Références

API

Pour gérer la Self-Service Enterprise Configuration, les points de terminaison suivants de la Management API sont disponibles :

Limites de débit

Lorsque vous utilisez Self-Service Enterprise Configuration, les limites de débit suivantes s’appliquent :

Description	Point de terminaison	Limites
Gérer les profils SSO	`/api/v2/self-service-profiles`	Consultez les limites de débit de la Management API pour votre type d’abonnement.
Créer un ticket d’accès	`/api/v2/self-service-profiles/{id}/sso-ticket`	Consultez les limites de débit de la Management API pour votre type d’abonnement.
Utiliser un ticket d’accès	`/self-service/connection-flows?ticket={id}`	6 / min / IP
Charger l’application web (y compris l’assistant de configuration) et les points de terminaison de l’application web	`/self-service/*`	50 / min / IP 90 / min / tenant

Quickstarts

Auth0 Overview

Configure Auth0

Applications

Gérer Self-Service Enterprise Configuration

Créer des profils en libre-service

Gérer les tickets d’accès en libre-service

SSO SAML initié par l’IdP

Vérification du domaine de courriel et domaines prévérifiés

Domaine prévérifié

domaines à vérifier

Vérification du domaine de courriel

Supprimer un domaine

Générer des tickets d’accès pour de nouvelles connexions

Générer des tickets d’accès pour les connexions existantes

Révoquer un ticket d’accès

Références

API

Limites de débit

​Créer des profils en libre-service

​Gérer les tickets d’accès en libre-service

​SSO SAML initié par l’IdP

​Vérification du domaine de courriel et domaines prévérifiés

​Domaine prévérifié

​domaines à vérifier

​Vérification du domaine de courriel

​Supprimer un domaine

​Générer des tickets d’accès pour de nouvelles connexions

​Générer des tickets d’accès pour les connexions existantes

​Révoquer un ticket d’accès

​Références

​API

​Limites de débit

Créer des profils en libre-service

Gérer les tickets d’accès en libre-service

SSO SAML initié par l’IdP

Vérification du domaine de courriel et domaines prévérifiés

Domaine prévérifié

domaines à vérifier

Vérification du domaine de courriel

Supprimer un domaine

Générer des tickets d’accès pour de nouvelles connexions

Générer des tickets d’accès pour les connexions existantes

Révoquer un ticket d’accès

Références

API

Limites de débit