ไทย

iam
oauth
openid-connect
saml
sso
jwt

ทำความเข้าใจกับ IAM, OAuth, OpenID Connect, SAML, SSO, และ JWT ในบทความเดียว

โลกของการจัดการข้อมูลประจำตัวและการเข้าถึง (IAM) อาจรู้สึกซับซ้อนและสร้างความสับสนได้ แต่ไม่ต้องกังวล - บทความนี้จะอธิบายพื้นฐานของพวกเขาเพื่อช่วยให้คุณมองเห็นภาพรวมและนำทางในสาขาที่ซับซ้อนนี้ได้อย่างมั่นใจ

Gao

Founder

11/23/2024

หยุดเสียเวลาเป็นสัปดาห์กับการยืนยันตัวตนผู้ใช้

เปิดตัวแอปที่ปลอดภัยเร็วขึ้นด้วย Logto ผสานการยืนยันตัวตนผู้ใช้ภายในไม่กี่นาทีและมุ่งเน้นที่ผลิตภัณฑ์หลักของคุณ

เริ่มต้นใช้งาน

ขอบเขตของ การจัดการข้อมูลประจำตัวและการเข้าถึง (IAM) เติบโตขึ้นอย่างซับซ้อนมากขึ้นในช่วงไม่กี่ปีที่ผ่านมา คำศัพท์ที่หรูหราเช่น OAuth, OpenID Connect (OIDC), SAML, SSO, และ JWT ถูกใช้บ่อย แต่พวกมันหมายถึงอะไร พวกมันทำงานร่วมกันอย่างไร ลองสำรวจแนวคิดและกรอบการทำงานเหล่านี้เพื่อทำให้พวกมันเข้าใจได้และใช้งานได้จริงมากขึ้น

IAM คืออะไร?

การจัดการข้อมูลประจำตัวและการเข้าถึง (IAM) เป็นแนวคิดที่กว้างขวางที่เกี่ยวข้องกับการจัดการ ข้อมูลประจำตัว ดิจิทัลและการนำ การควบคุมการเข้าถึง มาใช้ กรอบการทำงานและโปรโตคอลที่กล่าวถึงข้างต้นอยู่ภายใต้ IAM แต่ละข้อแก้ไขปัญหาเฉพาะในพื้นที่นี้

โดยสาระสำคัญ IAM เกี่ยวกับ:

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

ในแผนภาพด้านบน ผู้ใช้ (ข้อมูลประจำตัว) ต้องการดำเนินการคำขอ GET กับ API (ทรัพยากร) แอตทริบิวต์ของผู้ใช้ - ชื่อ, อีเมล, และบทบาท - อธิบายข้อมูลประจำตัว

การตรวจสอบตัวตนกับการให้อำนาจ

การตรวจสอบตัวตนและการให้อำนาจมักปรากฏควบคู่กันในการสนทนา IAM ลองทำให้ความหมายของพวกมันชัดเจน:

การตรวจสอบตัวตน: กระบวนการยืนยันความเป็นเจ้าของข้อมูลประจำตัว มันตอบคำถามว่า "คุณเป็นใคร?"
การให้อำนาจ: กระบวนการกำหนดว่าการกระทำใดที่ข้อมูลประจำตัวที่ได้รับการตรวจสอบสามารถดำเนินการกับทรัพยากรได้ มันตอบคำถามว่า “คุณทำอะไรได้บ้าง?”

ในตัวอย่างก่อนหน้า:

ก่อนที่ผู้ใช้ (ข้อมูลประจำตัว) จะสามารถดำเนินการใด ๆ ได้ พวกเขาจะต้องทำกระบวนการ การตรวจสอบตัวตน ให้เสร็จสมบูรณ์
หลังจากการตรวจสอบตัวตน ระบบจำเป็นต้องกำหนดว่าผู้ใช้สามารถดำเนินการคำขอ GET (การกระทำ) บน API (ทรัพยากร) ได้หรือไม่ คือทำการประมวลผล การให้อำนาจ ให้สมบูรณ์

ด้วยความรู้พื้นฐานนี้แล้ว ลองทำให้ตัวย่อและโปรโตคอลอื่น ๆ ไม่ยุ่งยากอีกต่อไป

OAuth

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

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

นี่คือแผนภาพที่ย่อยง่ายที่แสดงขั้นตอนของ OAuth:

ในขั้นตอนนี้:

MyApp เป็นไคลเอ็นต์ (ข้อมูลประจำตัว) ที่ขอเข้าถึง Google Drive (ทรัพยากร)
ผู้ใช้ (เจ้าของทรัพยากร) อนุญาต MyApp ในขั้นตอนที่ 6 ทำให้กระบวนการ การให้อำนาจ สมบูรณ์

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

OpenID Connect (OIDC)

OpenID Connect (OIDC) เป็นชั้น การตรวจสอบตัวตน ที่สร้างขึ้นบน OAuth 2.0 มันเพิ่มคุณสมบัติที่เฉพาะเจาะจงสำหรับการตรวจสอบตัวตน เช่น ID tokens และ UserInfo endpoint ทำให้เหมาะสำหรับการตรวจสอบตัวตนและการให้อำนาจ

หากเรากลับไปดูขั้นตอนของ OAuth การเพิ่ม OIDC จะเพิ่ม ID token ซึ่งมีข้อมูลเกี่ยวกับผู้ใช้ที่ได้รับการตรวจสอบและช่วยให้ MyApp สามารถตรวจสอบตัวตนของผู้ใช้ได้

สถานการณ์ตัวอย่าง: "ล็อกอินด้วย Google"

ลองเปลี่ยนตัวอย่างกัน หาก MyApp ต้องการให้ผู้ใช้สามารถล็อกอินโดยใช้บัญชี Google ของพวกเขาได้ จุดประสงค์เปลี่ยนไปยังการตรวจสอบตัวตนแทนการเข้าถึงทรัพยากร ในกรณีนี้ OIDC เหมาะสมกว่า นี่คือวิธีการทำงานของ OIDC:

แตกต่างหลัก: นอกจากโทเค็นการเข้าถึงแล้ว OIDC ยังให้ ID token ซึ่งช่วยให้ MyApp ทำการตรวจสอบตัวตนของผู้ใช้ได้โดยไม่ต้องทำการร้องขอเพิ่มเติม

OIDC แบ่งปันการกำหนด การให้สิทธิ์ ของ OAuth 2.0 เพื่อให้เกิดความเข้ากันได้และความคงเส้นคงวาผ่านสองกรอบการทำงาน

SAML

Security Assertion Markup Language (SAML) เป็นกรอบ XML สำหรับการแลกเปลี่ยนข้อมูล การตรวจสอบตัวตน และ การให้อำนาจ ระหว่างฝ่ายต่าง ๆ SAML ถูกนำเข้าใช้ในต้นปี 2000 และได้รับการใช้แพร่หลายในสิ่งแวดล้อมขององค์กร

SAML และ OIDC เปรียบเทียบกันอย่างไร?

SAML และ OIDC มีหน้าที่คล้ายกันแต่แตกต่างในรายละเอียดการดำเนินงาน:

SAML: ใช้การยืนยันแบบ XML และมักถูกพิจารณาซับซ้อนมากขึ้น
OIDC: ใช้ JSON และ JWT ซึ่งเบาและเป็นมิตรกับนักพัฒนามากกว่า

แอปพลิเคชันทันสมัยมักชื่นชอบ OIDC สำหรับความเรียบง่ายและความยืดหยุ่นของมัน แต่ SAML ยังคงมีความแพร่หลายในระบบเก่าและการใช้งานในองค์กร

Single sign-on (SSO)

Single sign-on (SSO) เป็นโครงสร้าง การตรวจสอบตัวตน ที่ช่วยให้ผู้ใช้สามารถเข้าถึงแอปพลิเคชันและบริการหลาย ๆ อย่างด้วยข้อมูลประจำตัวชุดเดียว แทนที่จะต้องล็อกอินเข้าแต่ละแอปพลิเคชันทีละอัน ผู้ใช้จะล็อกอินครั้งเดียวและสามารถเข้าถึงทุกระบบที่เชื่อมต่อได้

SSO ทำงานอย่างไร?

SSO อาศัย ผู้ให้บริการข้อมูลประจำตัว (IdP) เป็นศูนย์กลางในการจัดการข้อมูลประจำตัวผู้ใช้ IdP ตรวจสอบตัวตนของผู้ใช้และให้บริการเช่นการตรวจสอบตัวตนและการให้อำนาจแก๋แอปพลิเคชันที่เชื่อมต่อ

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

ตัวอย่างของ OIDC-Based SSO

ลองสำรวจตัวอย่างของ OIDC-based SSO:

ในขั้นตอนนี้ ผู้ใช้ล็อกอินเข้า IdP ครั้งเดียวและได้รับการตรวจสอบผ่านแอปพลิเคชันหลายอัน (AppA และ AppB)

Enterprise SSO

ในขณะที่ SSO เป็นแนวคิดที่กว้าง คุณอาจพบคำว่า enterprise SSO ซึ่งหมายถึง SSO ประเภทที่ออกแบบมาเพื่อตอบสนองสิ่งแวดล้อมองค์กร (โดยทั่วไปสำหรับพนักงานและพันธมิตร)

เมื่อลูกค้าขอ SSO สำหรับแอปพลิเคชันของคุณ มันสำคัญที่จะชี้แจงความต้องการของพวกเขาและโปรโตคอลที่พวกเขาใช้ ในหลายกรณีนี้หมายความว่าสำหรับโดเมนของอีเมลที่เฉพาะเจาะจง พวกเขาต้องการให้แอปพลิเคชันของคุณเปลี่ยนเส้นทางผู้ใช้ไปยัง IdP ของพวกเขา (ซึ่งมีการประยุกต์ใช้ enterprise SSO) สำหรับการตรวจสอบตัวตน

ตัวอย่าง: การเพิ่มผู้ให้บริการ Enterprise SSO

นี่คือตัวอย่างที่ย่อยง่ายของการรวมผู้ให้บริการ enterprise SSO (Banana) กับแอปพลิเคชันของคุณ (MyApp):

JWT

JSON Web Token (JWT) เป็นมาตรฐานเปิดที่กำหนดใน RFC 7519 ที่ช่วยให้การสื่อสารที่ปลอดภัยระหว่างทั้งสองฝ่าย เป็นรูปแบบมาตรฐานสำหรับ ID tokens ใน OIDC และใช้แพร่หลายใน OAuth 2.0 สำหรับโทเค็นการเข้าถึง

ลักษณะสำคัญของ JWT:

กะทัดรัด: JWT เป็นวัตถุ JSON ที่ถูกเข้ารหัสในรูปแบบกะทัดรัด ทำให้ง่ายต่อการส่งและจัดเก็บ
บรรจุข้อมูลในตัวเอง: JWT มีข้อมูลทั้งหมดที่จำเป็นเกี่ยวกับผู้ใช้และตัวโทเค็นเอง
สามารถตรวจสอบและเข้ารหัสได้: JWT สามารถถูกเซ็นและเข้ารหัสเพื่อให้มั่นใจในความสมบูรณ์ของข้อมูลและการรักษาความลับ

JWT ปกติดูเหมือนนี้:

JWT นี้ประกอบด้วยสามส่วนแบ่งด้วยจุด:

Header: มีข้อมูลเมตาเกี่ยวกับโทเค็น เช่น ชนิดของโทเค็นและอัลกอริทึมการเซ็น
Payload: มีข้อมูลเกี่ยวกับข้อมูลประจำตัวและตัวโทเค็นเอง
Signature: ตรวจสอบความสมบูรณ์ของโทเค็น

ทั้ง Header และ Payload ถูกเข้ารหัสเป็นวัตถุ JSON แบบ base64 โทเค็น JWT ที่อยู่ข้างบนสามารถถอดรหัสได้ดังนี้:

ด้วยการใช้ JWT ไคลเอ็นต์สามารถถอดรหัสโทเค็นและดึงข้อมูลผู้ใช้ได้โดยไม่ต้องทำการร้องขอเพิ่มเติมกับผู้ให้บริการข้อมูลประจำตัว เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับ JWT เยี่ยมชม JSON Web Token (JWT)

Recap

เราได้ครอบคลุมเนื้อหามากมายในบทความนี้ มาสรุปประเด็นสำคัญด้วยตัวอย่าง:

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

เพื่อให้เกิดความสะดวกสำหรับผู้ใช้ของคุณ คุณเปิดใช้งาน "ล็อกอินด้วย Google" ใน Logto ซึ่งใช้ OAuth 2.0 เพื่อแลกเปลี่ยนข้อมูลการให้อำนาจและข้อมูลผู้ใช้ระหว่าง Logto และ Google

หลังจากที่ผู้ใช้ล็อกอินเข้า AppA ผ่าน Logto แล้ว AppA ได้รับ ID token, ซึ่งเป็น JSON Web Token (JWT) ที่มีข้อมูลผู้ใช้

เมื่อธุรกิจของคุณเติบโตขึ้น คุณจะเปิดตัวแอปพลิเคชันใหม่, AppB, ที่ต้องมีการตรวจสอบผู้ใช้เช่นกัน เนื่องจาก Logto ถูกตั้งค่าเรียบร้อยแล้ว คุณสามารถใช้การตรวจสอบผู้ใช้แบบเดียวกันสำหรับ AppB ได้ ผู้ใช้ของคุณสามารถล็อกอินเข้า AppA และ AppB ด้วยข้อมูลประจำตัวชุดเดียว, ซึ่งเป็นคุณลักษณะที่เรียกว่า การลงชื่อเข้าใช้ครั้งเดียว (SSO)

ต่อมา พันธมิตรทางธุรกิจขอให้คุณเชื่อมต่อระบบ SSO องค์กรของพวกเขาซึ่งใช้ Security Assertion Markup Language (SAML) คุณพบว่า Logto สนับสนุนการเชื่อมต่อ SAML, ดังนั้นคุณตั้งค่าการเชื่อมต่อระหว่าง Logto กับระบบ SSO ของพันธมิตร ตอนนี้ ผู้ใช้จากองค์กรของพันธมิตรสามารถเข้าสู่ AppA และ AppB ได้ด้วยข้อมูลประจำตัวที่มีอยู่

ฉันหวังว่าบทความนี้จะทำให้แนวคิดเหล่านี้ชัดเจนสำหรับคุณ สำหรับการอธิบายแบบเชิงลึกและตัวอย่างเพิ่มเติม โปรดตรวจสอบ Auth Wiki หากคุณกำลังค้นหาโซลูชัน IAM สำหรับแอปพลิเคชันของคุณ ลองใช้บริการที่ได้รับการจัดการเช่น Logto เพื่อประหยัดเวลาและความพยายาม

ลองใช้ Logto Cloud ฟรี

IAM คืออะไร?#

การตรวจสอบตัวตนกับการให้อำนาจ#

OAuth#

OpenID Connect (OIDC)#

สถานการณ์ตัวอย่าง: "ล็อกอินด้วย Google"#

SAML#

SAML และ OIDC เปรียบเทียบกันอย่างไร?#

Single sign-on (SSO)#

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

ตัวอย่างของ OIDC-Based SSO#

Enterprise SSO#

ตัวอย่าง: การเพิ่มผู้ให้บริการ Enterprise SSO#

JWT#

Recap#

IAM คืออะไร?#

การตรวจสอบตัวตนกับการให้อำนาจ#

OAuth#

OpenID Connect (OIDC)#

สถานการณ์ตัวอย่าง: "ล็อกอินด้วย Google"#

SAML#

SAML และ OIDC เปรียบเทียบกันอย่างไร?#

Single sign-on (SSO)#

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

ตัวอย่างของ OIDC-Based SSO#

Enterprise SSO#

ตัวอย่าง: การเพิ่มผู้ให้บริการ Enterprise SSO#

JWT#

Recap#

IAM คืออะไร?

การตรวจสอบตัวตนกับการให้อำนาจ

OAuth

OpenID Connect (OIDC)

สถานการณ์ตัวอย่าง: "ล็อกอินด้วย Google"

SAML

SAML และ OIDC เปรียบเทียบกันอย่างไร?

Single sign-on (SSO)

SSO ทำงานอย่างไร?

ตัวอย่างของ OIDC-Based SSO

Enterprise SSO

ตัวอย่าง: การเพิ่มผู้ให้บริการ Enterprise SSO

JWT

Recap

IAM คืออะไร?

การตรวจสอบตัวตนกับการให้อำนาจ

OAuth

OpenID Connect (OIDC)

สถานการณ์ตัวอย่าง: "ล็อกอินด้วย Google"

SAML

SAML และ OIDC เปรียบเทียบกันอย่างไร?

Single sign-on (SSO)

SSO ทำงานอย่างไร?

ตัวอย่างของ OIDC-Based SSO

Enterprise SSO

ตัวอย่าง: การเพิ่มผู้ให้บริการ Enterprise SSO

JWT

Recap