Enregistrement dynamique d'applications

Apprenez à enregistrer dynamiquement des applications avec Auth0 en utilisant Management API.

Vous pouvez enregistrer dynamiquement des applications tierces pour votre locataire. Cette fonctionnalité est basée sur la spécification Enregistrement dynamique du client OpenID Connect.

​

Activer l’enregistrement dynamique des clients

Auth0 prend en charge Open Dynamic Registration (Enregistrement Dynamique Ouvert), ce qui signifie que si vous activez cette fonctionnalité, n’importe quel utilisateur pourra créer des applications dans votre locataire sans avoir besoin d’un jeton.

Par défaut, l’enregistrement dynamique d’applications est désactivé pour tous les locataires. Pour changer cela, vous devez définir le drapeau enable_dynamic_client_registration sur true dans les paramètres de votre locataire.

Pour ce faire, accédez à Dashboard > Settings (Paramètres) > Advanced (Avancé) et activez l’option Enregistrement dynamique de l’application OIDC.

Vous pouvez également mettre à jour cet indicateur en utilisant le point de terminaison de Management API /Tenant/patch_settings.

cURL

curl --request PATCH \
  --url 'https://{yourDomain}/api/v2/tenants/settings' \
  --header 'authorization: Bearer API2_ACCESS_TOKEN' \
  --header 'cache-control: no-cache' \
  --header 'content-type: application/json' \
  --data '{ "flags": { "enable_dynamic_client_registration": true } }'

Vous devez mettre à jour API2_ACCESS_TOKEN avec un jeton valide avec la permission update:tenant_settings. Pour en savoir plus, lisez Jetons d’accès à Management API.

​

Utiliser l’enregistrement dynamique des clients

Dans cette section, nous verrons comment vous pouvez enregistrer et configurer dynamiquement une application.

​

Enregistrer votre application

Pour enregistrer dynamiquement une application avec Auth0, vous devez envoyer un message HTTP POST au point de terminaison d’enregistrement de l’application : https://{yourDomain}/oidc/register. Notez qu’Auth0 prend en charge Enregistrement Open Dynamic, ce qui signifie que le point de terminaison acceptera une demande d’enregistrement sans jeton d’accès.

Pour créer une application portant le nom Mon application dynamique et les URL de rappel https://application.example.com/callback et https://application.example.com/callback2, utilisez l’extrait de code suivant :

cURL

curl --request POST \
  --url 'https://{yourDomain}/oidc/register' \
  --header 'content-type: application/json' \
  --data '{"client_name":"My Dynamic Application","redirect_uris": ["https://application.example.com/callback", "https://application.example.com/callback2"]}'

Où :

• client_name: nom de l’application dynamique à créer
• redirect_uris (obligatoire) : tableau des URL que Auth0 jugera valides à la fin d’un flux d’authentification.

Vous pouvez aussi définir une valeur pour token_endpoint_auth_method, qui peut être none ou client_secret_post (valeur par défaut). Utilisez token_endpoint_auth_method: none dans la charge utile de la demande si vous créez une application à page unique.

La réponse comprend les informations de base sur l’application.

HTTP/1.1 201 Created
Content-Type: application/json
{
  "client_name": "My Dynamic Application",
  "client_id": "8SXWY6j3afl2CP5ntwEOpMdPxxy49Gt2",
  "client_secret": "Q5O...33P",
  "redirect_uris": [
    "https://application.example.com/callback",
    "https://application.example.com/callback2"
  ],
  "client_secret_expires_at": 0
}

Où :

• client_id : identifiant unique du client. Il s’agit de l’identifiant que vous utiliserez lors de la configuration de vos applications pour utiliser Auth0. Il est généré par le système et ne peut être modifié.
• client_secret : secret client alphanumérique de 64 bits. Cette valeur est utilisée par les applications pour s’authentifier auprès de l’Authentication API /token et pour signer et valider les jetons d’ID.
• client_secret_expires_at: heure à laquelle le client_secret expirera. Pour Auth0, cette valeur sera toujours égale à zéro (0), ce qui signifie que l’application n’expire jamais.

Notez l’ID et le secret client, car ce sont les éléments les plus importants pour l’exécution des flux d’authentification et d’autorisation. Pour en savoir plus, lisez Flux d’authentification et d’autorisation.

N’oubliez pas non plus que les développeurs tiers ne sont pas autorisés à modifier les paramètres de l’application. Si cela s’avère nécessaire, ils doivent contacter le propriétaire du locataire pour lui faire part de sa demande.

​

Configuration de votre application

Maintenant que vous disposez d’un ID et d’un secret client, vous pouvez configurer votre application pour authentifier les utilisateurs avec Auth0.

Nous allons voir un exemple simple, qui montre comment appeler une API à partir d’une application web côté client, en utilisant le Flux implicite.

Tout d’abord, vous devez configurer votre application pour envoyer l’utilisateur à l’URL d’autorisation :

https://{yourDomain}/authorize?
  audience={API_AUDIENCE}&
  scope={SCOPE}&
  response_type={RESPONSE_TYPE}&
  client_id={yourClientId}&
  redirect_uri={https://yourApp/callback}&
  nonce={NONCE}
  state={OPAQUE_VALUE}

Où :

• audience (facultatif) : API cible pour laquelle l’application demande l’accès au nom de l’utilisateur. Définissez ce paramètre si vous avez besoin d’un accès à l’API.
• scope (facultatif) : permissions pour lesquelles vous souhaitez demander une autorisation. Elles doivent être séparées par un espace. Vous pouvez demander l’une des permissions standard OIDC pour les utilisateurs, telles que profile et email, des demandes personnalisées qui doivent se conformer à un format d’espace de noms, ou toute portée prise en charge par l’API cible (par exemple, read:contacts). Définissez ce paramètre si vous avez besoin d’un accès à l’API. Pour en savoir plus, lisez Permissions des API.
• response_type : type de réponse. Pour le consentement implicite, vous pouvez utiliser token ou id_token token. Cela spécifiera le type de jeton que vous recevrez à la fin du flux. Utilisez token pour obtenir uniquement un jeton d’accès, ou id_token token pour obtenir à la fois un jeton d’ID et un jeton d’accès.
• client_id : ID client de votre application.
• redirect_uri : URL vers laquelle le serveur d’autorisation (Auth0) redirigera l’agent utilisateur (navigateur) après autorisation par l’utilisateur. Le jeton d’accès (et éventuellement un jeton d’ID) sera disponible dans le fragment de hachage de cette URL. Cette URL doit être spécifiée comme URL de rappel valide dans les Paramètres d’application de votre application.
• État : valeur opaque que les applications ajoutent à la demande initiale et que le serveur d’autorisation inclut lorsqu’il redirige la demande vers l’application. Cette valeur doit être utilisée par l’application pour prévenir les attaques CSRF.
• nombre aléatoire : Une valeur de chaîne qui sera incluse dans la réponse du jeton d’ID d’Auth0, utilisée pour empêcher les attaques par réinsertion du jeton. Elle est nécessaire pour response_type=id_token token.

Par exemple :

<a href="https://{yourDomain}/authorize?scope=appointments%20contacts&audience=appointments:api&response_type=id_token%20token&client_id={yourClientId}&redirect_uri={https://yourApp/callback}">
  Sign In
</a>

Cet appel redirigera l’utilisateur vers Auth0 et, en cas d’authentification réussie, vers votre application (c’est-à-dire, vers redirect_uri).

Si vous avez besoin d’un accès à l’API, après l’authentification, vous devez extraire le jeton d’accès du fragment de hachage de l’URL et l’utiliser pour effectuer des appels à l’API, en le transmettant en tant que jeton Bearer dans l’en-tête Authorization de la requête HTTP.

​

En savoir plus

• Applications de première et de tierce partie
• User Consent and Third-Party Applications (Consentement de l’utilisateur et applications tierces)