Delivery Access Token

Le DeliveryAccessToken est un jeton en lecture seule utilisé pour lire le contenu publié depuis la CDA (diffusion publique). Le navigateur d'un site web ou d'une application appelle la CDA avec ce jeton pour récupérer le contenu publié. Lors de son émission, il est lié à un seul SpaceRole, et ce rôle définit la portée de lecture du jeton (quels Content Type peuvent être lus).

Dans la CMA, le DeliveryAccessToken est une ressource enfant du Space, et son chemin repose sur /spaces/{spaceId}/delivery-access-tokens. Comme ce jeton fonctionne en étant exposé au navigateur (le client), le rôle auquel il est lié doit impérativement être défini avec le moindre privilège (least-privilege), c'est-à-dire ne lire que les Content Type nécessaires (voir Sécurité : liaison au moindre privilège ci-dessous). En complément, si vous placez dans allowedReferrers les origines depuis lesquelles l'appel est autorisé, le jeton ne peut plus servir en dehors des sites indiqués (voir Règles d'écriture des origines et Contrôle du Referer).

Structure de la ressource

Voici la réponse obtenue lors de la création d'un DeliveryAccessToken. L'objet sys (propriétés système) contient la valeur et la portée du jeton, et le corps comporte name, description et allowedReferrers.

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7PUFQuOAqWOc",
    "type": "DeliveryAccessToken",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "user": { "sys": { "id": "3trmXRLdJIqc9GPBbyFYQQw6hf9kGj", "type": "Refer", "targetType": "User" } },
    "createdBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PUFQsSPi0nt", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-06-18T09:24:23.156Z",
    "updatedBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PUFQsSPi0nt", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-06-18T09:24:23.156Z",
    "accessToken": "DVRATbQ8mX2vK9pLs7Rf1Zt0Nc4Wd6Hg5Ua2Ee9Ck3PoYx8Bj6Hg5Ua2Ee9Ck3Po…",
    "scopes": ["DELIVERY_ACCESS_TOKEN"]
  },
  "allowedReferrers": ["https://shop.example.com"],
  "description": "Jeton de diffusion en lecture seule pour le site public de la boutique de vêtements",
  "name": "Diffusion publique du site web"
}

Clés principales :

• sys.id : identifiant unique du DeliveryAccessToken. Il s'insère dans le {deliveryAccessTokenId} des chemins de consultation, de modification et de suppression d'un élément unique.
• sys.accessToken : valeur secrète du jeton utilisée pour les appels CDA. Comme la même valeur réapparaît à l'identique lors d'une consultation après émission, il faut veiller à son exposition (voir la section sécurité ci-dessous).
• sys.scopes : portée des autorisations du jeton. Pour un DeliveryAccessToken, c'est toujours ["DELIVERY_ACCESS_TOKEN"] à l'émission.
• sys.user : utilisateur dédié qui est le sujet des autorisations de ce jeton. Il est créé automatiquement lors de l'émission, et les autorisations du SpaceRole lié sont accordées à cet utilisateur. Autrement dit, les autorisations effectives du jeton proviennent de cet utilisateur. C'est un utilisateur différent de la personne qui a réellement émis ce jeton (sys.createdBy).
• name : nom du jeton défini lors de la création (par exemple : Diffusion publique du site web).
• description : description du jeton (facultatif).
• allowedReferrers : liste qui restreint les origines depuis lesquelles ce jeton peut être appelé. Une liste vide ne restreint rien. Le jeton de l'exemple ci-dessus ne passe que lorsqu'il est appelé depuis le site public de la boutique de vêtements, à l'origine https://shop.example.com. Pour les règles d'écriture et le mode de contrôle, voir Règles d'écriture des origines et Contrôle du Referer.

Dans l'exemple ci-dessus, accessToken est une valeur secrète, donc elle a été remplacée par une chaîne d'exemple. En réalité, il s'agit d'une chaîne longue et opaque, et la même valeur réapparaît même si on la consulte de nouveau après émission.

Propriétés système (sys)

Chaque DeliveryAccessToken place dans l'objet sys des propriétés système communes ainsi que des propriétés propres au jeton. space, user, createdBy et updatedBy se présentent sous la forme Refer ({ "sys": { "id", "type": "Refer", "targetType" } }).

Propriétés du corps :

Sécurité : liaison au moindre privilège

Le DeliveryAccessToken est un jeton qui appelle la CDA tout en étant exposé au navigateur et aux visiteurs. Par conséquent, le SpaceRole auquel il est lié constitue directement la frontière de sécurité de ce jeton.

• Dans le role de la requête de création, indiquez le sys.id d'un SpaceRole au moindre privilège qui ne lit que les Content Type nécessaires. Pour la diffusion publique, un rôle en lecture seule est recommandé.
• Ne liez jamais le rôle Administrator. Comme ce jeton est exposé au client, lier un rôle assorti de privilèges d'administration ferait fuiter ces privilèges tels quels vers l'extérieur. De plus, n'utilisez pas par inadvertance le premier élément de la liste des SpaceRole : indiquez explicitement le sys.id du rôle au moindre privilège voulu.
• Avec allowedReferrers, délimitez aussi les endroits où ce jeton peut servir. Le rôle lié définit ce que ce jeton peut lire, et cette liste définit depuis où le jeton peut être appelé. Comme la valeur d'un jeton qui fonctionne dans le navigateur ne peut pas être dissimulée, placez dans la liste l'origine du site public : même si cette valeur fuite à l'extérieur, un appel CDA ne passe pas en dehors de ce site (voir Contrôle du Referer).
• accessToken est une valeur secrète qui se consulte avec la même valeur même après émission. Injectez-la de façon sécurisée dans le build du client, mais ne l'exposez pas telle quelle à l'extérieur.

États et contraintes

Contraintes de valeur à respecter lors de la création et de la modification.

Règles relatives à la liaison et aux permissions :

• Le role à lier doit réellement exister dans ce Space. Si vous indiquez le sys.id d'un rôle qui n'existe pas dans ce Space, la création est refusée.
• L'appelant ne peut lier que les rôles qu'il détient lui-même dans ce Space. Cette contrainte empêche d'accorder au jeton des privilèges plus élevés en liant un rôle que l'appelant ne détient pas ; une demande de création qui l'enfreint est refusée. Toutefois, l'administrateur de ce Space (le détenteur du rôle Administrator) n'est pas soumis à cette contrainte et peut lier n'importe quel rôle.
• Le DeliveryAccessToken est une ressource soumise à une limite de nombre. Si vous dépassez la limite d'émission de la formule actuelle, la création est refusée. Pour les limites par formule, consultez Tarifs.
• L'émission et la gestion (création, consultation, modification, suppression) exigent la présence de SETTING_DELIVERY_ACCESS_TOKEN dans le settings du rôle de l'appelant. Comme il s'agit d'une action distincte de SETTING_SPACE_ACCESS_TOKEN, qui émet le Space Access Token doté aussi de l'écriture, vous pouvez n'accorder que le droit d'émettre le jeton de diffusion tout en interdisant l'émission du jeton d'écriture (voir SpaceRole).
• Cette API n'est appelée qu'avec une session de connexion à la console ou un Personal Access Token. Un DeliveryAccessToken déjà émis ne peut pas lui-même créer un autre DeliveryAccessToken.

Règles d'écriture des origines

Chaque élément de allowedReferrers est une chaîne qui désigne une seule origine depuis laquelle l'appel est autorisé. Écrivez cette chaîne sous la forme suivante.

"allowedReferrers": [
  "https://shop.example.com",
  "https://*.shop.example.com",
  "http://localhost:3000"
]

La liste accepte au maximum 50 éléments, et une même origine ne peut pas y figurer deux fois. Les règles que chaque élément doit respecter sont les suivantes.

• Le schéma doit être https. Le schéma http n'est admis que pour localhost, 127.0.0.1 et [::1].
• Le caractère générique s'écrit uniquement comme une seule étiquette *. placée en tête. Il ne peut pas s'employer dans le chemin.
• Écrivez l'hôte en ASCII. Indiquez un domaine internationalisé en notation Punycode.
• Le port va de 1 à 65535. S'il est omis, c'est le port par défaut du schéma qui s'applique (443 pour https, 80 pour http).
• Si vous indiquez un chemin, la requête ne passe que lorsque le chemin de la requête est exactement le même. Comme le navigateur envoie le chemin en encodage pourcent, n'écrivez le chemin qu'en ASCII.
• Un élément portant des informations d'utilisateur (user@), une requête (?) ou un fragment (#) est refusé.

Ce contrôle s'applique aux trois chemins : la création, la modification complète et la modification partielle. S'il subsiste ne serait-ce qu'un élément contraire aux règles, la liste n'est pas enregistrée et la requête est refusée ; l'un des éléments en infraction est signalé dans le motif de l'erreur (voir Erreurs).

Contrôle du Referer

Après l'émission, chaque fois que vous appelez la CDA avec ce jeton, allowedReferrers est appliqué à la requête pour décider si elle passe.

• Si la liste est vide, aucune restriction ne s'applique. La requête passe depuis n'importe quelle origine.
• Dès que la liste comporte au moins un élément, la décision se prend sur la valeur de l'en-tête Referer de la requête. L'en-tête Origin n'est pas examiné.
• Si l'en-tête Referer est absent ou si sa valeur est vide, la requête est refusée. Le navigateur joint cet en-tête de lui-même, mais laissez la liste vide pour un jeton destiné à des endroits qui n'envoient pas de Referer, comme un script de build exécuté sur un serveur ou un rendu côté serveur.
• Pour passer, le schéma, l'hôte et le port du Referer doivent tous être identiques à ceux d'un élément de la liste. Si cet élément comporte un chemin, le chemin doit lui aussi être identique.
• https://*.shop.example.com couvre tous les hôtes qui se terminent par .shop.example.com, comme admin.shop.example.com, mais ne couvre pas shop.example.com lui-même. Pour autoriser les deux, ajoutez https://shop.example.com comme élément supplémentaire.
• Ce contrôle s'applique à toutes les requêtes envoyées avec ce jeton. Il en va de même quel que soit le chemin CDA appelé.
• Une requête arrêtée par ce contrôle est refusée avec un HTTP 403. Le code renvoyé figure dans Erreurs ci-dessous.

Erreurs

Ce sont les codes que l'on rencontre lorsque l'on manipule un DeliveryAccessToken. Pour les codes communs à toutes les ressources, consultez Erreurs communes.

API

L'URL de base de tous les points de terminaison ci-dessous est https://cma.weegloo.com/v1, et un jeton Bearer authentifiant la CMA est requis dans l'en-tête Authorization. La modification et la modification partielle d'un DeliveryAccessToken ne nécessitent pas l'en-tête X-Weegloo-Version.

Documents associés

• SpaceRole : définit le rôle (portée de lecture) à lier à ce jeton.
• Présentation de la CDA : l'API de diffusion qui lit le contenu publié avec ce jeton.
• Space Access Token : jeton qui permet aussi l'écriture au sein d'un seul Space (ce jeton dispose de la même restriction d'origines).
• Personal Access Token : jeton Weegloo User pour les serveurs et la CI.