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. Pour en savoir plus sur le cycle de lancement des produits d’Auth0, consultez 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. 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.

​

Activer l’API My Organization dans Auth0 Dashboard

1. Accédez à Auth0 Dashboard > Applications > 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 ou de politiques RBAC.
• 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.

​

Attributs de l’application cliente

Créez 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 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 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 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 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 avec 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 la clé de preuve pour l’échange de code (PKCE) pour les applications publiques sans secret client, les applications monopages, 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 Connection Profiles et les User Attribute Profiles 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.

​

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.

​

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

HTTP : authentification Bearer

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