Subscription Key (APIM) 101 — บัตรสมาชิกที่ประตูรั้ว

คู่กับ API Key 101 — ถ้า API Key คือ “บัตรพนักงาน” ที่ backend ตรวจเองที่ประตูห้อง Subscription Key คือ “บัตรสมาชิก” ที่ยามตรวจตั้งแต่ประตูรั้ว (APIM gateway) — request ที่ไม่มีบัตรถูกปัดตกก่อนถึงตัวบ้านด้วยซ้ำ · เป็นเครื่องมือขา server/partner → APIM เท่านั้น (ภาพระบบข้อ 6 — มติ 18)

TL;DR — อ่าน 30 วิ

• Subscription Key = key ที่ Azure APIM ออกให้ต่อ “ผู้สมัครใช้ API” (subscription) — ผู้เรียกแนบ header Ocp-Apim-Subscription-Key มากับทุก request
• ตรวจที่ gateway ก่อนถึง backend — ต่างจาก API Key ที่ backend ตรวจเอง
• จุดแข็งจริงไม่ใช่ “ความลับ” แต่คือการบริหารผู้เรียก: รู้ว่าใครเรียกเท่าไหร่ (analytics) · จำกัดโควต้า/rate ราย caller · ปิดก๊อกราย caller ได้ทันทีจาก portal โดย backend ไม่ต้องรู้เรื่อง
• มี 2 key ต่อ subscription (primary + secondary) ในตัว — rotate ได้แบบ zero-downtime
• ขา browser ของเราไม่ใช้ — เหตุผลเดียวกับ API Key (DevTools เห็น = ค่า public) และ FE ทั้ง 4 repo ไม่เคยถือ key พวกนี้อยู่แล้ว (ตรวจ 03/08)

1. ภาพที่ถูกต้อง: มันคือเครื่องมือ “บริหาร” ไม่ใช่เครื่องมือ “ป้องกัน”

sequenceDiagram
    autonumber
    participant P as Partner / Server caller
    participant APIM as APIM Gateway
    participant BE as Backend Service

    P->>APIM: request + Ocp-Apim-Subscription-Key
    APIM->>APIM: key นี้เป็นของ subscription ไหน?
    alt ไม่รู้จัก / ถูก revoke
        APIM-->>P: 401 — ไม่ถึง backend เลย
    else รู้จัก
        APIM->>APIM: เช็ค quota / rate-limit ของ subscription นี้
        alt เกินโควต้า
            APIM-->>P: 429 Too Many Requests
        else ผ่าน
            APIM->>BE: forward (backend ค่อยตรวจชั้นของตัวเอง: JWT / X-Api-Key / HMAC)
            BE-->>P: response
        end
    end

สิ่งที่ได้จากการตรวจที่ประตูรั้ว:

สิ่งที่ไม่ได้จากมัน: ไม่พิสูจน์ตัวผู้ใช้ (JWT ทำ) · ไม่กันแก้ request (HMAC/ลายเซ็นทำ) · ไม่กันอ่าน (encryption ทำ) — request ที่ผ่านรั้วมาแล้ว backend ยังต้องตรวจชั้นของตัวเองครบเหมือนเดิมทุกตัว ห้ามถือว่า “ผ่าน APIM มา = เชื่อได้”

2. Subscription Key vs API Key — ต่างกันตรงไหนกันแน่

สองตัวนี้คนสับสนกันบ่อยสุดเพราะหน้าตาเหมือนกันเป๊ะ (string ลับใน header) — จุดต่างจริงมี 3 ข้อ:

ใช้คู่กันได้และมักใช้คู่กันจริง: partner → Subscription Key ที่รั้ว (บริหาร/โควต้า) → API Key/JWT ที่บ้าน (gate จริง) — คนละชั้นคนละหน้าที่ ไม่แทนกัน

3. Dual-key rotation — ของแถมที่ดีที่สุดของ APIM

ทุก subscription มี primary + secondary key และ APIM รับทั้งคู่เสมอ ⇒ rotate โดยไม่มี downtime:

1. caller ใช้ primary อยู่                        → ระบบปกติ
2. caller สลับไปใช้ secondary                     → ยังผ่าน (APIM รับทั้งคู่)
3. regenerate primary (ค่าเก่าตายทันที)            → ไม่มีใครใช้อยู่แล้ว ไม่มีใครพัง
4. รอบถัดไปสลับกลับ: ใช้ primary ใหม่ → regen secondary

หลักคิดนี้ (มี key สำรองรับคู่ระหว่าง overlap) คือ pattern เดียวกับที่เราต้องทำเองมือถ้าใช้ API Key ฝั่ง backend — APIM ทำให้ฟรี · จดไว้เป็นตัวอย่างเวลาต้องออกแบบ rotation ของ secret ตัวอื่น (รวมถึง encryption key ของชั้น 3 ที่ใช้ kid — หลักการเดียวกัน)

4. แล้วขา browser ของเราล่ะ?

ไม่ใช้ และไม่เคยใช้ — ตรวจโค้ดจริง 03/08: FE ทั้ง 4 repo ไม่เคยถือ subscription key/API key ใดๆ และ authentication ไม่เคยพึ่งมัน:

• เหตุผลเดียวกับ API Key: browser เก็บ secret ไม่ได้ — key ใน bundle = ค่า public = การป้องกันเป็นศูนย์ แต่ภาระ rotate เต็มๆ (มติ 7)
• ขา browser ผ่าน APIM facade ด้วย cookie → resolve-session → JWT (ชั้น 1) ซึ่งผูกกับผู้ใช้จริง — ละเอียดและปลอดภัยกว่า key ระดับ app ที่ทุกคนใช้ร่วมกันคนละโลก
• ถ้าอนาคตมี partner/ระบบภายนอกมาเรียก API เรา → นั่นคือที่ของ Subscription Key: เปิด product ให้ subscribe, ได้ quota + ปิดก๊อกราย partner ฟรีจาก portal — โดยไม่แตะขา browser เลย

5. กติกาสรุป

• Subscription Key = เครื่องมือบริหารผู้เรียกที่ประตูรั้ว (quota / analytics / revoke) — ไม่ใช่เครื่องมือป้องกันเนื้อ request
• ผ่านรั้วมาแล้ว backend ตรวจชั้นตัวเองครบเหมือนเดิม — ไม่มีข้อยกเว้น
• ขา browser ไม่ใช้ทั้ง Subscription Key และ API Key — เห็นในโค้ด FE เมื่อไหร่ = bug security
• ใช้เมื่อไหร่: มี caller ภายนอก/partner เรียกผ่าน APIM และต้องการควบคุมราย caller — server-to-server ภายใน cluster ที่ไม่ผ่าน APIM ใช้ API Key + HMAC ตามเดิม