先問「誰在執行」，不要先問哪一種最方便
API 金鑰、OAuth 權杖與服務帳號都能讓程式通過驗證，但它們表達的身分並不相同。API 金鑰通常識別應用程式或專案，OAuth 識別使用者授權後的委派關係，服務帳號則代表一個非人類的工作負載身分。如果只因為 API 金鑰最容易產生就直接採用，後續常會遇到權限過大、無法判斷實際操作者，以及離職或系統下線時難以撤銷等問題。
設計整合時，我們會先拆成三個問題：呼叫者是瀏覽器、後端服務、排程工作，還是現場設備；它是在使用自己的權限，還是代表某位使用者；最後，資源擁有者是否需要明確同意。當系統代表使用者讀取其雲端檔案、行事曆或 CRM 資料時，通常應採 OAuth。當後端批次程式固定寫入資料倉儲，則較適合具有明確角色與稽核紀錄的服務帳號。若只是呼叫低風險、可嚴格限制來源與額度的 API，API 金鑰才可能是合理選擇。
三種機制各自應停在哪一條界線
API 金鑰適合回答「是哪一個應用程式在呼叫」，卻不適合證明「是哪一位使用者批准了操作」。它可以用於地圖、翻譯、模型推論或內部唯讀端點等情境，但前提是供應商支援來源限制、API 範圍限制、額度控管與快速輪替。金鑰不應放進前端程式、行動 App 安裝包、公開試算表或原始碼；任何會交付給終端使用者的程式，都應視為無法保密。
OAuth 的價值在於委派，而不只是登入。授權範圍應對應實際功能，避免為了省事一次要求完整信箱、整個雲端硬碟或全部 CRM 權限。服務帳號則適用於服務對服務、CI/CD、排程與資料管線，但不能成為多人共用的萬用管理員。實務上的判斷原則包括：
- 使用者代表性：操作必須歸屬到個人，或需要個人同意時，使用 OAuth，並保存使用者、租戶與授權範圍的對應關係。
- 工作負載代表性：無人值守的後端工作應使用服務帳號或雲端工作負載身分，為每個系統與環境分開建立。
- 應用程式識別：只需辨認呼叫來源，且資料風險有限時，可使用受限制的 API 金鑰。
- 無法安全保存秘密：瀏覽器、桌面程式與行動 App 應採 OAuth Authorization Code 搭配 PKCE，不能把 client secret 當成真正的秘密。
- 跨雲或跨組織整合：優先評估短效權杖與身分聯盟，避免長期保存可直接登入的金鑰檔。
真正的安全差異在生命週期管理
憑證建立只是起點。每一個金鑰、OAuth client 與服務帳號都應有負責人、用途、環境、權限範圍、建立日期與輪替方式。正式、測試與開發環境必須分離；同一組憑證不應同時存在於工程師筆電、CI 平台與正式伺服器。秘密應放入雲端 Secret Manager、Vault 或部署平台的加密環境變數，應用程式在執行時取得，而不是寫入設定檔後提交版本控制。
API 金鑰應具備到期或定期輪替流程。輪替時最好支援新舊金鑰短暫並存，先部署新金鑰、確認流量切換，再撤銷舊金鑰，避免直接替換造成停機。OAuth access token 應維持短效，refresh token 必須加密保存，並處理撤銷、授權範圍改變、使用者停權及重新同意。不要把 refresh token 當成永久密碼，也不要在日誌、錯誤追蹤或客服畫面輸出完整權杖。
服務帳號應採最小權限角色，並盡量使用 AWS IAM Role、GCP Workload Identity Federation 或相同概念的短效身分機制。若平台只能使用私鑰檔，應限制下載權限、記錄每次存取並建立可演練的輪替程序。每個服務帳號只服務一個明確工作負載，能讓稽核紀錄回答是哪個系統、在哪個環境、對哪個資源執行了操作。
從共用憑證遷移，並為外洩預先設計
常見技術債是所有整合共用一把金鑰，甚至共用管理員帳號。遷移時不要先撤銷舊憑證，而應盤點實際流量、建立分離的新身分、配置最小權限，再逐一切換呼叫端。可以透過憑證識別碼、來源系統、環境與 API 路徑建立可搜尋的稽核資料，但日誌只記錄雜湊或末端識別資訊，不記錄完整秘密。確認舊憑證已無流量後再撤銷，並補上自動化到期提醒與未使用憑證清理。
外洩處理也應事先寫進設計：如何立即撤銷、如何發出替代憑證、哪些服務需要重新部署、如何判斷受影響的資料範圍，以及如何保留調查證據。選擇認證方式的核心不是哪一種名稱更安全，而是身分是否清楚、權限是否足夠小、秘密是否能被妥善保存，以及撤銷是否真的可執行。跨 LINE、ERP、CRM、雲端與 IoT 的整合尤其需要一致的身分與憑證治理；必要時，可由整合團隊協助把這些界線落實成架構、部署流程與稽核規則。