Client Credentials Grant

Client Credentials grant คืออะไร?

Client Credentials grant ถูกออกแบบมาสำหรับการเรียก machine-to-machine ที่ไม่มีผู้ใช้ แทนที่จะให้ผู้ใช้ยืนยันตัวตน client จะยืนยันตัวตนตัวเองด้วย client_id และ client_secret เนื่องจากไม่มีผู้ใช้ใน flow Keycloak จึงส่งคืนเฉพาะ access token — ไม่มี ID token

grant นี้เป็นส่วนหนึ่งของ OAuth2 specification และเป็นวิธีมาตรฐานสำหรับ service account, background job, และกระบวนการอัตโนมัติที่ต้องเรียก protected API

เมื่อไรควรใช้

ใช้ Client Credentials grant สำหรับ:

• Background job ที่เรียก internal API
• Microservice ที่เรียกกันเอง
• CI/CD pipeline ที่จัดการ infrastructure

ไม่ควรใช้ กับสิ่งใดก็ตามที่มีผู้ใช้จริงเข้ามาเกี่ยวข้อง หากผู้ใช้ต้องยืนยันตัวตนและแอปต้องทำงานในนามของพวกเขา ให้ใช้ Authorization Code + PKCE แทน

การตั้งค่าใน Keycloak

1. สร้าง confidential client (ตั้ง Client authentication เป็น On)
2. เปิดใช้ Service Accounts — บน Capability config tab เปิดใช้ Service account roles
3. คัดลอก client secret จาก Credentials tab
4. กำหนด realm role หรือ client role ให้กับ service account user บน Service Accounts Roles tab หาก API ของคุณตรวจสอบ role ใน token

การขอ token

curl -X POST https://${KC_URL}/realms/${REALM}/protocol/openid-connect/token \
  -d "grant_type=client_credentials" \
  -d "client_id=${CLIENT_ID}" \
  -d "client_secret=${CLIENT_SECRET}"

Copy curl ⧉

🔐 ไม่มีผู้ใช้ ไม่มี ID token

Client Credentials grant ใช้สำหรับ service-to-service — ไม่มีผู้ใช้ดังนั้น Keycloak จึงไม่ออก ID token คุณได้รับเฉพาะ access token เท่านั้น หากต้องการทำงานในนามของผู้ใช้คนใดคนหนึ่ง ให้ใช้ Authorization Code + PKCE แทน

ข้อแลกเปลี่ยน

ตัวเลือก	Benefit	Cost
Client Credentials (M2M)	Setup ง่าย ไม่ต้องมี user login เหมาะกับ background job และ service-to-service call	ไม่มี user context เลย ใช้ไม่ได้ถ้าต้อง track ว่าใครเป็นคนทำ action
Authorization Code + PKCE (user-delegated)	รู้ว่า action นั้นทำในนามของผู้ใช้คนไหน รองรับ consent และ audit ต่อ user ได้	ต้องมีผู้ใช้ล็อกอินผ่าน browser ก่อนเสมอ ใช้กับ automated job ไม่ได้

ข้อผิดพลาดที่พบบ่อย

• ใส่ client secret ไว้ใน frontend หรือ mobile app — Client Credentials grant ออกแบบมาสำหรับ confidential client เท่านั้น เช่น backend service ที่รันบนเซิร์ฟเวอร์ที่ควบคุมได้ หากเอา secret ไปฝังใน frontend code หรือ mobile app ใครก็ตามที่ decompile หรือเปิด dev tools จะเห็น secret ทันที
• ใช้ Client Credentials เมื่อจริง ๆ ต้องการ user context — ถ้า flow ต้องรู้ว่า “ใครเป็นคนสั่ง action นี้” เพื่อทำ audit log หรือ authorization ตาม user role ห้ามใช้ Client Credentials เพราะไม่มี user เข้ามาเกี่ยวข้องเลย ต้องใช้ Authorization Code + PKCE แทน
• ไม่หมุน (rotate) client secret เป็นระยะ — เพราะ service account มักรันระยะยาวและไม่ค่อยมีใครไปแตะโค้ดอีก secret เดิมมักถูกใช้ซ้ำไปเรื่อย ๆ โดยไม่เคย rotate ทำให้ความเสี่ยงสะสมสูงขึ้นเมื่อเวลาผ่านไป

💡 ตัวอย่างจากของจริง

CI/CD pipeline ที่ deploy infrastructure — เช่น GitHub Actions หรือ GitLab CI ที่ต้องเรียก internal API เพื่อ provision resource จะใช้ Client Credentials grant เพราะไม่มีมนุษย์นั่งอยู่หน้าจอตอน pipeline รัน

Microservice ที่เรียกกันเองภายใน backend — เช่น order-service เรียก inventory-service จะยืนยันตัวตนด้วย Client Credentials แทนที่จะ forward user token ต่อ ๆ กันไปเรื่อย ๆ ซึ่งช่วยแยก concern เรื่อง service identity ออกจาก user identity ได้ชัดเจน

ควรใช้ Client Credentials grant เมื่อใด?

เมื่อผู้ใช้ login ผ่าน browser สำหรับการเรียก machine-to-machine ที่ไม่มีผู้ใช้ สำหรับแอปมือถือที่ใช้ PKCE เมื่อต้องการ ID token

Keycloak ส่งอะไรกลับมาเมื่อ Client Credentials request สำเร็จ?

ID token และ access token เฉพาะ access token (ไม่มี ID token) Refresh token เท่านั้น Authorization code

การตั้งค่าใดของ Keycloak ที่ต้องเปิดใช้สำหรับ Client Credentials?

Valid redirect URIs Web origins Service account roles PKCE method

Client ประเภทใดที่จำเป็นสำหรับ Client Credentials?

Public client Confidential client (Client authentication = On) SAML client Device client

Submit

Mark as complete