OIDC คืออะไร: จากเหตุผลที่จำเป็นต้องมีไปจนถึงวิธีการทำงาน

คำนิยามของ OpenID Connect (OIDC)#

OpenID Connect (OIDC) คือโปรโตคอลการตรวจสอบตัวตนที่สร้างขึ้นบนพื้นฐานของ OAuth 2.0 ในขณะที่ OAuth 2.0 เพียงแค่ให้การอนุญาต การอนุญาตให้ใช้งานเท่านั้น OIDC เพิ่มความสามารถในการตรวจสอบตัวตนเสนอวิธีการแก้ปัญหาที่มีมาตรฐานมากขึ้นสำหรับกรณีการใช้งานการอนุญาตและการตรวจสอบตัวตนของผู้ใช้

พูดง่าย ๆ : OIDC = โปรโตคอลการอนุญาต + การตรวจสอบตัวตน

ทำไมต้องมี OIDC?#

เพื่อที่จะเข้าใจว่าทำไมต้องมี OIDC เรามาสำรวจแนวคิดหลักและการทำงานของ OAuth 2.0 และข้อจำกัดในทางปฏิบัติก่อน นอกจากนี้เราจะวิเคราะห์กรณีศึกษาบางกรณีเพื่อดูว่าทำไมเราต้องการ OIDC เหนือกว่า OAuth 2.0

แนวคิดหลักและการทำงานของ OAuth 2.0#

OAuth 2.0 (Open Authorization) คือโปรโตคอลการอนุญาตที่ให้ผู้ใช้อำนาจให้แอปพลิเคชันบุคคลที่สามเข้าถึงทรัพยากรของพวกเขาโดยไม่ต้องแชร์ข้อมูลรับรอง เช่น ชื่อผู้ใช้และรหัสผ่าน มันประกอบด้วยบทบาทหลักสี่อย่าง:

• เจ้าของทรัพยากร (Resource Owner): ผู้ใช้ที่ครอบครองทรัพยากร
• เซิร์ฟเวอร์ทรัพยากร (Resource Server): เซิร์ฟเวอร์ที่เก็บรักษาทรัพยากรของผู้ใช้
• ไคลเอนต์ (Client): แอปพลิเคชันบุคคลที่สามที่ขอการเข้าถึงทรัพยากรของผู้ใช้
• เซิร์ฟเวอร์การอนุญาต (Authorization Server): เซิร์ฟเวอร์ที่ตรวจสอบตัวตนของผู้ใช้และออกโทเคนการเข้าถึง

การทำงานของ OAuth 2.0 ที่พบบ่อยมีลำดับขั้นตอนดังนี้:

ตามที่เห็น OAuth 2.0 เน้นในการออกโทเคนการเข้าถึงแอปพลิเคชันบุคคลที่สามเพื่อเข้าถึงทรัพยากรของผู้ใช้

ข้อจำกัดของ OAuth 2.0#

โปรโตคอล OAuth 2.0 มุ่งเน้นเพียงในการออกโทเคนการเข้าถึง เซิร์ฟเวอร์ทรัพยากรยืนยันโทเคนเหล่านี้และส่งคืนทรัพยากรที่ได้รับอนุญาต อย่างไรก็ตามเซิร์ฟเวอร์ทรัพยากรไม่ทราบถึงตัวตนของผู้ใช้

นี่ไม่ได้เป็นปัญหาใหญ่ในระบบนิเวศอินเทอร์เน็ตในสมัยแรก ๆ

อย่างไรก็ตามเมื่อแพลตฟอร์ม เช่น Google, Facebook, Twitter และ Github พัฒนา พวกเขาเริ่มนำเสนอทรัพยากรผู้ใช้ที่มีค่ามากขึ้นสำหรับแอพพลิเคชันบุคคลที่สาม

แม้ว่า OAuth 2.0 จะทำได้ดีในการอนุญาตการเข้าถึงของบุคคลที่สามไปยังทรัพยากรของผู้ใช้ แต่ยังมีข้อจำกัด ตัวอย่างทั่วไปคือ: เนื่องจากข้อมูลผู้ใช้ก็เป็นทรัพยากรเช่นกัน เมื่อแอพพลิเคชันบุคคลที่สามต้องการเข้าถึงข้อมูลพื้นฐานของผู้ใช้ แพลตฟอร์มต่าง ๆ (เช่น Google, Facebook, Twitter) ส่งคืนข้อมูลผู้ใช้ในรูปแบบที่แตกต่างกัน สร้างความท้าทายสำหรับนักพัฒนา

OIDC ถูกสร้างขึ้นเพื่อแก้ไขปัญหาเหล่านี้

บทบาทใน OIDC#

เพื่อเปิดใช้การตรวจสอบตัวตนของผู้ใช้บนฐานของ OAuth 2.0 และจัดการข้อจำกัด OIDC แนะนำสามบทบาท:

• ผู้ใช้ปลายทาง (End User - EU): ผู้ใช้สุดท้าย ที่สอดคล้องกับ Resource Owner ของ OAuth 2.0
• ฝ่ายพึ่งพิง (Relying Party - RP): ฝ่ายที่ขึ้นอยู่ สอดคล้องกับ Client ของ OAuth 2.0
• ผู้ให้บริการ OpenID (OpenID Provider - OP): ผู้ให้บริการการตรวจสอบตัวตน สอดคล้องกับ Authorization Server และ Resource Server ของ OAuth 2.0

OP คือบทบาทหลัก ให้ทั้งความสามารถในการอนุญาตของ OAuth 2.0 และพิจารณาข้อมูลผู้ใช้เป็นทรัพยากรแยกต่างหาก

OIDC ทำงานอย่างไร?#

กระบวนการตรวจสอบตัวของ OIDC คล้ายกับ OAuth 2.0 แต่เนื่องจาก OP รวมบทบาทของ Authorization Server และ Resource Server เข้าด้วยกัน จึงคืนรับทั้ง Access Token และ ID Token โดยที่ ID Token มีข้อมูลตัวตนของผู้ใช้ และ RP สามารถยืนยันตัวตนของผู้ใช้โดยตรวจสอบ ID Token

การทำงานทั่วไปมีลำดับขั้นตอนดังนี้:

นี้ทำให้มีมาตรฐานในการรับข้อมูลผู้ใช้จากแพลตฟอร์มต่าง ๆ กำจัดความจำเป็นที่แอพพลิเคชันบุคคลที่สามต้องจัดการกับความแตกต่างของแต่ละแพลตฟอร์ม

ID token (token ตัวตน) ใน OIDC#

เมื่อผู้ใช้อนุญาตแอพพลิเคชันบุคคลที่สาม OP จะส่งคืนทั้ง OAuth 2.0 Access Token และ JWT-format ID Token โดยที่ ID Token มีข้อมูลตัวตนของผู้ใช้ เช่น รหัสผู้ใช้ ชื่อผู้ใช้ อีเมล และภาพหน้าปก RP สามารถยืนยันตัวตนของผู้ใช้โดยตรวจสอบ ID Token

ในฐานะ JWT ID Token ประกอบไปด้วยข้อกล่าวมาตรฐาน ที่รวมถึงข้อกล่าวสำคัญดังต่อไปนี้:

• iss (Issuer): ตัวระบุที่ไม่ซ้ำของผู้ให้บริการ OpenID ที่ออก ID Token นี้
• sub (Subject): ตัวระบุที่ไม่ซ้ำของผู้ใช้
• aud (Audience): ตัวระบุของแอปพลิเคชันผู้ที่รับ ID Token นี้
• exp (Expiration Time): เวลาที่ ID Token หมดอายุ
• iat (Issued At): เวลาที่ ID Token ถูกออก

สำหรับข้อมูลรายละเอียดเกี่ยวกับ ID tokens, กรุณาดูที่: ID token.

Userinfo endpoint#

UserInfo Endpoint คือ HTTP API มาตรฐานที่ผู้ให้บริการ OP ให้เพื่อรับรายละเอียดผู้ใช้ที่ได้รับการตรวจสอบ โดยการส่งคำขอ GET หรือ POST พร้อม Access Token ไปยัง endpoint นี้ คุณสามารถรับข้อมูลผู้ใช้ในรูปแบบ JSON ได้ ข้อมูลที่ส่งคืนประกอบด้วยช่องที่มีมาตรฐานเช่น รหัสผู้ใช้ที่ไม่ซ้ำ (sub), ชื่อผู้ใช้ (name), อีเมล และภาพหน้าปก

กระบวนการรับ userinfo คล้ายกับการเข้าถึงทรัพยากรที่ได้รับการป้องกันใน OAuth 2.0 โดยทั่วไป ข้อมูลผู้ใช้ที่ได้รับจาก userinfo endpoint มักจะมีความหลากหลายมากกว่าข้อมูลที่อยู่ใน ID token เนื่องจาก ID token ส่วนใหญ่ให้บริการเพื่อการยืนยันตัวตนและข้อมูลผู้ใช้พื้นฐาน

สำหรับข้อมูลรายละเอียดเกี่ยวกับ Userinfo endpoint, กรุณาดูที่: Userinfo endpoint.

โปรดทราบว่าข้อมูลผู้ใช้ที่คุณได้รับจาก userinfo endpoint ขึ้นอยู่กับ scopes ที่ร้องขอและสิทธิ์ที่ได้รับในระหว่างการอนุญาต

Scopes ใน OIDC#

Scopes ใน OIDC กำหนดว่าข้อมูลผู้ใช้ที่ RP สามารถเข้าถึงได้ โดยที่ OIDC กำหนดขอบเขตมาตรฐาน โดยที่ขอบเขต openid เป็นสิ่งจำเป็นในกระบวนการตรวจสอบของ OIDC

ขอบเขตมาตรฐานทั่วไปประกอบด้วย:

• openid: ระบุคำขอการตรวจสอบ OIDC
• profile: ข้อมูลผู้ใช้พื้นฐานเช่น ชื่อและภาพหน้าปก
• email: ข้อมูลอีเมลของผู้ใช้
• phone: หมายเลขโทรศัพท์ของผู้ใช้
• address: ข้อมูลที่อยู่ของผู้ใช้

ขอบเขตที่แตกต่างกันส่งคืนข้อมูลผู้ใช้ที่แตกต่างกัน ตัวอย่างเช่นการร้องขอ openid profile email ส่งคืนข้อมูลผู้ใช้พื้นฐานและอีเมลใน ID Token และ Userinfo ในขณะที่ openid profile email phone address รวมถึงหมายเลขโทรศัพท์และข้อมูลที่อยู่ด้วย

การจัดการตัวตนที่ใช้ OIDC#

OIDC ไม่ได้เป็นเพียงโปรโตคอลการตรวจสอบตัวตน; มันเป็นเครื่องมือที่มีศักยภาพในการสร้างระบบการจัดการตัวตนที่ยืดหยุ่นและขยายได้ โดยการเพิ่มชั้นตรวจสอบตัวตนให้กับ OAuth 2.0 มาตรฐานทรัพยากรข้อมูลผู้ใช้ และวางรากฐานสำหรับฟีเจอร์การจัดการตัวตนที่ขยายได้ OIDC ช่วยให้เกิดสถานการณ์การจัดการตัวตนต่าง ๆ :

• Single Sign-On (SSO): OIDC สนับสนุน SSO โดยธรรมชาติผ่านข้อมูลเซสชันผู้ใช้ที่ขยาย ทำให้สามารถจัดการสถานะการเข้าสู่ระบบร่วมกันและการแชร์ตัวตนข้ามแอปพลิเคชัน
• การจัดการโครงสร้างองค์กร: ข้อมูลโครงสร้างองค์กรของผู้ใช้ที่ขยายสามารถจัดการโครงสร้างองค์กรที่ซับซ้อน รวมถึงลำดับชั้นของแผนกและความสัมพันธ์ของกลุ่มผู้ใช้
• การจัดการสิทธิ์: คุณลักษณะสิทธิ์ของผู้ใช้ที่ขยายช่วยในการควบคุมการเข้าถึงทรัพยากรที่ละเอียด รวมถึงข้อมูลของบทบาทและการกำหนดค่ากฎการอนุญาต

ความยืดหยุ่นของ OIDC ปรับตัวให้เข้ากับความต้องการการจัดการตัวตนที่พัฒนาไปได้ดี หลายระบบการจัดการตัวตนถูกสร้างบน OIDC เช่น Logto ที่มีฟีเจอร์ SSO, การจัดการองค์กร และการจัดการสิทธิ์