OAuthスコープ一覧と利用可否

oauth scope api permission liff

このガイドについて
レシートローラーのOAuth APIで指定できるすべてのスコープと、それぞれのスコープがどの種類のアプリに付与されるかを一覧でまとめています。OAuthアプリを登録する前、または認可URLを組み立てる前にご確認ください。

OAuthスコープ一覧と利用可否

レシートローラーのAPIは、OAuth 2.0のスコープによってアクセスできるリソースが制御されています。アプリを登録する際と、ユーザーを認可画面へ誘導する際に、必要なスコープだけを最小限で指定してください。スコープは半角スペース区切りで複数指定できます。

スコープの分類

スコープは目的別に4つのカテゴリに分かれています。

Store系 — 店舗・組織のビジネスデータ（商品・受注・在庫・クーポンなど）
CRM系 — 顧客プロファイル・セグメント情報
SNS / Analytics系 — SNS投稿・オーディエンス・分析データ
User系（コンシューマー） — 個人ユーザーのレシート・支出・お気に入り店舗など

後述のとおり、User系スコープは原則として第一者アプリと承認済みパートナーにのみ付与される厳格なスコープです。

Store系スコープ

店舗オーナー・組織管理者がOAuthで自社の店舗データを操作するためのスコープです。外部パートナーアプリにも付与可能ですが、店舗側がOAuth同意画面で許可する必要があります。

スコープ	付与される権限
`store.products.read`	商品・在庫情報の参照
`store.products.write`	商品の登録・更新
`store.orders.read`	受注データの参照
`store.orders.write`	受注ステータスの更新
`store.customers.read`	顧客データの参照
`store.coupons.read`	クーポンデータの参照
`store.coupons.write`	クーポンの作成・更新
`store.inventory.read`	倉庫・在庫データの参照
`store.flyers.read`	店舗チラシの参照
`store.flyers.write`	店舗チラシの作成・更新・公開

CRM系スコープ

スコープ	付与される権限
`crm.profiles.read`	CRM顧客プロファイルの参照
`crm.segments.read`	CRMセグメント・ランクの参照

SNS / Analytics系スコープ

スコープ	付与される権限
`sns.content.read`	SNS投稿データの参照
`sns.audience.read`	SNSオーディエンスデータの参照
`analytics.read`	分析スナップショットの参照

User系（コンシューマー）スコープ

重要：User系スコープは事前審査が必要です
これらのスコープは個人ユーザーのレシート・支出・お気に入り店舗など、コンシューマー個人データにアクセスするものです。レシートローラー第一者アプリと、明示的に承認されたパートナーアプリにのみ付与されます。
未審査のアプリで user.* スコープを指定して認可URLを呼び出すと、app_not_approved エラーが返ります。

スコープ	付与される権限
`user.profile.read`	ユーザー基本情報の参照
`user.profile.write`	ユーザー基本情報の更新
`user.receipts.read`	ユーザーが受け取ったレシートの参照
`user.spending.read`	月次支出サマリーの参照
`user.spending.write`	支出・予算データの更新
`user.coupons.read`	お気に入り店舗のクーポン参照
`user.favorites.read`	お気に入り店舗一覧の参照
`user.favorites.write`	お気に入り店舗の追加・削除

重要な制約

1. User系スコープは事前審査制

OAuthアプリ登録時に user.* スコープを含めると、アプリの UserScopeStatus が pending（審査待ち）になります。レシートローラー運営チームの審査で approved になるまで、認可フローで user.* スコープを指定するとエラーが返ります。

外部の店舗・パートナーが「自社のLIFFアプリやモバイルアプリで、ユーザーが受け取った全レシートを表示したい」というユースケースは、原則としてこの審査の対象です。お気軽にサポートまでご相談ください。

2. Store系とUser系は同一認可フローに混ぜられない

1つの認可リクエストで store.orders.read と user.receipts.read を同時に指定することはできません。これらはアクター（店舗 vs. ユーザー）が異なるため、認可サーバーが拒否します。

両方のデータを扱うサービスを作る場合は、OAuthアプリを2つ登録し、それぞれ別々の認可フローでトークンを取得してください。

3. 最小権限の原則

ユーザー（または店舗オーナー）の信頼を得るためにも、本当に必要なスコープだけを指定してください。「念のため write も入れておく」「使わないけど他のスコープも申請する」のはおすすめしません。

ユースケース別の推奨スコープ

やりたいこと	必要なスコープ	備考
店舗の在庫・受注を外部システムから同期する	`store.products.read` `store.products.write` `store.orders.read`	店舗オーナーの同意で取得可
自社の店舗チラシを社内CMSから一括投稿する	`store.flyers.write`	店舗オーナーの同意で取得可
マーケ部門にCRMセグメントを連携する	`crm.profiles.read` `crm.segments.read`	店舗オーナーの同意で取得可
自社モバイルアプリでユーザーの全レシートを表示する	`user.receipts.read`	事前審査が必要
家計簿アプリで月次支出を可視化する	`user.spending.read` `user.receipts.read`	事前審査が必要
LIFFで他社の店舗データを取得したい	—	不可（自社のStore系スコープのみ取得可）

LIFF / LINE Mini App からの利用について

LIFFアプリ（LINE Mini App）からレシートローラーのAPIを呼び出す場合も、標準のOAuth 2.0 Authorization Codeフローを使います。

LINE IDトークンの直接交換は提供していません

「LINE IDトークン → レシートローラーのアクセストークン」を直接交換するエンドポイントは現時点で提供していません。LIFFアプリも他のWebアプリと同様に、ユーザーをレシートローラーの認可画面に誘導する必要があります。

LIFFでの実装パターン

LIFFアプリ起動後、liff.init() でLIFFを初期化します
レシートローラーAPIが必要なタイミングで、liff.openWindow() または通常のリンクで /oauth/authorize へ誘導します
ユーザーがレシートローラーの認可画面で許可すると、redirect_uri に認可コードが返ります
認可コードを POST /api/v1/auth/token（grantType: authorization_code）でアクセストークンに交換します
取得したトークンを Authorization: Bearer ヘッダーで API に付与してリクエストします

User系スコープを使う場合の注意

LIFFアプリで user.* スコープを指定する場合も、上記の事前審査が必要です。「LINEで認証しているからレシートローラーのユーザー認証は省略できる」という設計にはなっていません。これはセキュリティとユーザー同意の透明性のための設計です。