Référence de l’API My Organization

Documentation de l’API My Organization d’Auth0

Version : 1.0 (actuelle)

Accès anticipé

L’API My Organization et les composants d’interface utilisateur intégrables sont actuellement offerts en accès anticipé à tous les clients. En utilisant cette fonctionnalité, vous acceptez les conditions applicables de l’essai gratuit énoncées dans le Contrat-cadre d’abonnement d’Okta. Pour en savoir plus sur le cycle de publication des produits d’Auth0, consultez Étapes de publication des produits. Il incombe au client de s’assurer que son utilisation de l’API My Organization et des composants d’interface utilisateur intégrables respecte ses politiques de sécurité et les lois applicables, y compris toute autorisation accordée à ses utilisateurs finaux.

L’API Auth0 My Organization fournit une interface sécurisée, circonscrite à l’organisation, qui permet à vos clients entreprise de gérer leurs propres organisations dans votre locataire Auth0. Cette API constitue la base technique de l’administration déléguée intégrée et des intégrations axées sur l’API.

La documentation de l’API My Organization s’appuie sur le schéma OpenAPI v3.1 de l’API My Organization. Veuillez noter que la prise en charge du schéma OpenAPI v3.1 est actuellement en version bêta.

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 domaine tout au long du processus, notamment pour :

• Obtenir un jeton d’accès
• Définir la valeur de l’audience
• Appeler le endpoint de l’API My Organization

Pour en savoir plus, consultez Domaines personnalisés.

​

Activer l’API My Organization dans Auth0 Dashboard

1. Accédez à Auth0 Dashboard > Applications > APIs.
2. Repérez la bannière My Organization API.
3. Sélectionnez Activer.
4. L’API apparaît 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 d’autorisations d’application ou de politiques RBAC.
• Vos clients d’affaires peuvent récupérer les détails d’une organisation ou configurer des fournisseurs d’identité (IdP) au nom de leurs propres organisations.

Par défaut, l’API My Organization est activée avec les politiques d’accès à l’API pour les applications suivantes :

require_client_grant pour les flux utilisateur deny-all pour les flux d’application (machine-to-machine)

Pour qu’une application puisse accéder à l’API My Organization au nom de l’utilisateur, vous devez créer explicitement une autorisation d’application pour cette application, ce qui vous permet de définir les scopes maximums 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 locataire 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 les risques potentiels pour la sécurité.

Les autorisations finales accordées à l’application seront déterminées par l’intersection des scopes permis par la politique d’accès à l’API pour l’application, des autorisations de Contrôle d’accès basé sur les rôles (RBAC) attribuées à l’utilisateur final et de tout consentement donné par l’utilisateur (le cas échéant).

Pour en savoir plus sur la gestion des politiques d’accès à l’API pour les applications et des autorisations d’application associées, consultez Accès des applications aux API : autorisations d’application.

​

Attributs de l’application cliente

Créer une application dans Auth0 pour l’utiliser avec l’API My Organization. Une fois l’application créée, accédez à Auth0 Dashboard > Applications > APIs et autorisez l’API My Organization, en incluant les scopes que vous voulez accorder à l’application.

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 profil de connexion. ID du profil de connexion utilisé avec l’application lors de l’utilisation 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 profil de connexion ne fonctionneront pas. Cet ID doit faire référence à un profil de connexion valide dans le même locataire.
my_organization_configuration.user_attribute_profile_id	ID du profil d’attribut utilisateur. ID du profil d’attribut utilisateur utilisé avec l’application lors de l’utilisation 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 profil d’attribut utilisateur ne fonctionneront pas. Cet ID doit faire référence à un profil d’attribut utilisateur valide dans le même locataire.
my_organization_configuration.allowed_strategies	Tableau de chaînes. Chaque chaîne est unique et correspond à une stratégie prise en charge. Les stratégies prises en charge — c’est-à-dire 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 par l’entremise 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 dispose du 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 dispose du 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 façon 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’inscription d’une méthode d’authentification), nous vous recommandons fortement d’utiliser l’authentification renforcée afin d’appliquer des politiques de sécurité supplémentaires au moyen de l’authentification multifacteur (MFA).

​

Exemples

​

Exemple de flux de code d’autorisation

Utilisez le flux de code d’autorisation pour les applications Web confidentielles dotées d’un Secret client.

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

{
  "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 PKCE (Proof Key for Code Exchange) pour les applications publiques sans Secret client, les applications monopage, les applications mobiles ou natives et les outils CLI.

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 profils de connexion et les profils d’attributs utilisateur pour définir la structure, les restrictions et les règles des configurations créées par des clients tiers.

​

Profil de connexion (CP)

Le profil de connexion permet aux développeurs 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 profil de connexion, ses mappages et substitutions d’attributs, voir des exemples et apprendre à en configurer un, consultez Profils de connexion.

​

Profil d’attributs utilisateur (UAP)

Le profil d’attributs utilisateur (UAP) fournit une manière cohérente de définir, de gérer et de faire correspondre les attributs utilisateur entre des protocoles comme SCIM, SAML et OIDC. Pour en savoir plus sur le fonctionnement de l’UAP, ses mappages d’attributs et ses remplacements personnalisés, consulter des exemples et apprendre à en configurer un, lisez Profils d’attributs utilisateur.

​

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 organisation

En plus des limites de débit du niveau de service, l’API My Organization applique aussi des limites de débit par organisation. Ces limites visent à assurer une répartition équitable des ressources et à éviter qu’une seule organisation nuise aux performances globales de votre locataire. En imposant ces limites, nous atténuons l’effet du « voisin bruyant » afin qu’une hausse soudaine de l’activité d’une organisation ne monopolise pas les ressources partagées et n’ait pas d’incidence sur une autre organisation dans le même environnement. Un nombre précis de requêtes par seconde (RPS) est attribué à chaque organisation, autant pour les opérations de lecture que d’écriture.

Niveau	Lecture par organisation (RPS)	Écriture par organisation (RPS)
Free	4	2
Public Self-Service	4	2
Public Enterprise	8	4
Private Basic	8	4
Private Performance	16	8

​

Authentification

HTTP : auth Bearer

Les jetons Bearer et DPoP sont pris en charge selon la configuration de l’API.

Type de mécanisme de sécurité :	http
Schéma d’authentification HTTP :	bearer