API 的應用，帶來了十足的便利、彈性與靈活性。當所有人都可以存取此 API 應用時，進而可能衍生出各種風險、攻擊與安全危機，此時 API 的安全機制就十分重要。如何控管並開放 API 給對的使用者，並做到完善的 API 存取認證與授權?這裡將對於 F5 所提供的 API 的安全認證機制做說明。
單一入口 支援多種完備的認證機制
API 應用使用了幾個方面的認證技術，例如 Oauth2、OpenID、JWT 等等，以 Oauth2 為例，Oauth2 認證的流程如下：
Oauth2 的實際效果是，資源所有者通過該流程賦予協力廠商應用訪問資源服務器的有限許可權。該模式被廣泛應用在社交網路運用，來提供使用者認證登入服務，比如通過使用臉書帳號登入 Line 等其他社交媒體，Line 可以獲取到用戶在臉書上的頭像等相關資訊。
在一個通用型的 API 系統中，API 調用者作為協力廠商伺服器調用 API 伺服器，API 的使用者可以通過管理門戶得到一個 Token，使用這個 Token 發起 API 請求到 API 閘道，API閘道將識別該認證資訊，並將請求轉發到適當的 API 伺服器組，此時 API 系統各元件在認證關係中可以理解為：
API 閘道 + API 服務器 = 資源服務器
Oauth2 的 RFC 本身自訂了認證流程中的各個角色，對於 Token 的認證使用 RFC7662 進行定義，該 RFC 提出是通過在請求中夾 Token，資原始伺服器請求認證伺服器獲取到Token 的 SCOPE，該 SCOPE 可以是自訂的任何值，以下為典型的 Oauth2 請求與回應範例：
請求如下：
回應如下：
上述只是範例展示，而不是強制要求。
自建 API 服務的過程中有兩種認證路線：
– 普通 Bearer Token + SCOPE Valid（要看 Oauth2 認證伺服器是否支援）
– 基於 Json Web Token（JWT）的 Token
兩種 Token 的區別在於，Bearer Token 本身並不包含太多的資訊，需要將 Token 轉發到 Oauth2 伺服器進行驗證，而 JWT 在 Token 本身已經包含了足夠的資訊，可以在資原始伺服器上直接驗證，兩者在技術上無高下之分，只是適用的場景不同。
Bearer Token 可以結合 Scope 對請求內容+Token 發給認證伺服器，此時 API 閘道需要 Cache 認證結果，避免業務壓力直接擴散到認證伺服器，對 Token 的撤銷時效性較快，API KEY 本身和 API 可以採用松耦合關係，但是對 Oauth2 認證伺服器的要求比較高。
JWT Token 無需轉發給認證伺服器，但是需要消耗更多的 CPU 資源做 Token 的解密工作，另外對 Token 撤銷需要更新伺服器側的 Key 配置或 Token 配置，時效性略低，但是開發起來可以拋棄 Oauth2 的設計考慮，只單純考慮如何 update API 閘道的加密 Key（非 API key）列表即可。
實現 API 的混合認證 降低開發成本滿足客戶需求
F5 APM 模組支持上述 JWT 認證以及 Beare Token 的 Scope valid，同時可對 Per API 選擇各自的認證方式，也支援同一個 API 請求，同時使用 HTTP 基礎認證以及 Oauth2 認證，整體認證部署如下：
Per API 認證方式，F5 支援在同一入口下，對不同的 API 可以採用不同的認證方法。
如上圖，可以實現對特定 API 入口：POST /dev 執行認證檢查，對其他 API 入口則不做任何認證。
混合認證方式，對於同一個 API 入口，可以自動識別認證種類，實現對 API 的混合認證。
在上圖中，對某個 API 的請求，如包含 HTTP Basic 的相關報文頭，則識別為 HTTP Basic 認證類型請求，將用戶名和密碼提交給 LDAP 伺服器進行認證，如包含 Oauth Bearer 報文頭，則執行 Oauth 相關的認證步驟。
F5 作為資源服務器的前端，支援基於 OpenID 協定的 JWK 自動獲取並且自動更新到相關 Token 配置，實現全自動 JWT KEY 撤銷修改。根據 Token 欄位校驗 Token 合法性，撤銷 Token 可以更細細微性執行，比如撤銷特定類別的 Issuer/Audience，撤銷指定某個 Token，對比開源的解決方案，細微性更精確，無需撤銷某 key 下所有 Token 對 Key 管理有很好的便利性。
在 API 安全管理系統中，F5 可以作為所有資源服務器的統一安全認證代理，具備完整的認證流程，支援多種認證方法以及靈活的 Token/Key 撤銷機制，可以滿足不同客戶的多種 API 認證需求，提供領先的 API 認證功能並且降低整體開發成本。