API Token 驗證方式設計

後端常見的工作是在對應的產品上出各種 API 提供串接，串接方有可能是 瀏覽器、手機 ，另外在微服務 (MicroService) 興起的同時 Server 與 Server 對接 也是常見的溝通方式。

各服務使用 API 溝通的同時，除非是公開的 API 不需要認證，不然一般的 API 可能都需要經過 認證 或者是 授權 的行為來取得使用的允許權。

原文請看 ： API Token 驗證方式設計

以下簡介我對於常見的 API Token 串接的設計特性簡介以及優缺分析，提供大家能夠在設計上快速釐清:

• 自行設計 Token
• JWT Token
• OAuth 2.0 驗證

自行設計 Token

• 適用情境：自家 Server 服務對接，亦即呼叫者都為自家服務或者 Server
• 優點:
  • 實作簡單
• 缺點:
  • 必須 Hardcode 設定
  • 更新 Token 的話 Client 和 Server 都要手動更新
• 備註：
  • 如果提供多組 Client 都可以存取，需要把 Token 分開處理。 當需要把某一組 Token 設定為失效的同時，可以讓其他組的 Token 可以持續生效

JWT Token

• 適用情境：
  • 需要針對個人身份辨識做發放者
  • MicroService Server or Client Side 服務串接
  • 單次認證行為使用 (e.g. Email 驗證)
• 優點:
  • 根據單一身份或行為進行客製發放
  • 需要夾帶欲使用的(非敏感)資料
  • 設定 Expired time 來降低 Token 流失後作用的風險
• 缺點:
  • 發出去無法收回，只能等 Token 失效，或者在 Server 端建立黑名單機制做 Block 阻擋
  • 更新 Token 的話 Client 和 Server 都要手動更新
• 備註：
  • 需注意編碼長度的問題，是否會超出 JS cookie 或者 Local Storage 的儲存長度
  • 與 CSRF 攻擊預防無關，只要 JS 可以 Work，Token 就有機會被竊取而造成攻擊
  • 可以看我先前深層筆墨 JWT 的介紹

OAuth 2.0 驗證

• 優點:

  • 相較於 自設計 Token 對接 以及 JWT Token 對接提供更大管理上的彈性，
  • 可以設定作用域以及存取資料範圍

• 缺點:

  • 流程繁瑣，嚴謹

• 備註： 不同種的 Grant 有不同的適用情境，下列簡述:

OAuth Grant 簡介

❖ Authorization Code Grant

• 適用情境：
  • 可保存 client credentials， e.g. client secret, refresh token
  • 不被他人看到的第三方 APP，e.g. Server-side Web APP
• 各家 OAuth2 provider 幾乎都會實作，e.g. Google, FB, Amazon

❖ Implicit Grant

• 適用情境:
  • 無法保存 Client Secret 會被他人看到的第三方 APP，e.g. Mobile/Desktop APP, JavaScript Web APP

❖ Client Credentials Grant

• 適用情境：
  • OAuth2 Client 直接向 Authorization Server 取得授權的情境。
  • OAuth2 Client 自己就是 Resource Owner。

❖ Resource Owner Password Credentials Grant

• 此授權流程需要使用者輸入帳密，所以一般不開放給外部開發者的 OAuth2 Client 使用，避免使用者帳密被第三方紀錄的風險。
• 適用情境：
  • 適用於自家開發的 APP，e.g. Mobile/Desktop APP