Realms

realm คืออะไร?

realm คือ container ระดับบนสุดใน Keycloak ทุก object ใน Keycloak — ไม่ว่าจะเป็น user, client, role, identity provider, token policy — ล้วนอยู่ใน realm หนึ่งเดียวเท่านั้น realm แต่ละตัวแยกออกจากกันอย่างสมบูรณ์: user ใน realm shop ไม่สามารถ log in เข้าแอปพลิเคชันที่ลงทะเบียนไว้ใน realm blog ได้ และ session ของพวกเขาก็จะไม่ถูกแชร์กัน

คุณสามารถนึกถึง realm ว่าเหมือน tenant ในระบบ SaaS แบบ multi-tenant ได้ เพียงแต่ว่าแต่ละ realm ถูกจัดการอยู่ภายใน Keycloak server เครื่องเดียวทั้งหมด

master realm

Keycloak ติดตั้งมาพร้อม realm หนึ่งตัวอยู่แล้วคือ master master realm มีจุดประสงค์พิเศษ: เป็น realm สำหรับงานบริหารจัดการ เมื่อคุณเปิด Keycloak admin console แล้ว log in คุณกำลังยืนยันตัวตนกับ master อยู่

master realm สามารถสร้างและจัดการ realm อื่น ๆ ได้ แต่ไม่ควรนำไปใช้ลงทะเบียนแอปพลิเคชันของคุณเองหรือเก็บ user ของแอปพลิเคชันของคุณ การปนกัน user ของแอปกับ super-user ฝ่ายบริหารของ master ถือเป็นความเสี่ยงด้านความปลอดภัยที่ร้ายแรง

การสร้าง realm

เปิด Keycloak admin console ที่ http://localhost:8080 แล้ว sign in ด้วย admin credentials ของคุณ
ที่มุมบนซ้าย ให้คลิกที่ drop-down ชื่อ realm (ตอนแรกจะแสดงเป็น Keycloak หรือ master)
คลิก Create realm
ในช่อง Realm name ให้ใส่ชื่อ realm ที่สั้น เป็นตัวพิมพ์เล็ก และคั่นด้วยขีดกลาง (เช่น my-app)
ตรวจสอบให้แน่ใจว่า Enabled ถูกเปิดอยู่
คลิก Create

Keycloak จะสร้าง realm แล้วสลับ context ของ console ของคุณเข้าไปใน realm นั้น การตั้งค่าทั้งหมดหลังจากนี้ (client, role, user) จะอยู่ใน realm ใหม่นี้

พาทัวร์การตั้งค่า realm

หลังจากสร้าง realm แล้ว ให้คลิก Realm settings ในแถบด้านซ้าย การตั้งค่าถูกจัดเป็นแท็บต่าง ๆ:

General

Display name — ชื่อที่อ่านง่ายสำหรับคนทั่วไป แสดงบนหน้า login
Frontend URL — override URL ที่ Keycloak ใช้สร้าง redirect link (มีประโยชน์เมื่ออยู่หลัง reverse proxy)
HTML display name — รองรับ HTML สำหรับหน้า login ที่ทำแบรนด์

User registration — อนุญาตให้สมัครสมาชิกเองได้
Forgot password — เปิดใช้งานขั้นตอนรีเซ็ตรหัสผ่าน (ต้องตั้งค่า email ไว้)
Remember me — ให้ user ยังคง log in อยู่ข้ามการรีสตาร์ท browser ได้
Verify email — บังคับให้ user ยืนยัน email address หลังจากสมัครสมาชิก
Login with email — อนุญาตให้ user กรอก email address แทน username ได้

Email

ตั้งค่า SMTP server ที่ Keycloak ใช้ส่ง email ยืนยันตัวตนและรีเซ็ตรหัสผ่าน จำเป็นต้องตั้งค่าหากคุณเปิดใช้งานขั้นตอนใด ๆ ที่ต้องอาศัย email

Tokens

การตั้งค่าสำคัญที่ควบคุมอายุและพฤติกรรมของ token:

การตั้งค่า	ค่าเริ่มต้น	สิ่งที่ควบคุม
Access token lifespan	5 นาที	access token มีอายุนานแค่ไหน
SSO session idle	30 นาที	session หมดอายุหากไม่มีการใช้งานนานเท่านี้
SSO session max	10 ชั่วโมง	ขีดจำกัดสูงสุดของความยาว session
Refresh token lifespan	เท่ากับ SSO session	refresh token ใช้ได้นานแค่ไหน

access token ที่มีอายุสั้นลงจะลดช่วงเวลาที่ตกอยู่ในความเสี่ยงหาก token ถูกขโมย แลกกับการต้อง refresh บ่อยขึ้น

Keys

Keycloak จะสร้าง cryptographic key สำหรับ sign token ให้โดยอัตโนมัติ แท็บ Keys จะแสดง key provider ที่ใช้งานอยู่ สำหรับ production คุณควรหมุน (rotate) key เป็นระยะ provider แบบ RS256 คือค่าเริ่มต้นและสร้าง JWT ที่ sign ด้วย RSA private key; client จะตรวจสอบ signature โดยใช้ public key ที่มีอยู่ที่ JWKS endpoint ของ realm:

http://localhost:8080/realms/{realm-name}/protocol/openid-connect/certs

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

ตัวเลือก	Benefit	Cost
realm ต่อแอป (realm-per-app)	แยก user, session และ token policy ของแต่ละแอปออกจากกันอย่างสมบูรณ์ ลดผลกระทบเมื่อแอปหนึ่งมีปัญหาความปลอดภัย	ต้องดูแลหลาย realm — theme, SMTP, identity provider ต้องตั้งค่าซ้ำในแต่ละ realm เพิ่ม operational overhead
shared realm (หลายแอปอยู่ realm เดียว)	ตั้งค่าและดูแลรักษาง่ายกว่า user เดียวใช้ได้กับหลายแอปแบบ SSO ทันที	isolation อ่อนกว่า — การตั้งค่าหรือ role ที่ผิดพลาดในแอปหนึ่งอาจกระทบแอปอื่นในขอบเขตเดียวกัน

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

ลงทะเบียนแอปจริงไว้ใน master realm — master ควรสงวนไว้สำหรับงานบริหารจัดการ Keycloak เท่านั้น ให้สร้าง realm แยกสำหรับทุกโปรเจกต์หรือผลิตภัณฑ์ เพื่อไม่ให้ user ของแอปปนกับ super-user ฝ่ายบริหาร
ลืมตั้งค่า token lifespan ให้เหมาะกับความเสี่ยงของแอป — ใช้ค่า default ของทุก realm เหมือนกันหมด ทั้งที่บาง realm (เช่น banking) ควรมี access token lifespan สั้นกว่า realm ที่ความเสี่ยงต่ำ
ไม่ rotate signing key เป็นระยะใน production — ปล่อยให้ key เดิมใช้งานตลอดอายุของระบบ เพิ่มความเสี่ยงหาก private key รั่วไหลโดยไม่รู้ตัว

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

Multi-tenant SaaS platform — แพลตฟอร์ม SaaS จำนวนมากใช้ pattern realm-per-customer โดยสร้าง realm แยกให้ลูกค้าแต่ละราย ทำให้ user, role และ session ของลูกค้าแต่ละคนแยกขาดจากกันอย่างสมบูรณ์ พร้อมรองรับการทำ custom branding และ identity provider ต่อ tenant ได้ง่าย

องค์กรขนาดใหญ่ที่มีหลายทีม — บริษัทที่มีทั้งระบบ internal tool และ customer-facing product มักแยก realm ตามกลุ่มผู้ใช้ เช่น realm staff สำหรับพนักงาน กับ realm customers สำหรับลูกค้า เพื่อไม่ให้ policy ด้าน password หรือ MFA ของฝั่งหนึ่งไปกระทบอีกฝั่ง