Keycloak คืออะไร?

Keycloak เป็น open-source IAM server ที่ดูแลโดย Red Hat ทำงานในฐานะ standalone server (Quarkus distribution) และแอปพลิเคชันของคุณ integrate ผ่าน standard protocols แอปของคุณไม่เห็น password เลย — แต่ redirect ผู้ใช้ไปยัง Keycloak และรับ signed token กลับมา

ความสามารถหลัก

Single Sign-On (SSO)

เมื่อผู้ใช้ authenticate กับ Keycloak แล้ว แอปพลิเคชันอื่นใน realm เดียวกันสามารถรับ token ที่ valid ได้โดยไม่ต้องให้ผู้ใช้ login ซ้ำ session อยู่ที่ Keycloak ไม่ใช่ในแอปของคุณ

Standard protocols

Keycloak ใช้ OpenID Connect (OIDC) และ OAuth2 เป็น primary protocols นอกจากนี้ยังรองรับ SAML 2.0 สำหรับการ integrate กับระบบ enterprise เดิม แอปพลิเคชันที่ compliant ทุกตัว ไม่ว่าจะเป็นภาษาหรือ framework ใดก็ตาม สามารถ integrate ได้โดยไม่ต้องเขียน auth code เอง

การจัดการผู้ใช้

admin console และ REST API ช่วยให้คุณสร้าง, อัปเดต, ปิดใช้งาน และค้นหาผู้ใช้ได้ ผู้ใช้สามารถ reset password, ยืนยัน email, ตั้งค่า TOTP และจัดการ session ได้ทั้งหมดผ่าน Keycloak ไม่ใช่ผ่านแอปของคุณ

Identity brokering และ social login

Keycloak สามารถ delegate authentication ไปยัง identity provider ภายนอกได้ ไม่ว่าจะเป็น Google, GitHub, Microsoft, Facebook หรือ IdP ที่ compatible กับ OIDC/SAML ผู้ใช้กดปุ่ม “Sign in with Google” บนหน้า login ของ realm คุณ แล้ว Keycloak จะจัดการ federation ให้

User federation

หากองค์กรของคุณมีผู้ใช้อยู่ใน LDAP หรือ Active Directory แล้ว Keycloak สามารถเชื่อมต่อโดยตรงได้ ผู้ใช้ authenticate กับ directory ที่มีอยู่ของพวกเขา และ Keycloak จะ synchronise attributes และจัดการ session

Admin console และ REST API

ทุก operation ที่ทำได้ใน admin console ก็สามารถทำได้ผ่าน REST API เช่นกัน คุณสามารถ automate การตั้งค่า realm, การลงทะเบียน client และการสร้างผู้ใช้ได้ด้วย API หรือ Keycloak Terraform provider

อะไรเปลี่ยนไปบ้างในเวอร์ชันล่าสุด

Keycloak เปลี่ยนแปลงเยอะมากระหว่างเวอร์ชัน 22 ถึง 26 ทำให้ tutorial เก่าหลายอันใช้ไม่ได้แล้ว คอร์สนี้อ้างอิง Keycloak 26.x (26.7 ณ เวลาที่เขียน) ด้านล่างคือสิ่งที่มักทำให้สับสนที่สุดถ้าคุณเคยอ่านคู่มือรุ่นเก่ามาก่อน

สิ่งที่เปลี่ยน	เริ่มใน	ผลกับคุณ
เหลือแค่ Quarkus distribution	17 (WildFly ถูกเลิกใช้ปี 2022)	ไม่มี standalone.xml แล้ว การตั้งค่าใช้ CLI option และ environment variable KC_*
account console ใหม่เป็นค่าเริ่มต้น	24	theme ของ account console v1 และ v2 ถูกลบใน 22 และ 25
Java adapter ส่วนใหญ่ถูกลบ	25	ให้ใช้ OIDC/OAuth2 มาตรฐานที่ framework ของคุณมีอยู่แทน
persistent user session เป็นค่าเริ่มต้น	25	session ถูกเก็บใน database จึงไม่หายเมื่อ restart
Organizations	26	โมเดล multi-tenancy ในระดับ first-class ภายใน realm เดียว
Hostname v2	26	--hostname รับ base URL เต็มรูปแบบได้ และ option hostname แบบเดิมถูกลบไปแล้ว
เปลี่ยนชื่อตัวแปร bootstrap admin	26	KEYCLOAK_ADMIN และ KEYCLOAK_ADMIN_PASSWORD กลายเป็น KC_BOOTSTRAP_ADMIN_USERNAME และ KC_BOOTSTRAP_ADMIN_PASSWORD
login theme ใหม่เป็นค่าเริ่มต้น	26	theme keycloak.v2 มาแทน theme เดิม

ถ้าบทความไหนบอกให้แก้ไฟล์ XML, ให้โหลด adapter keycloak-connect หรือให้ตั้ง KEYCLOAK_ADMIN แปลว่าบทความนั้นเก่ากว่า server ที่คุณกำลังรันอยู่

ตำแหน่งของ Keycloak ในสถาปัตยกรรม

Keycloak อยู่ระหว่างผู้ใช้กับแอปพลิเคชันของคุณ ผู้ใช้ authenticate ครั้งเดียวกับ Keycloak และรับ signed token มา แอปของคุณ validate token เหล่านั้นในเครื่องโดยไม่ต้องเรียก Keycloak ทุก request

flowchart TD
  U[Users] --> K[Keycloak auth server]
  K -- issues signed tokens --> A[Your apps]

Where Keycloak sits in your architecture

🔐 ประเด็นสำคัญ

Keycloak รองรับ OIDC/OAuth2 และ SAML — แอปพลิเคชันที่ compliant ทุกตัวสามารถ integrate ได้โดยไม่ต้องเขียน auth code เอง

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

ตัวเลือก	Benefit	Cost
Self-host Keycloak	ควบคุม data residency เต็มที่, ไม่มีค่า MAU (monthly active user), customize ได้ทุกส่วนรวมถึง theme และ SPI	ต้องดูแล infrastructure เอง (patching, scaling, backup, HA) และต้องมีทีมที่เข้าใจ Keycloak internals
Managed IdP (Auth0, AWS Cognito)	เริ่มใช้งานได้เร็ว ไม่ต้องดูแล server, มี SLA และ support จาก vendor	ค่าใช้จ่ายเพิ่มตามจำนวนผู้ใช้ (MAU pricing), customize ได้จำกัดกว่า, ข้อมูลผู้ใช้อยู่นอกโครงสร้างพื้นฐานของคุณ

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

• มอง Keycloak เป็น “ติดตั้งแล้วจบ” — Keycloak ต้องการการดูแลต่อเนื่อง เช่น อัปเกรด version, monitor performance และ patch security vulnerability เหมือน service อื่นใน production
• เลือก self-host โดยไม่ประเมิน ops cost — ทีมที่ไม่มีประสบการณ์ดูแล stateful service มักประเมินค่าใช้จ่ายด้าน infrastructure และ on-call ต่ำเกินไปเมื่อเทียบกับการจ่ายค่า managed IdP
• สับสนระหว่าง Keycloak กับ application-level authorization — Keycloak จัดการ authentication และ token issuance เท่านั้น ส่วน authorization logic ที่ซับซ้อนของแต่ละแอปยังต้อง implement เองอยู่ดี

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

Red Hat build of Keycloak (RH-SSO) — Red Hat เอง distribute Keycloak แบบมี commercial support ภายใต้ชื่อ “Red Hat build of Keycloak” (เดิมชื่อ RH-SSO) ให้องค์กรที่ต้องการ SLA และ certified build โดยไม่ต้องเสียความยืดหยุ่นของ open source

องค์กร enterprise ขนาดใหญ่ — บริษัทที่มีแอปพลิเคชันภายในหลายสิบตัวมักเลือก self-host Keycloak เพื่อรวม login ทั้งหมดเป็น SSO เดียว ลดภาระ helpdesk เรื่อง password reset และให้ทีม security ควบคุม authentication policy จากจุดเดียว

SSO ในบริบทของ Keycloak หมายความว่าอย่างไร?

แต่ละแอปมีหน้า login ของตัวเอง เมื่อ authenticate แล้ว ผู้ใช้เข้าถึงหลาย app ได้โดยไม่ต้อง login ซ้ำ ผู้ใช้ใช้ password เดียวกันสำหรับทุก app Keycloak เก็บ password ให้ทุก app

ระบบ directory ใดที่ Keycloak สามารถ federate ได้?

MySQL และ PostgreSQL Redis และ Memcached LDAP และ Active Directory S3 และ GCS

Identity brokering คืออะไร?

การเก็บ password ในที่เข้ารหัส การ delegate authentication ไปยัง identity provider ภายนอกเช่น Google หรือ GitHub การ sync ผู้ใช้ระหว่าง Keycloak realm สองอัน การสร้าง machine-to-machine token

Keycloak distribution ใดที่แนะนำสำหรับการ deploy สมัยใหม่?

WildFly distribution Quarkus distribution Tomcat distribution Spring Boot embedded distribution

Submit

Mark as complete