先釐清四個不同問題
傳輸、認證、授權與資料歸屬
TLS 保護資料傳輸，OAuth 2.0 定義授權框架，OpenID Connect 可在其上提供身分認證。JWT 則是權杖格式之一；常見簽章型 JWT 的內容可被讀取，不適合放密碼、完整個資或商業秘密。選了某個協定，不代表其他層的工作已經完成。
企業可先畫出使用者、身分提供者、API 閘道與後端服務的信任邊界。每個請求都要回答：誰發出、要做什麼、操作哪筆資料、屬於哪家公司。這四個問題對應的檢查不一定在同一個元件，必須明確分工。
OAuth 流程怎麼選？
採用適合客戶端的授權方式
互動式行動或網頁應用可評估授權碼流程搭配 PKCE，並嚴格核對重新導向位置。RFC 9700 更新了 OAuth 安全建議，提醒團隊不要沿用已不合適的舊流程。實際實作仍應使用成熟函式庫與身分平台，避免自行拼湊協定。
純服務對服務呼叫與使用者登入不同，需要工作負載身分及最小權限，不宜共用一組長期管理員憑證。API 閘道還要限制請求大小、速率與允許的方法，但這些控制不能取代後端業務規則，也不能單靠限流解決撞庫與帳號接管。
短期 JWT 的完整生命週期
驗證簽章之外，也驗證用途
接收權杖時應核對可信任簽發者、預期受眾、有效期限與允許的演算法，並管理簽章金鑰輪替。不能接受權杖自行指定任意驗證方式。權杖有效期應依風險與使用情境設定，不存在適用所有企業的固定分鐘數。
短效 access token 降低外洩後的可用時間，卻仍需要安全的 refresh token 管理與撤銷策略。帳號停用、密碼變更或權限異動後，既有工作階段何時失效必須可預期。若採無狀態驗證，也要明確說明立即撤銷的設計與成本。
BOLA 為什麼會發生？
合法使用者，也可能讀到別人的資料
假設使用者有查詢訂單的功能權限，仍不代表可查詢任意訂單。後端必須依可信任的使用者與租戶關聯，驗證資料歸屬，再決定可讀、可改或可匯出。把流水號改成 UUID 只能降低猜測便利性，不能補上缺失的授權判斷。
多租戶系統尤其不能直接信任前端傳入的公司代碼。批次下載、報表匯出與巢狀資源也要逐一檢查，避免單筆查詢安全，批次接口卻略過同一套規則。建議把權限規則集中管理，但讓服務端在資料操作點確實執行。
驗收必須包含拒絕情境
建立角色與資料的交叉測試矩陣
用兩個租戶、不同角色及已停用帳號建立測試資料，逐一驗證查詢、修改、刪除與匯出。成功情境確認功能可用，拒絕情境確認沒有資料洩漏。測試回應內容、檔案下載連結與快取，也要確認錯誤訊息不透露不應知道的資源細節。
此外要測試過期權杖、錯誤受眾、金鑰輪替與高頻登入失敗。日誌可記錄請求識別碼、角色與授權結果，但避免完整保存權杖。對合法操作的誤擋要能追查原因，才能在安全與使用體驗間持續校正。
從既有 API 開始改善
先處理高價值資料與寫入操作
可以先盤點涉及客戶資料、價格、付款與權限異動的端點，再補上物件授權測試。對已上線的系統，逐步統一驗證中介層與錯誤回應，並檢查舊版 API 是否仍可繞過新控制。端點退役同樣需要呼叫量觀察與通知。
架構評估應交付權限矩陣、權杖生命週期與測試案例，而不只畫一個 API Gateway 方塊。當企業能說清楚誰可以在什麼條件下操作哪筆資料，OAuth 與 JWT 才能真正成為可驗證的安全設計。
常見問題
用了 JWT，資料就不會被看見嗎？
不一定。常見簽章型 JWT 不是加密容器，內容可被解碼閱讀。敏感資料不應放入權杖，傳輸仍需要 TLS。
API 閘道可以完全處理 BOLA 嗎？
通常不行。閘道可驗證身分與粗粒度權限，但訂單歸屬、租戶邊界及特定操作條件仍需由了解資料的服務端確認。
短期權杖會讓使用者一直重新登入嗎？
不一定。可設計安全的續期流程，但必須同時處理裝置遺失、權限變動與 refresh token 撤銷，不能只追求無感登入。