什麼是應用程式登錄

應用程式登錄（以下「應用程式登錄」）是為了將外部系統連接到 ReceiptRoller API，作為 OAuth 用戶端登錄資訊的手續。透過登錄，ReceiptRoller 可識別「請求從何處來」，變得只回傳被許可範圍的資料。

為什麼需要應用程式登錄

ReceiptRoller API 以 OAuth 2.0 保護。OAuth 2.0 中，以呼叫 API 的用戶端（外部系統）事先登錄身分為前提。沒登錄無法突然發行存取權杖。

透過進行應用程式登錄，實現以下事項。

• 身分證明 — 以用戶端 ID、密鑰唯一識別請求的發送來源
• 授權範圍的宣言 — 這個應用程式要求哪些權限範圍事先登錄
• 重新導向對象的固定 — 限定回傳授權碼的 URL，防止 phishing
• 稽核、取消 — 有問題時以應用程式為單位取消存取

登錄後發行的東西

登錄應用程式後，會發行、確定以下的憑證、設定值。

應用程式的生命週期

應用程式從登錄到運用、廢止以下列這樣的流程管理。

1. 登錄 — 設定應用程式名、重新導向 URI、要求權限範圍
2. 審查（僅含 user.* 的情況） — 以營運團隊的審查轉為 approved
3. 開發 — 以測試用的重新導向 URI（http://localhost 等）確認運作
4. 正式運用 — 追加正式的重新導向 URI 並切換
5. 密鑰輪替 — 定期地或外洩時重新產生密鑰
6. 廢止 — 利用結束時無效化應用程式（既有權杖也無效）

1 商業帳戶可登錄多個應用程式

1 個商業帳戶可登錄多個應用程式。以下這樣的分法很一般。

• 依環境 — 開發用 / 預備用 / 正式用 分成不同應用程式，獨立管理重新導向 URI 或權限
• 依用途 — 「自家 EC 串接」「BI 工具串接」「行動應用程式」等，不同使用案例分成不同應用程式
• 依權限 — 讀取專用應用程式（store.orders.read）與寫入應用程式（store.orders.write）分開，以最小權限運用
• 依用戶端形態 — 在伺服器端運作的應用程式，與向行動/SPA 公開的應用程式分別登錄

Store 系應用程式與 User 系應用程式

應用程式依要求的權限範圍，大致分成 2 種類型。因為兩者無法混在 1 個應用程式，兩者處理的情況分別登錄。

詳情請參閱OAuth 權限範圍一覽與利用可否。

應用程式的公開範圍

在 ReceiptRoller 的開發者入口登錄的應用程式，預設是只能在登錄的商業帳戶內使用的私有應用程式。「他社的店鋪業主授權而使用這個應用程式」這樣的公開應用程式的提供，與營運團隊另行洽商後調整。

• 私有應用程式 — 自家的店鋪、自家的員工授權的應用程式。公司內工具、自家 EC 串接等
• 公開應用程式（需洽商） — 他社的店鋪業主、他社的使用者授權的應用程式。作為 SaaS 向他店鋪提供的情況等

應用程式登錄需要的前提

• 持有 ReceiptRoller 的店鋪帳戶
• 商業帳戶的方案為Starter 方案以上（免費方案不會顯示應用程式登錄畫面）
• 賦與業主或開發者角色

不滿足前提的情況請先參閱利用開始為止的流程。

本章的構成

本章中，關於應用程式登錄的各論以下列順序解說。

• 新增建立應用程式 — 登錄畫面的操作與輸入項目的解說
• 重新導向 URL 的設定 — 開發、正式環境別的設定與常見錯誤
• 利用目的、串接對象（POS／EC／分析等）的申告 — 登錄時的中繼資訊輸入
• User 系權限範圍的審查申請 — 使用 user.* 時的追加流程

相關指南

• 利用開始為止的流程（店鋪登錄 → Starter 方案 → 應用程式登錄）
• OAuth 權限範圍一覽與利用可否
• API 驗證指南（OAuth 2.0 授權碼流程）
• 返回開發者向幫助目次