> ## 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. # Référence de l’API My Organization > Documentation de l’API My Organization d’Auth0 Version : 1.0 (actuelle)

Early Access

L’API My Organization et les Embeddable UI Components sont actuellement offerts en Early Access à tous les clients. En utilisant cette fonctionnalité, vous acceptez les conditions applicables de l’essai gratuit énoncées dans le [Master Subscription Agreement d’Okta](https://www.okta.com/legal/). Pour en savoir plus sur le cycle de lancement des produits d’Auth0, consultez [Product Release Stages](/docs/fr-ca/troubleshoot/product-lifecycle/product-release-stages). Le client est responsable de s’assurer que son utilisation de l’API My Organization et des Embeddable UI Components respecte ses politiques de sécurité et les lois applicables, y compris toute permission accordée à ses utilisateurs finaux. L’API My Organization d’Auth0 fournit une interface sécurisée, propre à l’organisation, qui permet à vos clients commerciaux de gérer leurs propres Organizations dans votre tenant Auth0. Cette API sert de fondement technique à l’administration déléguée intégrée et aux intégrations API-first. La documentation de l’API My Organization suit le [schéma OpenAPI v3.1 de l’API My Organization](https://auth0.com/docs/oas/myorganization/myorganization-api-oas.json). Veuillez noter que la prise en charge du schéma OpenAPI v3.1 est actuellement en Beta.

Utiliser le domaine Auth0 ou un domaine personnalisé

L’API My Organization prend en charge l’utilisation de votre domaine Auth0 canonique ou de votre domaine personnalisé, mais vous devez utiliser le même tout au long du processus, notamment pour : * Obtenir un jeton d’accès * Définir la valeur d’audience * Appeler le point de terminaison de l’API My Organization Pour en savoir plus, consultez [Custom Domains](https://auth0.com/docs/customize/custom-domains).
## Activer l’API My Organization dans Auth0 Dashboard
1. Accédez à **[Auth0 Dashboard > Applications > APIs](https://manage.auth0.com/#/apis)**. 2. Repérez la bannière de l’API My Organization. 3. Sélectionnez **Activer**. 4. L’API s’affiche dans votre liste Applications > API sous le nom My Organization API. Une fois l’API My Organization activée : * L’API est désactivée par défaut pour toutes les applications clientes. * Vous devez accorder l’accès aux applications et aux rôles à l’aide de [client grants](/docs/fr-ca/get-started/applications/application-access-to-apis-client-grants) ou de politiques [RBAC](/docs/fr-ca/manage-users/access-control/configure-core-rbac/enable-role-based-access-control-for-apis). * Vos clients d’affaires peuvent récupérer les détails de l’Organization ou configurer des Identity Providers (IdPs) au nom de leurs propres Organizations. Par défaut, l’API My Organization s’active avec les politiques d’accès aux API des applications suivantes : `require_client_grant` pour les flux utilisateur `deny-all` pour les flux client (machine-to-machine) Pour qu’une application puisse accéder à l’API My Organization au nom de l’utilisateur, vous devez créer explicitement un client grant pour cette application, ce qui vous permet de définir les scopes maximaux que l’application peut demander. Vous pouvez aussi modifier la politique des flux d’accès utilisateur à `allow_all`, ce qui permet à toute application de votre tenant de demander n’importe quel scope de l’API My Organization. Comme l’API My Organization expose des renseignements et des opérations sensibles, Auth0 ne recommande pas d’utiliser `allow_all` pour les flux d’accès utilisateur. Vous devriez appliquer le principe du moindre privilège avec l’API My Organization afin de vous assurer que les applications n’obtiennent que l’accès dont elles ont réellement besoin, ce qui réduit au minimum les risques potentiels pour la sécurité. Les permissions finales accordées à l’application seront déterminées par l’intersection des scopes autorisés par la politique d’accès à l’API de l’application, des permissions Role-Based Access Control (RBAC) attribuées à l’utilisateur final et de tout consentement accordé par l’utilisateur (le cas échéant). Pour en savoir plus sur la gestion des politiques d’accès aux API des applications et des client grants qui y sont associés, consultez [Application Access to APIs: Client Grants](https://auth0.com/docs/get-started/applications/application-access-to-apis-client-grants).
## Attributs de l’application cliente
[Créez une application](/docs/fr-ca/get-started/auth0-overview/create-applications) dans Auth0 pour l’utiliser avec l’API My Organization. Une fois l’application créée, accédez à **[Auth0 Dashboard > Applications > APIs](https://manage.auth0.com/#/apis)** et autorisez l’API My Organization, en incluant les scopes que vous voulez permettre à l’application d’utiliser. L’application cliente doit fournir un objet de configuration spécifique (`my_organization_configuration`) contenant les propriétés suivantes : | **Propriété** | **Description** | | ------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `my_organization_configuration` | **Objet.** L’application doit fournir cet objet avec la configuration que l’API My Organization doit utiliser. Si l’application ne définit pas cet objet, l’API My Organization renverra une erreur et rejettera la requête. | | `my_organization_configuration.connection_profile_id` | **ID du Connection Profile.** ID du [Connection Profile](/docs/fr-ca/authenticate/enterprise-connections/connection-profile) utilisé avec l’application dans le cadre de l’API My Organization. S’il n’est pas fourni, les fonctionnalités de l’API My Organization qui exigent la présence d’un Connection Profile ne fonctionneront pas. Cet ID doit faire référence à un Connection Profile valide dans le même tenant. | | `my_organization_configuration.user_attribute_profile_id` | **ID du User Attribute Profile**. ID du [User Attribute Profile](/docs/fr-ca/authenticate/enterprise-connections/user-attribute-profile) utilisé avec l’application dans le cadre de l’API My Organization. S’il n’est pas fourni, les fonctionnalités de l’API My Organization qui exigent la présence d’un User Attribute Profile ne fonctionneront pas. Cet ID doit faire référence à un User Attribute Profile valide dans le même tenant. | | `my_organization_configuration.allowed_strategies` | **tableau de chaînes de caractères.** Chaque chaîne est unique et fait référence à une stratégie prise en charge. Les stratégies prises en charge — les valeurs de l’énumération — sont les suivantes : `pingfederate`, `ad`, `adfs`, `waad`, `google-apps`, `okta`, `oidc` et `samlp`. | | `my_organization_configuration.connection_deletion_behavior` | **Énumération (allow, allow\_if\_empty).** Décrit le comportement de l’API My Organization lorsqu’un utilisateur final tente de supprimer une connexion au moyen de l’API My Organization à partir de cette application. Les valeurs et la description de l’énumération sont les suivantes :

1. `allow`: Si l’utilisateur possède le scope approprié, il peut supprimer la connexion, ce qui entraîne la suppression de tous les utilisateurs provenant de cette connexion.

2.`allow_if_empty`: Si l’utilisateur possède le scope approprié, il peut supprimer la connexion seulement s’il n’y a aucun utilisateur dans la connexion. Si des utilisateurs sont présents, l’API My Organization renverra une erreur et ne procédera pas à la suppression. |

## Obtenir un jeton d’accès
Vous pouvez obtenir un jeton d’accès pour l’API My Organization de la même manière que pour l’une de vos propres API.

Opérations sensibles

Si vous prévoyez autoriser l’API My Organization à effectuer des opérations sensibles (comme l’enregistrement d’une méthode d’authentification), nous vous recommandons fortement d’utiliser l’[authentification renforcée](https://auth0.com/docs/secure/multi-factor-authentication/step-up-authentication) afin d’appliquer des politiques de sécurité supplémentaires au moyen de l’[authentification multifacteur (MFA)](https://auth0.com/docs/secure/multi-factor-authentication).
## Exemples
### Exemple de flux de code d’autorisation
Utilisez le [flux de code d’autorisation](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow) pour les applications Web confidentielles avec un secret client. ```bash theme={null} curl --request POST \ --url 'https://YOUR_DOMAIN/oauth/token' \ --header 'content-type: application/x-www-form-urlencoded' \ --data 'grant_type=authorization_code' \ --data 'client_id=YOUR_CLIENT_ID' \ --data 'client_secret=YOUR_CLIENT_SECRET' \ --data 'code=AUTH_CODE' \ --data 'redirect_uri=https://yourapp/callback' \ --data 'audience=https://YOUR_DOMAIN/my-org/' ``` **Exemple de réponse** ```json theme={null} { "access_token": "eyJz93a...k4laUWw", "token_type": "Bearer", "expires_in": 900, "scope": "read:my_org:details update:my_org:identity_providers" } ```
### Exemple de flux de code d’autorisation avec PKCE
Utilisez le [flux de code d’autorisation avec la clé de preuve pour l’échange de code (PKCE)](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce) pour les applications publiques sans secret client, les applications monopages, les applications mobiles ou natives et les outils CLI. ```bash theme={null} curl --request POST \ --url 'https://YOUR_DOMAIN/oauth/token' \ --header 'content-type: application/x-www-form-urlencoded' \ --data 'grant_type=authorization_code' \ --data 'client_id=YOUR_CLIENT_ID' \ --data 'code=AUTH_CODE' \ --data 'code_verifier=CODE_VERIFIER' \ --data 'redirect_uri=https://yourapp/callback' \ --data 'audience=https://YOUR_DOMAIN/my-org/' ```
## Profils
L’API My Organization utilise les [Connection Profiles](/docs/fr-ca/authenticate/enterprise-connections/connection-profile) et les [User Attribute Profiles](/docs/fr-ca/authenticate/enterprise-connections/user-attribute-profile) pour définir la structure, les restrictions et les règles des configurations créées par des clients tiers.
### Connection Profile (CP)
Le Connection Profile permet aux développeurs d’Auth0 de préciser comment les paramètres privés d’une connexion Auth0 doivent être configurés lorsqu’elle est créée par des tiers. Pour en savoir plus sur le fonctionnement du Connection Profile, ses mappages d’attributs, ses remplacements, consulter des exemples et apprendre à en configurer un, voir [Connection Profiles](/docs/fr-ca/authenticate/enterprise-connections/connection-profile).
### User Attribute Profile (UAP)
Le User Attribute Profile (UAP) offre une façon cohérente de définir, de gérer et de mapper les attributs utilisateur dans des protocoles comme SCIM, SAML et OIDC. Pour en savoir plus sur le fonctionnement du UAP, ses mappages d’attributs, ses surcharges, des exemples et la façon d’en configurer un, consultez [User Attribute Profiles](/docs/fr-ca/authenticate/enterprise-connections/user-attribute-profile).
## Limites de débit
Les limites de débit s’appliquent selon votre niveau de service : | **Niveau** | **Lecture (RPS)** | **Écriture (RPS)** | | ----------------------- | ----------------- | ------------------ | | **Free** | 4 | 2 | | **Public Self-Service** | 8 | 4 | | **Public Enterprise** | 40 | 20 | | **Private Basic** | 40 | 20 | | **Private Performance** | 160 | 80 |
### Limites de débit par Organization
En plus des limites de débit du niveau de service, My Organization API applique aussi des limites de débit par Organization. Ces limites visent à assurer une répartition équitable des ressources et à éviter qu’une seule Organization n’affecte les performances globales de votre tenant. En appliquant ces seuils, nous atténuons l’effet de « voisin bruyant », afin qu’une hausse soudaine d’activité d’une Organization ne monopolise pas les ressources partagées et n’ait pas d’incidence sur une autre au sein du même environnement. Un nombre précis de requêtes par seconde (RPS) est attribué à chaque Organization, tant pour les opérations de lecture que d’écriture. | **Niveau** | **Lecture par Organization (RPS)** | **Écriture par Organization (RPS)** | | ----------------------- | ---------------------------------- | ----------------------------------- | | **Free** | 4 | 2 | | **Public Self-Service** | 4 | 2 | | **Public Enterprise** | 8 | 4 | | **Private Basic** | 8 | 4 | | **Private Performance** | 16 | 8 |
### Authentification
Les jetons Bearer et DPoP sont pris en charge selon la configuration de l’API | | | | ---------------------------- | ------ | | Type de schéma de sécurité : | http | | Schéma d’autorisation HTTP : | bearer |