API Consumer

來用API的人是誰？

來到了第四天，既然已經完成了中間層 Kong API Gateway的設計，是時候來思考，要如何辨識API 的使用者了。如果讀者曾經寫過需要登入 的Web Site，不妨與筆者一起先來思考一下，撰寫這類型網站的一些特點是不是如下：

1. 認證授權：一定會辨識使用者，通常會有一個登入頁面要求敲入帳號與密碼，可能透過session 或是前後端分離採取token的方式辨識。
2. 狀態紀錄：常見透過後端進行狀態紀錄，例如登入後將購物資料放入購物車，當然前端紀錄亦常見。一定要有瀏覽器
3. Post/Get：基本上大多網站預設都使用Post 與Get 兩種Http 動詞方法，預設其他方法不開放。

筆者在企業中，每當提到API 或是Web Service要注意的一些事項時，許多人常常暈頭轉向陷入原有Web Site的設計思維而感到困惑，舉幾個常被問的例子如下：

1. 辨識來源使用者？API 又沒有登入頁面，怎麼知道？鎖定IP嗎？Session記在哪裡？沒有瀏覽器了耶。
2. API不就是把Query 資料庫的條件，請來用的使用者填入？所以如果要取得A廠商訂單，不就在url後方請廠商自己填入廠商id即可？(order?id=1)。
3. 一隻API給多個廠商用會有風險？那不然複製很多個一樣的API，每一個站台都給不同廠商使用，而且都對鎖防火牆或是牽專線，這樣就可以透過站台與IP來辨識來使用的對方了。

上面的例子是真實發生的，也的確有企業在這樣的設計下活下來。只要能夠有效管理，當然都是種作法，不過筆者比較囉嗦，所以喜歡優雅的且有效的設計與管理。因此這個系列文將會好好的與讀者一起思考，怎麼做在實務上才是比較好的做法。

雖然這些做法在企業內部曾經「運作正常」，甚至支撐了多年業務，但若用 OWASP API Security Top 10 來檢視，會發現它們正好踩中多個常見 API 弱點。

• API1:2023 – Broken Object Level Authorization
  透過 order?id=1 讓使用者自行輸入 ID，若缺乏嚴格授權檢查，等於把「別人家的訂單」送上門。

• API2:2023 – Broken Authentication
  靠 IP 鎖定或防火牆白名單來辨識客戶，忽略了使用者層級的身分驗證，一旦 IP 被濫用，系統無法分辨真正的呼叫者。

• API8:2023 – Security Misconfiguration
  複製多份 API 給不同廠商、各自配專線，雖然直觀，但帶來維護成本與一致性風險，一旦設定錯誤，可能讓資料暴露。

這些案例的共通點，是「沒有標準化的 API 身分與授權管理」，導致每個 API 實作都要重新解題，安全與維護的成本居高不下。

OWASP API Security Top 10 是由 OWASP 制定的十大常見 API 安全風險清單，涵蓋從身分驗證、授權缺陷到錯誤設定等問題，協助開發者與企業識別並優先修補 API 的安全弱點，降低資料外洩與濫用風險。
參考來源：OWASP Top 10 API Security Risks – 2023

Kong API Consumer

為了在單一 API Gateway 中統一管理使用者身分，Kong API Gateway的 Consumer 提供了可擴展多種驗證方式供使用。Consumer 是 Kong 內部對「API 使用者」的抽象化表示，不論他是第三方廠商、行動 App、內部系統，都能夠精準辨識。

圖 4-1

Day 3的時候有提及到Route與Service的觀念，這張圖4-1 則精準地描繪出，在每一個Request的時候，Kong會從Consumer的角度先判斷呼叫方。接下來才會進入到Route以及後續的Service。今天就來透過最簡單的API Key，來做來源認證辨識示範。

首先先關注到示範專案中ironman2025\case_2_consumer_apikey\1.Kong_declarative\kong.yml這個檔案，與case1差異簡略顯示如下：

    // ...上略...
    - name: file-log
      config:
        path: /tmp/kong-file.log
    - name: key-auth
      config:
        key_names:
        - apikey
        hide_credentials: false
consumers:
- username: user1@user.com
  custom_id: user1
  keyauth_credentials:
  - key: user1-api-key

上面這段新增的設定，是用於 Kong API Gateway 的 key-auth plugin，目的是為 API 請求加入 API 金鑰驗證機制。

• name: key-auth 表示啟用 key-auth plugin。
  • config
    • key_names 設定為 apikey，代表 API 金鑰會從請求的 apikey 參數中取得。
    • hide_credentials: false 則表示在請求轉發給後端服務時，API 金鑰不會被隱藏，依然會包含在請求中。

接下來的 consumers 區塊定義了 API 使用者。這裡有一個使用者，簡述如下：

• username： user1@user.com。
• custom_id： user1。
• keyauth_credentials：
  • API 金鑰：user1-api-key。

實驗

好，來驗證Kong 是不是有把未經認證的API Request 阻擋起來，首先先在示範專案ironman2025\case_2_consumer_apikey路徑下執行 docker compose up -d，應該會看到圖4-1的結果。

圖4-2 docker compose 啟動成功

服務正常啟動後，開啟瀏覽器來驗證，url:http://localhost:8000/my-service/weatherforecast。

圖4-3 401錯誤

圖4-3很清楚的表示，原本在Case 可以成功呼叫的API，由於Kong API Gateway 已經將key-auth認證plugin 設定在route上。因此需要提供apikey經過認證後，才可以合法的呼叫。

接下來開啟postman來接續實驗，除了前面提到url:http://localhost:8000/my-service/weatherforecast外，請在headers加入apikey=user1-api-key，並按下Send。

圖4-4 成功的Postman

太棒了，成功！

這表示當 API 請求帶有 apikey=user1-api-key 時，Kong 會認定這是 user1 的合法請求。這初步完成了在Kong API Gateway 上面做到須先經過認證，才能存取後端API安全性設定。

在這種設計下，營運單位就可以透過Kong 上面Consumer 的設定，來辨識存取來源。

今天的任務也順利完成，讓工程師明天繼續面臨新的挑戰。