เชื่อมต่อผู้ให้บริการ OpenID Connect

ใช้คู่มือนี้เมื่อผู้ให้บริการตัวตนของคุณพูด OpenID Connect แทน SAML ผู้ออกที่ผ่านการรับรอง OIDC รายใดก็ใช้ได้ — Pocket ID, Keycloak, Auth0, Zitadel, Google Workspace และรายอื่น ๆ ล้วนทำตามขั้นตอนเดียวกัน ต่างกันแค่จุดที่ผู้ให้บริการของคุณแสดงค่าเหล่านั้น

สิ่งที่ต้องมีก่อน

• ผู้ให้บริการ OIDC ที่คุณสร้างไคลเอนต์ได้ — จด client id และ URL ผู้ออก ของมันไว้ (base ที่เอกสาร .well-known/openid-configuration อาศัยอยู่) รวมทั้ง client secret ของมันเมื่อไคลเอนต์เป็นแบบ confidential (ไคลเอนต์ PKCE สาธารณะไม่มี secret),
• เซิร์ฟเวอร์ Control Center ที่คุณดูแล (ในฐานะเจ้าของเซิร์ฟเวอร์)

ขั้นตอน

1. เปิด การตั้งค่า → เซิร์ฟเวอร์ → ลงชื่อเข้าใช้ครั้งเดียว แล้วสลับไปที่ OpenID Connect
2. กรอก URL ผู้ออก และ Client ID รวมทั้ง Client secret (ไม่บังคับ) เมื่อผู้ให้บริการออกให้ Control Center จะค้นหาเอนด์พอยต์จาก เอกสาร discovery มาตรฐานของผู้ออกเอง — ไม่ต้องตั้งค่าเฉพาะผู้ให้บริการแต่ละราย
3. ที่ฝั่งผู้ให้บริการ ให้ลงทะเบียน redirect https://<your-server>/oidc/callback กับไคลเอนต์นั้น
4. หากกลุ่มของคุณอยู่ใน claim อื่นที่ไม่ใช่ groups ให้ตั้งชื่อ เคลมกลุ่ม และแมปกลุ่มเป็นบทบาทได้หากต้องการ (SSO ไม่มีทาง ให้บทบาทเจ้าของได้)
5. เลือกนโยบายสมาชิก (เพิ่มเข้าทุกเวิร์กสเปซอัตโนมัติ หรือบังคับให้เชิญ เป็นรายเวิร์กสเปซ) เปิด ใช้ OpenID Connect สำหรับลงชื่อเข้าใช้ แล้ว กด บันทึกการเชื่อมต่อ
6. กด ทดสอบการเชื่อมต่อ — เซิร์ฟเวอร์จะดึงเอกสาร discovery ของผู้ออกและยืนยันเอนด์พอยต์ของมัน ดังนั้นทอสต์สีเขียวหมายความว่าทุกอย่าง ยกเว้นการไปกลับผ่านเบราว์เซอร์ทำงานได้ หากต้องการตรวจการลงทะเบียน ไคลเอนต์ด้วย ให้ใช้ตัวตรวจสอบด้านล่าง
7. ลองลงชื่อเข้าใช้ดู: หน้าจอเชื่อมต่อบนเว็บจะแสดง ลงชื่อเข้าใช้ด้วย OpenID Connect หรือเปิด https://<your-server>/oidc/login โดยตรง

Claims (อีเมล ชื่อ กลุ่ม) ถูกอ่านจาก token endpoint ของผู้ออกผ่าน TLS โดยเซิร์ฟเวอร์ของคุณ — เบราว์เซอร์ไม่เคยเป็นผู้ส่งค่าเหล่านี้ จึงไม่มีการ ตรวจสอบลายเซ็น JWT ในเครื่องเข้ามาเกี่ยวข้อง ไคลเอนต์ควรได้รับอนุญาตให้ร้องขอ scope openid profile email ซึ่งเป็นสิ่งที่ Control Center ขอพอดี

เนื่องจากช่องทาง TLS นั้นเป็นสิ่งเดียวที่ยืนยันความถูกต้องของ claims URL ผู้ออกจึงต้องเป็น https — ผู้ออกที่เป็น plaintext จะเปิดทางให้ ผู้โจมตีบนเส้นทางปลอมแปลงตัวตนได้ทั้งหมด ระบบยอมรับ http เฉพาะกับผู้ออกแบบ loopback (localhost, 127.0.0.1, ::1) เท่านั้น สำหรับการพัฒนาภายในเครื่อง

ไคลเอนต์สาธารณะหรือไคลเอนต์ confidential?

รูปแบบเริ่มต้น — และที่แนะนำ — คือ ไคลเอนต์สาธารณะ ที่ใช้ authorization code flow ร่วมกับ PKCE (RFC 7636): code verifier แบบใช้ครั้งเดียวที่เซิร์ฟเวอร์ถืออยู่จะทำหน้าที่แทน secret และ การแลกเปลี่ยนโทเคนจะผูกกับคำขออนุญาตที่เริ่มกระบวนการนั้น ไม่มี secret ให้รั่วไหล และ authorization code ที่ถูกขโมยไปก็ไร้ประโยชน์หากไม่มี verifier ผู้ให้บริการบางรายเรียกชนิดไคลเอนต์นี้ว่า “SPA” หรือ “native” ตอนที่คุณสร้างมัน

หากผู้ให้บริการของคุณออกไคลเอนต์แบบ confidential มาแทน ให้ทำเครื่องหมาย ไคลเอนต์เป็นสาธารณะที่ฝั่งผู้ให้บริการ (ไม่ว่าทางไหน PKCE ก็ยังทำงานอยู่) หรือ วาง client secret ลงในช่อง Client secret (ไม่บังคับ) ของการเชื่อมต่อ secret ถูกเก็บในไฟล์ secrets สิทธิ์ 0600 ของเซิร์ฟเวอร์ (ไม่ใช่ฐานข้อมูล เด็ดขาด) ส่งไปยัง token endpoint เป็น client_secret_post และไม่ถูกส่งกลับ ผ่าน RPC เลย การเว้นช่องนี้ว่างไว้ตอนบันทึกจะคง secret ที่เก็บไว้เดิม เมื่อการลงชื่อเข้าใช้ล้มเหลวที่ขั้นตอนแลกเปลี่ยนโทเคน ล็อกของเซิร์ฟเวอร์ จะระบุข้อผิดพลาดจากผู้ให้บริการเอง (invalid_client เกือบทุกครั้ง หมายความว่า secret หายไปหรือไม่ถูกต้อง)

การเข้าถึงได้

การลงชื่อเข้าใช้เองดำเนินการผ่านเบราว์เซอร์: ผู้ออกเพียงเปลี่ยนเส้นทาง เบราว์เซอร์ของผู้ใช้กลับมาที่ /oidc/callback และเซิร์ฟเวอร์ของคุณเรียก HTTPS ขาออกไปยัง token endpoint เท่านั้น — ไม่ต้องมีการเชื่อมต่อขาเข้าจาก ผู้ออก เซิร์ฟเวอร์ที่อยู่หลัง NAT จึงใช้งานได้ตราบใดที่เบราว์เซอร์ของผู้ใช้เข้าถึง มันได้ (LAN, VPN, Tailscale หรือทันเนล) การจัดสรรผู้ใช้ด้วย SCIM เป็น ข้อยกเว้น: IdP เรียกเซิร์ฟเวอร์ของคุณโดยตรง ซึ่งต้องใช้ทันเนลหรือ URL สาธารณะ — ดูจัดสรรผู้ใช้ด้วย SCIM

ตรวจสอบการกำหนดค่าของคุณจากหน้านี้

ตัวตรวจสอบด้านล่างทำงานในเบราว์เซอร์ของคุณ มันดึงเอกสาร discovery ของผู้ออกของคุณโดยตรง เว็บไซต์นี้จึงไม่เคยเห็นมัน และนำกฎของเซิร์ฟเวอร์มา ปรับใช้: ผู้ออกที่เป็น https ซึ่งตรงกับเอกสาร เอนด์พอยต์บน origin ของผู้ออกเอง PKCE S256 และวิธีตรวจสอบสิทธิ์โทเคนที่ชนิดไคลเอนต์ของคุณต้องใช้ เมื่อมี client ID และที่อยู่เซิร์ฟเวอร์ มันจะเปิดการลงชื่อเข้าใช้ทดสอบที่บอกว่า ไคลเอนต์และ redirect URI ของมันลงทะเบียนไว้แล้วหรือไม่ มันไม่เคยขอ client secret

Runs in your browserYour browser fetches the discovery document straight from your issuer. Add a server address and it also asks that server which sign-in methods it offers. This site never receives what you type.

Issuer URL

Client ID (optional)

Needed for the test sign-in.

Groups claim (optional)

Client type

Public, PKCE only Confidential, has a client secret

Never paste the secret here. The check only needs to know whether one exists.

Server address (optional)

The address your users open. Adds a reachability check and a test sign-in.

Paste the discovery document instead

Discovery document JSON

For providers that block other sites from reading it.

Check issuer