Social Login
Social login คืออะไร?
หัวข้อที่มีชื่อว่า “Social login คืออะไร?”Social login ช่วยให้ผู้ใช้ authenticate ด้วย provider ที่มีบัญชีอยู่แล้ว เช่น Google, GitHub, Facebook, Apple และอื่น ๆ แทนที่จะต้องสร้าง username และ password ใหม่ในรีล์ม ภายใต้การทำงาน Keycloak ทำหน้าที่เป็น identity broker: Keycloak redirect ผู้ใช้ไปยัง provider ที่เลือก provider authenticate ผู้ใช้ และ Keycloak ยอมรับ token ที่ได้รับ แอปพลิเคชันของคุณไม่ต้องติดต่อกับ external provider โดยตรง
Keycloak มี connector ในตัวสำหรับ social provider ทั่วไป แต่ละ connector เรียกว่า identity provider (IdP) ใน admin console
ขั้นตอนที่ 1 — รับ credentials จาก provider
หัวข้อที่มีชื่อว่า “ขั้นตอนที่ 1 — รับ credentials จาก provider”ก่อนจะตั้งค่าใน Keycloak คุณต้องลงทะเบียน OAuth2 client ที่ provider ก่อน ขั้นตอนต่างกันตาม provider แต่รูปแบบเหมือนกัน
สำหรับ Google:
- ไปที่ console.cloud.google.com และสร้างหรือเลือก project
- ไปที่ APIs & Services → Credentials → Create Credentials → OAuth client ID
- ตั้งประเภทแอปพลิเคชันเป็น Web application
- ในช่อง Authorised redirect URIs ใส่ broker endpoint ของ Keycloak สำหรับรีล์มของคุณ (ดูขั้นตอนที่ 2 ด้านล่าง)
- คลิก Create บันทึก Client ID และ Client secret
สำหรับ GitHub:
- ไปที่ GitHub → Settings → Developer settings → OAuth Apps → New OAuth App
- ตั้ง Authorization callback URL เป็น broker endpoint ของ Keycloak (ดูขั้นตอนที่ 2 ด้านล่าง)
- คลิก Register application บันทึก Client ID และสร้าง Client secret
ขั้นตอนที่ 2 — หา redirect URI ที่ต้องลงทะเบียนกับ provider
หัวข้อที่มีชื่อว่า “ขั้นตอนที่ 2 — หา redirect URI ที่ต้องลงทะเบียนกับ provider”Keycloak เปิดเผย broker endpoint ที่แน่นอนสำหรับแต่ละ identity provider alias คุณต้องลงทะเบียน URI นี้กับ external provider — นี่คือที่ที่ provider ส่งผู้ใช้กลับมาหลัง authentication
URI ตาม pattern นี้:
https://<keycloak-host>/realms/<realm>/broker/<alias>/endpointตัวอย่าง ถ้า Keycloak รันที่ https://auth.example.com รีล์มชื่อ my-app และ alias คือ google redirect URI คือ:
https://auth.example.com/realms/my-app/broker/google/endpointลงทะเบียน URI นี้ตามที่แสดงใน developer console ของ provider ความไม่ตรงกัน — แม้แต่ trailing slash — จะทำให้ social login ล้มเหลวด้วย redirect URI mismatch error
ขั้นตอนที่ 3 — เพิ่ม identity provider ใน Keycloak
หัวข้อที่มีชื่อว่า “ขั้นตอนที่ 3 — เพิ่ม identity provider ใน Keycloak”- เปิด Keycloak admin console และสลับไปยังรีล์มเป้าหมาย
- คลิก Identity providers ใน left sidebar
- คลิก Add provider และเลือก Google (หรือ GitHub หรือ provider อื่น ๆ ที่แสดง)
- Keycloak กรอก Alias ไว้ล่วงหน้า (เช่น
google) ปล่อยไว้ถ้าไม่มีเหตุผลที่ต้องเปลี่ยน - วาง Client ID จากขั้นตอนที่ 1 ลงในช่อง Client ID
- วาง Client secret จากขั้นตอนที่ 1 ลงในช่อง Client secret
- ปล่อยการตั้งค่าอื่น ๆ ไว้เป็นค่าเริ่มต้นก่อน
- คลิก Save
ขั้นตอนที่ 4 — ทดสอบ social login
หัวข้อที่มีชื่อว่า “ขั้นตอนที่ 4 — ทดสอบ social login”- เปิดหน้า login ของรีล์ม:
https://<keycloak-host>/realms/<realm>/account - คุณควรเห็นปุ่มใหม่ — “Log in with Google” หรือ “Sign in with GitHub” — ด้านล่างฟอร์ม username/password
- คลิกปุ่ม คุณจะถูก redirect ไปยังหน้า login ของ external provider
- Authenticate กับ external provider คุณจะถูก redirect กลับมาที่ Keycloak และ Keycloak จะสร้าง federated user ในรีล์ม (หรือเชื่อมกับบัญชีที่มีอยู่ผ่าน first-login flow)
Provider alias กับปุ่ม login
หัวข้อที่มีชื่อว่า “Provider alias กับปุ่ม login”Alias ที่ตั้งในขั้นตอนที่ 3 ปรากฏใน broker endpoint URI และควบคุมการแสดงผลบนหน้า login ด้วย Keycloak ใช้ alias เพื่อ route callback กลับไปยัง IdP configuration ที่ถูกต้อง ถ้าคุณเปลี่ยนชื่อหรือลบ IdP federated user links ที่อ้างอิง alias เดิมจะพัง — ผู้ใช้จะไม่สามารถ login ผ่าน provider นั้นได้จนกว่าจะอัปเดต link
ข้อแลกเปลี่ยน
หัวข้อที่มีชื่อว่า “ข้อแลกเปลี่ยน”| ตัวเลือก | Benefit | Cost |
|---|---|---|
| Identity brokering เป็น hub กลาง (ให้ Keycloak เป็นตัวกลางจัดการ social login ทั้งหมด) | จัดการ credential, redirect URI และ token exchange ในที่เดียว เพิ่ม provider ใหม่โดยไม่ต้องแตะแอปพลิเคชัน | ต้อง maintain configuration ของแต่ละ IdP ใน Keycloak เอง และแอปทั้งหมดพึ่งพา Keycloak เป็น single point of failure |
| แต่ละแอปฝัง social-login SDK ของตัวเอง (เช่น Google Sign-In SDK ตรง ๆ ในแต่ละแอป) | ควบคุม UX ของปุ่ม login ได้ละเอียดกว่า ไม่ต้อง depend กับ Keycloak | ทีมต้อง maintain OAuth client และ SDK แยกกันในทุกแอป เปลี่ยน provider ทีต้องแก้หลายที่ |
ข้อผิดพลาดที่พบบ่อย
หัวข้อที่มีชื่อว่า “ข้อผิดพลาดที่พบบ่อย”- ใช้ Google OAuth client เดียวกันข้าม dev/staging/prod — ควรสร้าง OAuth client แยกต่อ environment เพราะ redirect URI ต่างกัน และถ้า client เดียวกันรั่วใน environment ที่ไม่ปลอดภัย (เช่น dev) จะกระทบ prod ด้วย
- ลืมตั้ง redirect URI ให้ตรงเป๊ะกับที่ Keycloak เปิดเผย — แม้ trailing slash เกินก็ทำให้ social login ล้มเหลวด้วย redirect URI mismatch ต้อง copy pattern จากขั้นตอนที่ 2 มาวางตรง ๆ
- ไม่ตรวจสอบ first-login flow ก่อนเปิดใช้ social login จริง — ถ้าไม่ตั้งค่าการเชื่อมบัญชีให้ถูกต้อง ผู้ใช้ที่มีบัญชีเดิมอยู่แล้วอาจได้บัญชีซ้ำซ้อนโดยไม่รู้ตัว
💡 ตัวอย่างจากของจริง
แอปที่มีปุ่ม “Log in with Google” หรือ “Log in with GitHub” — นี่คือ identity brokering ที่ทำงานอยู่จริงในโปรดักชัน แอปไม่เคยเห็น credential ของ Google หรือ GitHub เลย แอปแค่รับ token ที่ Keycloak ออกให้หลังจาก broker เสร็จ
สตาร์ทอัพที่ขยายจาก 1 แอปเป็นหลายแอป — เดิมแต่ละแอปฝัง Google SDK ของตัวเอง พอย้ายมาใช้ Keycloak เป็น broker กลาง การเพิ่ม provider ใหม่ (เช่น Apple Sign-In) ทำครั้งเดียวใน Keycloak แล้วทุกแอปได้ใช้ทันทีโดยไม่ต้อง deploy ใหม่