DocumentationAEMGuide de l’utilisateur

Générer des jetons d’accès pour les API côté serveur generating-access-tokens-for-server-side-apis

Dernière mise à jour : 29 octobre 2026
  • S'applique à :
  • Experience Manager as a Cloud Service

Créé pour :

  • Administrateur ou administratrice
  • Développeur
NOTE
Les informations d’identification de serveur à serveur OAuth dans AEM Developer Console sont disponibles à compter du 4 novembre 2026.
IMPORTANT
Utilisez les informations d’identification de serveur à serveur OAuth pour les intégrations côté serveur. Les informations d’identification du compte de service (JWT) sont abandonnées au profit d’OAuth de serveur à serveur. Pour les intégrations existantes basées sur JWT, voir Génération de jetons d’accès pour les API côté serveur - JWT (hérité).

Certaines architectures reposent sur des appels à Adobe Experience Manager (AEM) as a Cloud Service à partir d’une application hébergée sur un serveur en dehors de l’infrastructure AEM. Par exemple, une application mobile appelle un serveur, qui effectue ensuite des requêtes API à AEM as a Cloud Service.

Utilisez AEM as a Cloud Service Developer Console pour créer un compte technique OAuth de serveur à serveur. Votre application échange son identifiant client et son secret client contre un jeton d’accès à l’aide de l’octroi de client_credentials Adobe Identity Management Services (IMS). Aucun jeton JWT, clé privée ou certificat signé n’est requis.

NOTE
Le Developer Console AEM gère l’accès à votre environnement AEM. Il est différent du Developer Console Adobe sur developer.adobe.com/console. Créez et gérez le compte technique décrit ici dans AEM Developer Console.

Flux de serveur à serveur the-server-to-server-flow

Les utilisateurs et utilisatrices disposant d’un rôle d’administrateur d’organisation IMS qui sont également membres du profil de produit Utilisateurs ou Administrateurs AEM sur l’instance de création AEM peuvent créer un compte technique. Au moment de la création, le secret client n’est visible que par l’utilisateur qui le crée. Un utilisateur ou une utilisatrice disposant du rôle d’administration de l’environnement AEM as a Cloud Service peut afficher les détails du compte, qui n’incluent pas le secret client.

Le flux serveur à serveur comprend les étapes suivantes :

  1. Créez un compte technique de serveur à serveur OAuth et enregistrez ses informations d’identification, y compris le secret client affiché lors de la création.
  2. Stockez les informations d’identification en toute sécurité sur le serveur qui effectue les requêtes vers AEM.
  3. Demandez un jeton d’accès à l’IMS à l’aide de l’identifiant client, du secret client et des portées.
  4. Configurez le profil de produit et les autorisations AEM du compte technique.
  5. Appelez l’API AEM avec le jeton d’accès servant de jeton porteur.

Créer un compte technique et récupérer ses informations d’identification fetch-the-aem-as-a-cloud-service-credentials

IMPORTANT
AEM Developer Console n’affiche un secret client OAuth serveur à serveur qu’une seule fois, lors de sa création. Le Developer Console AEM ne stocke pas la valeur secrète . Il conserve uniquement l’identifiant secret et son statut. IMS stocke le secret en tant que hachage unidirectionnel. Enregistrez le secret en toute sécurité lorsqu’il est affiché. Si vous le perdez, créez un nouveau secret à l’aide d’un autre secret actif ou créez un compte technique.

  1. Ouvrir les intégrations. Ouvrez AEM Developer Console pour l’environnement auquel votre application accède, puis sélectionnez Intégrations. Sélectionnez Créer un compte technique.

    Page Intégrations avec l’option Créer un compte technique mise en surbrillance

  2. Créez le compte technique. Dans la boîte de dialogue, sélectionnez OAuth de serveur à serveur (S2S) comme Type d’informations d’identification, puis sélectionnez Créer.

    Boîte de dialogue Créer un compte technique avec l’option OAuth de serveur à serveur sélectionnée

  3. Enregistrez le secret client. La boîte de dialogue Enregistrer le secret client affiche les informations d’identification, y compris les technicalAccount.clientSecret. Sélectionnez Télécharger les informations d’identification pour les enregistrer en tant que aem-s2s-credentials.json ou sélectionnez Copier dans le presse-papiers. Stockez les informations d’identification dans un gestionnaire de secrets ou un autre emplacement dont l’accès est contrôlé pour votre application.

    Enregistrez la boîte de dialogue du secret client avec la valeur du secret client masquée et sélectionnez Télécharger les informations d’identification et Copier dans le presse-papiers

    Sélectionner Fermer. Dans la boîte de dialogue de confirmation Fermer sans autre accès à votre secret, sélectionnez Fermer uniquement après avoir enregistré le secret en toute sécurité. Une fois la boîte de dialogue fermée, le secret ne peut plus être affiché.

    Fermer sans autre accès à la boîte de dialogue de confirmation secrète avec Fermer en surbrillance

  4. Vérifier le compte technique. Le nouveau compte OAuth serveur à serveur est répertorié avec son secret client actif. L’identifiant de secret affiché dans la liste identifie un secret. Il ne s’agit pas de la valeur secrète et ne peut pas être utilisé comme client_secret dans une demande de jeton.

    Nouveau compte OAuth serveur à serveur avec un secret client actif et son menu d’actions ouvert

Pour consulter les détails d’un secret ultérieurement, ouvrez le menu de ligne du secret client et sélectionnez Afficher. La boîte de dialogue des informations d’identification affiche le point d’entrée IMS, les portées, l’identifiant client, l’adresse e-mail du compte technique, l’identifiant secret et le statut de révocation. Elle n’affiche pas la valeur du secret client.

​ Boîte de dialogue Informations d’identification sans valeur de secret client

NOTE
Les clients peuvent créer jusqu’à 20 comptes techniques. Les comptes supprimés sont comptabilisés dans cette limite.
IMPORTANT
Un administrateur d’organisation IMS qui est également membre du profil de produit Utilisateurs ou Administrateurs AEM sur l’instance de création AEM doit créer le compte technique. Comme le secret client n’est affiché qu’une seule fois, l’utilisateur qui crée le compte est chargé de transmettre les informations d’identification au propriétaire de l’application par le biais d’un canal sécurisé.

Installer les informations d’identification du service AEM sur un serveur non AEM install-the-aem-service-credentials-on-a-non-aem-server

Rendez les informations d’identification disponibles uniquement pour l’application côté serveur qui appelle AEM. Utilisez un gestionnaire de secrets ou un autre mécanisme de stockage dont l’accès est contrôlé.

Ne placez pas de secret client dans le code côté navigateur, les applications mobiles, le contrôle de code source ou les journaux. Traitez également les jetons d’accès comme des secrets.

Demander un jeton d’accès OAuth request-an-oauth-access-token

Envoyez une demande de POST HTTPS à https://<imsEndpoint>/ims/token/v3. Le imsEndpoint dans vos informations d’identification JSON est un nom d’hôte IMS. Par exemple, ims-na1.adobelogin.com utilise https://ims-na1.adobelogin.com/ims/token/v3. Utilisez le nom d’hôte fourni dans vos informations d’identification, y compris le nom d’hôte d’évaluation lors de l’utilisation des informations d’identification d’évaluation.

Utilisez Content-Type: application/x-www-form-urlencoded et incluez ces champs de formulaire dans le corps de la requête :

Paramètre
Valeur
grant_type
client_credentials
client_id
technicalAccount.clientId à partir de vos informations d’identification.
client_secret
technicalAccount.clientSecret enregistré lors de la création du secret.
scope
Les valeurs en scopes, jointes par des virgules.

Encodez chaque valeur de formulaire par URL. Envoyez les secrets dans le corps de la requête, et non dans l’URL ou la chaîne de requête.

La réponse inclut access_token, token_type et expires_in. Utilisez access_token pour appeler AEM. La valeur expires_in correspond à la durée de vie du jeton, exprimée en secondes. Utilisez cette valeur plutôt que de supposer un délai d’expiration fixe.

Mettez en cache et réutilisez le jeton d’accès jusqu’à ce qu’il arrive à expiration, puis demandez un nouveau jeton avec les mêmes informations d’identification client. Cette autorisation ne nécessite pas d’échange JWT ni de jeton d’actualisation.

NOTE
Utilisez les informations d’identification de l’environnement AEM que vous appelez. Un jeton d’accès IMS valide n’accorde pas d’autorisations AEM supplémentaires. Configurez les autorisations du compte technique comme décrit ci-dessous.

Exemple d’authentification Node.js nodejs-authentication-example

Pour une implémentation minimale d’OAuth serveur à serveur, consultez l’exemple de bibliothèque cliente de l’API AEM-CS 🔗. Il utilise les API Node.js intégrées et nécessite Node.js 18 ou version ultérieure, sans dépendances supplémentaires.

L’exemple exige les informations d’identification dans un objet integration. Le fichier aem-s2s-credentials.json téléchargé à partir d’AEM Developer Console contient les informations d’identification sans ce wrapper. Encapsulez son contenu avant de l’utiliser avec l’exemple, par exemple avec jq :

jq '{integration: .}' aem-s2s-credentials.json > downloaded_integration.json

Vous pouvez également modifier le fichier afin que son contenu complet devienne la valeur d’un champ de integration de niveau supérieur. À partir d’une extraction de l’exemple de référentiel, exécutez :

node oauth-s2s-cli.js downloaded_integration.json

Pour une utilisation par programmation, l’assistant OAuth accepte l’objet encapsulé en tant que requestAccessToken(credentials). Il utilise le nom d’hôte IMS, l’ID client, le secret client et les portées dans integration.

Gardez le fichier d’informations d’identification privé. L’interface de ligne de commande imprime un jeton d’accès. N’envoyez pas sa sortie aux journaux partagés ou ne la publiez pas. Le fichier README de l’exemple indique également comment utiliser le jeton dans une requête API AEM.

Appel de l’API AEM calling-the-aem-api

Incluez le jeton d’accès dans l’en-tête Authorization des requêtes à votre environnement AEM as a Cloud Service, à l’aide de la valeur Bearer <access_token>.

curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
  "https://author-p<program-id>-e<environment-id>.adobeaemcloud.com/content/dam.json"

Utilisez le nom d’hôte pour l’environnement et le niveau auxquels votre application accède. Appelez uniquement les ressources auxquelles le compte technique est autorisé à accéder.

Définir les autorisations appropriées pour l’utilisateur ou l’utilisatrice du compte technique dans AEM set-the-appropriate-permissions-for-the-technical-account-user-in-aem

  1. Ouvrez le 🔗.
  2. Sélectionnez ​​sous Produits et services.
  3. Créez un profil de produit pour l’intégration ou sélectionnez un profil existant approprié.
  4. Sélectionnez Ajouter un utilisateur et ajoutez le compte technique à l’aide du email à partir de ses informations d’identification.
  5. Laissez le temps aux modifications du profil de produit de se propager. Effectuez un appel API vers AEM avec un jeton d’accès généré pour le compte technique. Le profil de produit est synchronisé en tant que groupe AEM, avec le compte technique en tant que membre.
  6. Sur l’instance d’auteur AEM appropriée, ouvrez Outils > Sécurité > Groupes. Recherchez le groupe de profils de produit et vérifiez que le compte technique apparaît sous Membres. Vous pouvez également vérifier son appartenance à un groupe sous Outils > Sécurité > Utilisateurs.
  7. Ouvrez Paramètres > Sécurité > Autorisations. Sélectionnez le groupe correspondant au profil de produit et configurez les autorisations requises par vos appels API.
  8. Vérifiez les appels d’API requis par rapport à chaque niveau auquel l’application accède. Accordez uniquement les autorisations nécessaires à l’intégration.
NOTE
Lors du remplacement d’un compte technique JWT par un compte serveur à serveur OAuth, attribuez le nouveau compte aux profils de produit requis et vérifiez ses autorisations AEM. Les autorisations de l’ancien compte technique ne sont pas automatiquement transférées vers le nouveau compte.

Pour plus d’informations sur les utilisateurs et les groupes IMS et AEM, voir Prise en charge d’IMS.

Flux de développement developer-flow

Pour les tests locaux, les développeurs et développeuses peuvent générer un jeton d’accès au développement directement dans le Developer Console AEM sans créer de compte technique de serveur à serveur OAuth. Le jeton peut être utilisé pour appeler les environnements AEM auxquels le développeur peut accéder. Utilisez des informations d’identification de serveur à serveur OAuth, plutôt qu’un jeton de développement local, pour les applications côté serveur sans assistance.

Consultez les Developer Guidelines pour connaître les autorisations requises pour utiliser AEM Developer Console.

NOTE
Un jeton d’accès au développement local est valide pendant 24 heures au maximum. Après expiration, générez un autre jeton en utilisant la même méthode.

Génération du jeton d’accès generating-the-access-token

  1. Dans AEM Developer Console, accédez à Intégrations > Jeton local.
  2. Sélectionnez Obtenir le jeton de développement local.

Appelez ensuite l’application AEM à l’aide du jeton d’accès. call-the-aem-application-with-an-access-token

Utilisez le jeton d’accès au développement local comme jeton porteur dans l’en-tête Authorization, comme décrit dans la section Appeler l’API AEM.

Pour un projet AEM s’exécutant sur votre ordinateur local, aucun jeton d’accès IMS n’est nécessaire.

Rotation des secrets client refresh-credentials

Les informations d’identification de serveur à serveur OAuth ne nécessitent pas de renouvellement de certificat annuel. Faites pivoter les secrets clients périodiquement et chaque fois qu’un secret est exposé. Créez un nouveau secret, commutez-y vos applications, puis révoquez l’ancien secret.

La création et la révocation de secrets nécessitent les valeurs secrètes que vous avez enregistrées. Le Developer Console AEM utilise un secret saisi uniquement pour authentifier la requête auprès d’IMS et ne la stocke pas.

IMPORTANT
IMS requiert au moins un secret actif. Créez et vérifiez un nouveau secret avant de révoquer le dernier secret actif. Pour arrêter complètement d’utiliser le compte technique, supprimez le compte à la place.

  1. Créer un secret. Dans Intégrations, ouvrez le menu d’actions en regard du nom du compte de serveur à serveur OAuth et sélectionnez Créer un secret. Il s’agit du menu au niveau du compte, et non du menu en ligne d’un secret client.

    Menu d’action de compte de serveur à serveur OAuth avec l’option Créer un secret mise en surbrillance

  2. S’authentifier avec un secret actif. Dans la boîte de dialogue Créer un secret, saisissez la valeur d’un secret client actif pour le compte, puis sélectionnez Créer un secret.

    Boîte de dialogue Créer un secret avec le champ Secret client actif et le bouton Créer un secret en surbrillance

  3. Enregistrez le nouveau secret. La boîte de dialogue affiche le nouveau secret une fois, avec ses clientId, secretId, clientSecret et scopes. Téléchargez-le ou copiez-le, stockez-le en toute sécurité et fermez la boîte de dialogue. Confirmez que vous ne souhaitez le fermer qu’après avoir enregistré le secret en toute sécurité. Une fois la boîte de dialogue fermée, le nouveau secret ne peut plus être affiché.

    Nouvelle boîte de dialogue secrète avec la valeur de secret client masquée et Télécharger les informations d’identification et les Copier dans le presse-papiers en surbrillance

  4. Basculer les applications vers le nouveau secret. Remplacez la valeur technicalAccount.clientSecret dans les informations d’identification que chaque instance d’application et déploiement utilise par la nouvelle clientSecret. Les autres valeurs d’identification ne changent pas.

    Demandez un nouveau jeton d’accès avec le nouveau secret et vérifiez les appels API AEM requis avant de continuer. Les deux secrets restent actifs pendant le basculement de l’application. La réutilisation d’un jeton d’accès émis précédemment ne vérifie pas le nouveau secret.

  5. Sélectionnez l’ancien secret pour la révocation. Une fois que toutes les applications ont utilisé le nouveau secret, ouvrez le menu de ligne de l’ancien secret et sélectionnez Révoquer. Vérifiez l’ID du secret pour vous assurer que vous avez sélectionné l’ancien secret.

    Menu Action de l’ancien secret client avec Révoquer mis en surbrillance lorsque les deux secrets sont actifs

  6. Confirmer la révocation. Dans la boîte de dialogue Révoquer le secret client, vérifiez l’ID du secret client à révoquer, saisissez la valeur de ce secret, puis sélectionnez Révoquer. Si vous ne disposez plus de la valeur secrète, contactez l’assistance Adobe. Une fois que la révocation se propage via IMS, les applications ne peuvent pas utiliser ce secret pour demander de nouveaux jetons. Les jetons d’accès existants peuvent rester valides.

    Boîte de dialogue Révoquer le secret client avec le champ Secret client et le bouton Révoquer en surbrillance

  7. Vérifier le résultat. L’ancien secret est répertorié comme Révoqué, tandis que le nouveau secret reste Actif.

    Liste des secrets clients affichant l’ancien secret comme révoqué et le nouveau secret comme actif, avec l’option Supprimer du secret révoqué mise en surbrillance

    Une fois la révocation prise en compte, vérifiez que l’ancien secret ne peut pas émettre de nouveaux jetons d’accès et que le nouveau secret le peut. La seule vérification du statut affiché ne vérifie pas la propagation IMS.

  8. Supprimez le secret révoqué si vous n’en avez plus besoin. Pour supprimer le secret révoqué de la liste, ouvrez son menu de ligne, sélectionnez Supprimer et confirmez.

Révocation des informations d’identification credentials-revocation

Révoquer désactive un secret sélectionné pour les nouvelles demandes de jeton. Elle nécessite la valeur du secret en cours de révocation. La révocation peut prendre du temps à se propager. Ne supposez pas que la révocation d’un secret invalide immédiatement les jetons d’accès qui ont déjà été émis.

Supprimer sur un secret révoqué supprime ses métadonnées, telles que l’identifiant du secret et le statut de révocation, d’AEM Developer Console. Il n’effectue pas de révocation IMS distincte et n’est pas disponible pour les secrets actifs.

Suppression d’un compte technique delete-a-technical-account

La suppression d’un compte technique entraîne immédiatement la révocation du compte et de tous ses secrets clients dans IMS. Aucun nouveau jeton d’accès n’est émis pour les informations d’identification sous le compte, et les intégrations qui l’utilisent cessent de fonctionner une fois que leurs jetons actuels expirent. Pour restaurer l’accès, vous devez créer un nouveau compte technique, mettre à jour vos applications avec ses informations d’identification et attribuer à nouveau les autorisations requises dans AEM.

La suppression du compte ne peut pas être annulée. Confirmez uniquement après avoir vérifié quelles applications dépendent du compte et ne l’utilisez pas comme étape de rotation individuelle-secrète.

  1. Dans Intégrations, ouvrez le menu d’actions en regard du nom du compte technique et sélectionnez Supprimer.

    Menu d’action de compte de serveur à serveur OAuth avec l’option Supprimer mise en surbrillance

  2. Consultez la boîte de dialogue Supprimer le compte technique puis sélectionnez Supprimer.

    ​ Boîte de dialogue de confirmation Supprimer le compte technique ​

Migration d’une intégration basée sur JWT migrate-a-jwt-based-integration

  1. Créez un compte technique de serveur à serveur OAuth dans AEM Developer Console.
  2. Attribuez le nouveau compte technique aux profils de produit requis et configurez ses autorisations AEM.
  3. Mettez à jour l’application côté serveur pour demander des jetons à l’aide de client_credentials au lieu de signer et d’échanger un jeton JWT.
  4. Vérifiez la nouvelle génération de jeton et les appels API requis à l’aide du nouveau compte.
  5. Une fois que toutes les instances d’application ont utilisé OAuth de serveur à serveur, supprimez les anciennes informations d’identification JWT et l’ancien compte technique.

Pour les opérations sur les certificats et les clés privées sur l’ancien compte, reportez-vous au guide hérité de JWT. Ne supprimez pas l’ancien compte avant la vérification de l’intégration de remplacement.

recommendation-more-help
experience-manager-cloud-service-help-main-toc