Day 5: Service-to-Service Security & Client Credentials Grant

1. Client Credentials Grant คืออะไร? เมื่อไม่มีมนุษย์มาล็อกอิน ระบบยืนยันตัวตนกันอย่างไร?

The Autonomous Night-Shift Security Drone vs. The Human Employee

เปรียบเทียบการยืนยันตัวตนในระบบ IAM เสมือนการเปิดประตูเข้าอาคารสำนักงานใหญ่:
• User Flow (Human Employee): เปรียบเหมือน "พนักงานมนุษย์" ที่ต้องเดินมาหน้าป้อมยาม แสดงหน้าตา สแกนใบหน้าและกรอกรหัส 2FA ยามจึงแจกบัตรผ่านประตูพร้อมให้กุญแจสำรอง (Refresh Token) เผื่อเดินเข้าออกในวันนั้น
• Machine Flow (Autonomous Drone / Background Worker): เปรียบเหมือน "โดรนรักษาความปลอดภัยอัตโนมัติ" ที่บินอยู่ตอนตี 3 ไม่มีหน้าตามนุษย์ให้สแกน โดรนจะบินตรงไปยังแท่นชาร์จกลาง (Keycloak IdP) แล้วยื่นรหัสลับประจำชิปประมวลผล (Client Secret) ผ่านสัญญาณคลื่นเข้ารหัสส่วนตัว แท่นชาร์จจะปล่อยสติกเกอร์บาร์โค้ดผ่านประตูที่มีอายุ 5 นาที (Access Token) ให้โดรนบินไปตรวจห้องเก็บของ (Resource Server) หากสติกเกอร์หมดอายุ โดรนก็บินกลับมายื่นรหัสลับของชิปเพื่อขอสติกเกอร์แผ่นใหม่ได้เองทันทีโดยไม่ต้องปลุกใคร!

Anatomy of Service Account Provisioning via kcadm.sh CLI

การสร้าง M2M Client และการกำหนดสิทธิ์ให้ Service Account สามารถทำได้ผ่าน Keycloak Admin CLI (kcadm.sh) ตามขั้นตอนแบบทีละขั้น:

# 1. เข้าสู่ Container และล็อกอินผ่าน kcadm
docker exec -it keycloak-core /opt/keycloak/bin/kcadm.sh config credentials \
  --server http://localhost:8080 --realm master --user superadmin --password AdminSuperSecret2026!

# 2. สร้าง Confidential Client พร้อมเปิด Service Accounts
docker exec -it keycloak-core /opt/keycloak/bin/kcadm.sh create clients -r app-dev \
  -s clientId=billing-daemon \
  -s name="Automated Billing Background Daemon" \
  -s enabled=true \
  -s publicClient=false \
  -s serviceAccountsEnabled=true \
  -s standardFlowEnabled=false \
  -s directAccessGrantsEnabled=false

# 3. ตรวจสอบว่า Client สร้างสำเร็จและดึง Client Secret
CLIENT_UUID=$(docker exec -it keycloak-core /opt/keycloak/bin/kcadm.sh get clients -r app-dev -q clientId=billing-daemon --fields id --format csv | tail -n 1 | tr -d '\r')
docker exec -it keycloak-core /opt/keycloak/bin/kcadm.sh get clients/$CLIENT_UUID/client-secret -r app-dev

# 1. ค้นหา User Entity เสมือนของ Service Account
SA_USER_ID=$(docker exec -it keycloak-core /opt/keycloak/bin/kcadm.sh get clients/$CLIENT_UUID/service-account-user -r app-dev --fields id --format csv | tail -n 1 | tr -d '\r')
echo "Service Account User ID: $SA_USER_ID"

# 2. สร้าง Realm Role สำหรับงานเฉพาะทาง: 'invoice-writer'
docker exec -it keycloak-core /opt/keycloak/bin/kcadm.sh create roles -r app-dev -s name=invoice-writer -s description="Permission to generate and update invoices"

# 3. มอบสิทธิ์ Role 'invoice-writer' ให้กับ Service Account User
docker exec -it keycloak-core /opt/keycloak/bin/kcadm.sh add-roles -r app-dev --uid $SA_USER_ID --rolename invoice-writer

# 4. ทดสอบยิง HTTP POST แลก M2M Access Token ผ่าน cURL (Back-channel 100%)
CLIENT_SECRET=$(docker exec -it keycloak-core /opt/keycloak/bin/kcadm.sh get clients/$CLIENT_UUID/client-secret -r app-dev | jq -r '.value')

curl -s -X POST http://localhost:8080/realms/app-dev/protocol/openid-connect/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=billing-daemon" \
  -d "client_secret=$CLIENT_SECRET" | jq .

Live Client Credentials Exchanger & Zero-Downtime Secret Rotation

ทดลองจำลองการยิงคำขอของ Worker Service เพื่อขอ Access Token และสังเกตโครงสร้าง Payload ของ JWT ที่ได้ พร้อมทดลองหมุนเวียน Secret แบบ Zero-Downtime เพื่อดูว่าระบบจัดการคีย์สลับกันอย่างไร:

{
  "iss": "http://localhost:8080/realms/app-dev",
  "sub": "sa-uuid-99124-billing-daemon",
  "client_id": "billing-daemon",
  "resource_access": {
    "billing-daemon": {
      "roles": ["invoice-writer"]
    }
  },
  "scope": "email profile",
  "exp": 1791629100,
  "iat": 1791628800
}