vtex-io-auth-tokens-and-context について
VTEX IO のバックエンドリクエストで使用する ID を選ぶためのスキルです。アプリ、購入者、Admin ユーザーのトークンを区別し、トークンの受け渡しと認証情報の扱いを説明します。
主な機能
- 01リクエストコンテキストに応じたトークン選択
- 02アプリ・購入者・Admin の ID の区別
- 03authMethod とカスタムクライアントの指針
- 04VTEX 認証情報のハードコード防止
- 05ログやレスポンスへのトークン混入防止
活用シーン
- 01ストアフロントリクエストの認証レビュー
- 02Admin 操作を現在のユーザー ID に結び付ける
- 03ハードコードされた API 認証情報の置き換え
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ vtex/ skills --skill vtex-io-auth-tokens-and-contextインストール後、Claude Code で/vtex-io-auth-tokens-and-contextを入力して読み込まれたか確認します。
詳細
認証トークンとリクエストコンテキスト
このスキルを使用する場面
バックエンドから VTEX サービスにリクエストを送る際、どの VTEX IO ID で認証するかが主な判断事項である場合に、このスキルを使用します。
ctx.authToken、ctx.storeUserAuthToken、ctx.adminUserAuthTokenのいずれを選ぶか- VTEX クライアントの呼び出しで
AUTH_TOKEN、STORE_TOKEN、ADMIN_TOKENのいずれを使用するか - 現在のユーザー ID を尊重する必要があるストアフロントおよび Admin のインテグレーションをレビューする場合
- VTEX IO アプリ内のハードコードされた
appKeyとappTokenの使用を置き換える場合
次の用途には、このスキルを使用しないでください。
manifest.jsonにどのポリシーを指定するかの判断- ルートレベルの認可やリソースベースのポリシーの設計
ExternalClient、JanusClient、その他のクライアント抽象化の選択- ブラウザー側のログインやセッションの UX フロー
- ルート入力の検証や、アプリの境界を越えて受け渡し可能なデータの判断
判断ルール
- このスキルでは、VTEX エンドポイントへの呼び出しにどの ID を使用するかを判断します。その ID に何が許可されているかは判断しません。
ctx.authTokenとAUTH_TOKENは、現在の購入者や Admin ユーザーに紐づかないアプリレベルの操作にのみ使用します。- ストアフロントの閲覧や購入者が開始したフローに起因する操作では、常に
ctx.storeUserAuthTokenとSTORE_TOKENを使用します。インテグレーションは購入者の権限を尊重する必要があります。 - Admin インターフェースに起因する操作では、常に
ctx.adminUserAuthTokenとADMIN_TOKENを使用します。インテグレーションはログイン中の Admin ユーザーの License Manager 権限を尊重する必要があります。 - ユーザートークンが利用可能な場合は、ユーザートークンを優先します。公式ガイダンスでは、ストアまたは Admin ユーザーのトークンでリクエスト元をより正確に表せる場合、アプリトークン認証を避けるよう推奨されています。
- 対応するユーザートークンがない場合、操作が真にアプリスコープであり、現在の購入者や Admin の ID に依存しないときに限り、
AUTH_TOKENにフォールバックします。 authMethodを受け取る VTEX IO クライアントを使用する場合、デフォルトのアプリ ID がリクエストに適さないときは、トークンの選択を明示的に渡します。- カスタム VTEX クライアントをラップする場合、ハンドラーに認証情報をハードコードするのではなく、クライアントの境界で
IOContextから対応する認証トークンを渡します。 - トークンの選択はユーザージャーニーに沿ったものにします。ストアフロントのフローでアプリレベルの権限に暗黙に昇格させてはならず、Admin のフローで現在の Admin のロールコンテキストを迂回してはなりません。
ctx.adminUserAuthTokenとADMIN_TOKENはサーバー側のみで使用し、ブラウザークライアントに決して公開したり、プロキシしたりしてはなりません。- トークンの選択とポリシーの設計は別の関心事として扱います。このスキルでは呼び出しを行う ID を決め、auth-and-policies ではその ID に許可されている操作を決めます。
- 通常の VTEX IO 認証トークンモデル以外の、文書化された例外がない限り、VTEX IO アプリ内で
appKeyとappTokenを使用してはなりません。 - 生のトークンをログに記録したり、レスポンスで返したりしてはなりません。トークンはリクエストの機密情報であり、後続の呼び出し元には業務データのみを返します。
トークン選択の概要:
| トークン | コンテキストフィールド | 使用する場面 | 使用を避ける場面 |
|---|---|---|---|
AUTH_TOKEN | ctx.authToken | アプリレベルのジョブ、サービス間の処理、または現在のユーザーに紐づかない操作 | 購入者または Admin ユーザーがすでに操作を開始している場合 |
STORE_TOKEN | ctx.storeUserAuthToken | ストアフロントおよび購入者が開始する操作 | バックエンドジョブまたは Admin 専用の操作 |
ADMIN_TOKEN | ctx.adminUserAuthToken | 現在のユーザーの LM ロールを尊重する必要がある Admin リクエスト | ストアフロントのフローまたはバックグラウンドのアプリタスク |
厳守事項
制約:ユーザー起点のリクエストでは、アプリトークンよりユーザートークンを優先する
現在の購入者または管理者ユーザーがリクエストを開始した場合、VTEX インテグレーションでは、デフォルトでアプリトークンを使用するのではなく、対応するユーザートークンを必ず使用してください。
重要な理由
ユーザー起点の処理にアプリトークンを使用すると、権限が不必要に広がり、アクセスを制御するべき実際のユーザーコンテキストからリクエストが切り離されます。
検出方法
コードがストアフロントまたは管理者リクエストの経路で実行されているにもかかわらず、ctx.authToken または暗黙的なアプリトークンの動作が使われている場合は、処理を止めて、代わりに ctx.storeUserAuthToken または ctx.adminUserAuthToken を使うべきか確認してください。
正しい例
export class OmsClient extends JanusClient {
constructor(ctx: IOContext, options?: InstanceOptions) {
super(ctx, {
...options,
headers: {
...options?.headers,
VtexIdclientAutCookie: ctx.storeUserAuthToken,
},
})
}
}
誤った例
export class OmsClient extends JanusClient {
constructor(ctx: IOContext, options?: InstanceOptions) {
super(ctx, {
...options,
headers: {
...options?.headers,
VtexIdclientAutCookie: ctx.authToken,
},
})
}
}
制約:アプリトークンは、ユーザーに紐付かないアプリレベルの処理に限って使用する
リクエストが真にアプリスコープであり、現在の購入者や管理者のアイデンティティに処理を委ねるべきでない場合に限り、ctx.authToken を使用してください。
重要な理由
アプリトークンには、アプリのマニフェストで宣言された権限が付与されています。ユーザーが開始した処理にこれを使用すると、プラットフォームが想定する、より限定的な購入者または管理者の権限モデルを迂回するおそれがあります。
検出方法
リクエストが管理者ページ、ストアフロントでの操作、またはその他のユーザー向けワークフローから発生している場合は、ctx.authToken を使う前に処理を止め、その処理がユーザースコープではなく、真にアプリレベルのものか確認してください。
正しい例
export class RatesAndBenefitsClient extends JanusClient {
constructor(ctx: IOContext, options?: InstanceOptions) {
super(ctx, {
...options,
headers: {
...options?.headers,
VtexIdclientAutCookie: ctx.authToken,
},
})
}
}
誤った例
export class AdminOrdersClient extends JanusClient {
constructor(ctx: IOContext, options?: InstanceOptions) {
super(ctx, {
...options,
headers: {
...options?.headers,
VtexIdclientAutCookie: ctx.authToken,
},
})
}
}
ログイン中のユーザーのロールを尊重すべき管理者フローでクライアントを使用する場合、これは誤りです。
制約:認証トークンを利用できる場合、VTEX IO アプリで VTEX API 認証情報をハードコードしない
VTEX IO アプリでは、ソースコードまたは通常のランタイム設定に appKey、appToken、静的な VTEX 認証情報を埋め込むのではなく、IOContext または authMethod のトークンを必ず使用してください。
重要な理由
ハードコードされた VTEX 認証情報は、ローテーションが難しく、漏えいしやすいうえ、VTEX IO クライアントがすでにサポートしているリクエストコンテキストモデルを迂回します。
検出方法
通常の IO アプリインテグレーション内で X-VTEX-API-AppKey、X-VTEX-API-AppToken、生の VTEX API 認証情報、または永続的な VTEX 認証情報を保持する環境変数を見つけた場合は、処理を止め、文書化された例外がない限り、適切な認証トークンのフローに置き換えてください。
正しい例
await ctx.clients.catalog.getSkuById(id, {
authMethod: 'ADMIN_TOKEN',
})
誤った例
await fetch(`https://${ctx.vtex.account}.myvtex.com/api/catalog/pvt/stockkeepingunit/${id}`, {
headers: {
'X-VTEX-API-AppKey': process.env.VTEX_APP_KEY!,
'X-VTEX-API-AppToken': process.env.VTEX_APP_TOKEN!,
},
})
推奨パターン
リクエスト元のコンテキストを起点に、そのリクエスト元に対応するトークンのアイデンティティを選び、クライアント層内でトークンを伝播させてください。
最小限の選択ガイド:
storefront request -> STORE_TOKEN / ctx.storeUserAuthToken
admin request -> ADMIN_TOKEN / ctx.adminUserAuthToken
background app work -> AUTH_TOKEN / ctx.authToken
クライアントが authMethod をサポートしている場合は、トークンを明示的に渡してください:
await ctx.clients.orders.listOrders({
authMethod: 'ADMIN_TOKEN',
})
await ctx.clients.orders.listOrders({
authMethod: 'STORE_TOKEN',
})
または、一致するトークンをカスタム VTEX クライアントに注入してください:
import type { IOContext, InstanceOptions } from '@vtex/api'
import { JanusClient } from '@vtex/api'
export class OmsClient extends JanusClient {
constructor(ctx: IOContext, options?: InstanceOptions) {
super(ctx, {
...options,
headers: {
...options?.headers,
VtexIdclientAutCookie: ctx.adminUserAuthToken,
},
})
}
}
判断はリクエスト境界に近いところで行い、その後のハンドラーやサービスには、適切に設定されたクライアントを利用させてください。複数の場所で場当たり的にトークンを選択させないようにします。
よくある失敗パターン
- 購入者または管理者ユーザーが処理を開始した場合でも、すべての VTEX リクエストで
ctx.authTokenをデフォルトとして使用する。 - 管理者ページで
ctx.authTokenを使用し、現在の管理者ユーザーの License Manager ロールコンテキストを誤って迂回する。 - 購入者の権限で制限されるべきストアフロントのフローで
ctx.authTokenを使用する。 IOContextの認証トークンを使用せず、IO アプリにappKeyとappTokenをハードコードする。- あるクライアントメソッドでは正しいトークンを選んでも、関連する呼び出し全体で同じアイデンティティを一貫して適用し忘れる。
- トークンの選択とポリシーのモデル化を混同し、同じ判断として扱う。
ctx.authToken、ctx.storeUserAuthToken、またはctx.adminUserAuthTokenを平文でログに記録する、あるいは必要のない下流サービスに生のトークンを転送する。
レビューチェックリスト
- 各 VTEX 統合で、適切なリクエスターの識別情報(購入者、Admin ユーザー、またはアプリ)が使用されていますか?
- ユーザーが実際に操作を行う場合、
ctx.storeUserAuthTokenとctx.adminUserAuthTokenが優先されていますか? -
ctx.authTokenは、現在のユーザーに関連付けられていないアプリレベルの操作にのみ使用されていますか? - 通常の IO アプリ統合に、ハードコードされた VTEX 認証情報が含まれていませんか?
- トークンの引き継ぎは、ハンドラーに散在させるのではなく、クライアント層に集約するか、
authMethodを明示的に使用していますか?
関連スキル
vtex-io-auth-and-policies- 主な判断事項が、選択した識別情報に付与すべき権限とポリシーである場合に使用します
参考資料
- 認証トークンを使用したアプリ認証 -
AUTH_TOKEN、STORE_TOKEN、ADMIN_TOKENに関する公式のトークンモデル - VTEX IO クライアントの使用 - トークンの選択を補完するクライアントの使用パターン
- ポリシー - アプリトークンの権限と manifest で宣言されたポリシーの関連性