Delivery Access Token

DeliveryAccessTokenは、CDA(公開配信)で発行されたコンテンツを読み取るときに使う読み取り専用トークンです。ウェブサイトやアプリのブラウザが発行済みコンテンツを取得する際、このトークンでCDAを呼び出します。発行時に1つのSpaceRoleにバインドし、そのロールがトークンの読み取り範囲(どのContent Typeを読めるか)を定めます。

CMAにおいてDeliveryAccessTokenはSpaceの下位リソースであり、パスは/spaces/{spaceId}/delivery-access-tokensを基準とします。このトークンはブラウザ(クライアント)に公開された状態で動作するため、バインドするロールは必要なContent Typeだけを読む最小権限(least-privilege)に設定しなければなりません(下記セキュリティ: 最小権限バインディングを参照)。これに加えて、allowedReferrersに呼び出しを許可するoriginを入れておくと、指定したサイトの外ではこのトークンを使えません(origin の表記ルールとReferer の判定を参照)。

リソース構造

次はDeliveryAccessTokenを生成したときのレスポンスです。sys(システム属性)にトークン値と範囲が入り、本文にname・description・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": "アパレルショップ公開サイト用の閲覧専用配信トークン",
  "name": "ウェブサイト公開配信"
}

主なキー:

• sys.id: DeliveryAccessTokenの一意の識別子です。単一取得・更新・削除パスの{deliveryAccessTokenId}に入ります。
• sys.accessToken: CDA呼び出しに使う秘密のトークン値です。発行後の取得でも同じ値がそのまま返るため、露出に注意が必要です(下記セキュリティ節を参照)。
• sys.scopes: トークンの権限範囲です。DeliveryAccessTokenは発行時に常に["DELIVERY_ACCESS_TOKEN"]です。
• sys.user: このトークンの権限主体となる専用ユーザーです。発行時に自動で作成され、バインドしたSpaceRoleの権限がこのユーザーに付与されます。つまりトークンの実効権限はこのユーザーから生じます。このトークンを実際に発行した人(sys.createdBy)とは別のユーザーです。
• name: 生成時に指定したトークン名です(例: ウェブサイト公開配信)。
• description: トークンの説明です(任意)。
• allowedReferrers: このトークンをどのoriginから呼び出せるかを制限する一覧です。一覧が空なら制限しません。上記の例は、アパレルショップの公開サイト(https://shop.example.com)から呼び出したときにだけ通過するトークンです(表記ルールと判定方法はorigin の表記ルールとReferer の判定を参照)。

上記の例のaccessTokenは秘密の値なので、例示用の文字列に置き換えてあります。実際には長く不透明な文字列であり、発行後に再度取得しても同じ値が返ります。

システム属性 (sys)

すべてのDeliveryAccessTokenは、共通のシステム属性とトークン固有の属性をsysオブジェクトに格納します。space、user、createdBy、updatedByはReferの形({ "sys": { "id", "type": "Refer", "targetType" } })で入ります。

本文の属性:

セキュリティ: 最小権限バインディング

DeliveryAccessTokenは、ブラウザと訪問者に公開された状態でCDAを呼び出すトークンです。そのため、どのSpaceRoleにバインドするかが、そのままこのトークンのセキュリティ境界になります。

• 生成リクエストのroleには、必要なContent Typeだけを読む最小権限のSpaceRoleのsys.idを入れます。公開配信には読み取り専用ロールを推奨します。
• Administratorロールは絶対にバインドしません。 このトークンはクライアントに公開されるため、管理権限を持つロールをバインドすると、その権限がそのまま外部に漏れ出します。また、SpaceRole一覧の先頭の項目を不用意に使わず、意図した最小権限ロールのsys.idを明示的に指定します。
• allowedReferrersで、このトークンを使える場所まで併せて絞ります。 バインドしたロールはこのトークンで何を読めるかを定め、この一覧はどこから呼び出せるかを定めます。ブラウザで動作するトークンは値そのものを隠せないため、公開サイトのoriginを一覧に入れておけば、トークンの値が外部に漏れても、そのサイトの外からのCDA呼び出しは通過しません(Referer の判定を参照)。
• accessTokenは発行後も同じ値で取得される秘密の値です。クライアントのビルドに安全に注入しつつ、外部にそのまま露出しないようにします。

状態と制約

生成・修正時に守る値の制約です。

バインドと権限についてのルール:

• バインドするroleは、そのSpaceに実際に存在していなければなりません。そのSpaceに存在しないロールのsys.idを入れると生成が拒否されます。
• 呼び出し元は、自分がそのSpaceで持っているロールだけをバインドできます。自分が持たないロールをバインドしてトークンにより高い権限を与えることを防ぐための制約であり、これに反する生成リクエストは拒否されます。ただし、そのSpaceの管理者(Administrator ロールの保有者)はこの制約を受けず、どのロールでもバインドできます。
• DeliveryAccessTokenは発行数に上限があるリソースです。現在のプランの発行数の上限を超えると生成が拒否されます。プランごとの上限は料金プランを参照してください。
• 発行・管理(生成・取得・更新・削除)には、呼び出し元のロールのsettingsにSETTING_DELIVERY_ACCESS_TOKENが含まれている必要があります。書き込みまで行えるSpace Access Tokenを発行するSETTING_SPACE_ACCESS_TOKENとは別のアクションなので、配信トークンの発行権限だけを与えて、書き込みトークンの発行は禁止できます(SpaceRoleを参照)。
• このAPIは、コンソールのログインセッションとPersonal Access Tokenからのみ呼び出されます。発行したDeliveryAccessToken自身では、ほかのDeliveryAccessTokenを作成できません。

origin の表記ルール

allowedReferrersの各項目は、呼び出しを許可するoriginを1つ指す文字列です。次の形で書きます。

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

一覧には項目を最大50個まで含められ、同じoriginを二度入れることはできません。項目ごとに守るべきルールは次のとおりです。

• スキームはhttpsだけを使います。httpはlocalhost・127.0.0.1・[::1]にのみ許可されます。
• ワイルドカードは先頭の*.ラベル1つとしてのみ使えます。パスには使えません。
• ホストはASCIIで書きます。国際化ドメインはPunycode表記で入れます。
• ポートは1から65535までです。省略するとスキームの既定ポート(httpsは443、httpは80)として扱います。
• パスを書いた場合は、リクエストのパスと完全に一致するときだけ通過します。ブラウザはパスをパーセントエンコードして送るため、パスにはASCIIだけを使います。
• ユーザー情報(user@)やクエリ(?)、フラグメント(#)が付いた項目は拒否されます。

この検査は、生成・全体更新・部分更新の3つの経路すべてで行われます。ルールに反する項目が1つでもあると、一覧を保存せずリクエストを拒否し、反した項目を1つエラーの理由に含めて知らせます(エラーを参照)。

Referer の判定

発行後にこのトークンでCDAを呼び出すと、リクエストごとにallowedReferrersを適用して通過するかどうかを判定します。

• 一覧が空なら制限しません。どのoriginから呼び出しても通過します。
• 一覧に項目が1つでもあれば、リクエストのRefererヘッダーの値で判定します。Originヘッダーは見ません。
• Refererヘッダーがない、または値が空のリクエストは拒否されます。ブラウザはこのヘッダーを自ら付けて送りますが、サーバーで動かすビルドスクリプトやサーバーレンダリングのようにRefererを送らない場所で使うトークンは、一覧を空にしておきます。
• 通過するには、Refererのスキーム・ホスト・ポートが一覧のいずれか1つの項目とすべて一致していなければなりません。その項目にパスがある場合は、パスまで一致していなければなりません。
• https://*.shop.example.comは、admin.shop.example.comのように.shop.example.comで終わるホストをすべて含み、shop.example.com自身は含みません。両方を許可するには、https://shop.example.comを項目としてもう1つ入れます。
• この判定は、このトークンで送るすべてのリクエストに適用されます。CDAのどのパスを呼び出しても同じです。
• 判定で弾かれたリクエストはHTTP 403で拒否されます。返るコードは下記のエラーにあります。

エラー

DeliveryAccessTokenを扱うときに出会うコードです。すべてのリソースに共通するコードは共通エラーを参照してください。

API

以下のすべてのエンドポイントの基準URLはhttps://cma.weegloo.com/v1であり、AuthorizationヘッダーにCMAを認証するBearerトークンが必要です。DeliveryAccessTokenの更新・部分更新にはX-Weegloo-Versionヘッダーは必要ありません。

関連ドキュメント

• SpaceRole: このトークンにバインドするロール(読み取り範囲)を定義。
• CDA 概要: このトークンで発行済みコンテンツを読み取る配信 API。
• Space Access Token: 1つのSpaceの中で書き込みまで行えるトークン(同じ origin 制限を持ちます)。
• Personal Access Token: サーバー・CI 用の Weegloo User トークン。