บันทึก. แปล: บทความดีๆ นี้จาก Okta อธิบายว่า OAuth และ OIDC (OpenID Connect) ทำงานอย่างไรด้วยวิธีที่ง่ายและชัดเจน ความรู้นี้จะเป็นประโยชน์กับนักพัฒนา ผู้ดูแลระบบ และแม้แต่ "ผู้ใช้ทั่วไป" ของเว็บแอปพลิเคชันยอดนิยม ซึ่งมีแนวโน้มที่จะแลกเปลี่ยนข้อมูลที่ละเอียดอ่อนกับบริการอื่นๆ
ในยุคหินของอินเทอร์เน็ต การแบ่งปันข้อมูลระหว่างบริการต่างๆ เป็นเรื่องง่าย คุณเพียงให้ข้อมูลเข้าสู่ระบบและรหัสผ่านจากบริการหนึ่งไปยังอีกบริการหนึ่ง เพื่อให้เขาป้อนบัญชีของคุณและรับข้อมูลที่ต้องการ
"เอาบัญชีธนาคารของคุณมาให้ฉัน" “เราสัญญาว่าทุกอย่างจะเรียบร้อยดีด้วยรหัสผ่านและเงิน ตรงไปตรงมา ซื่อสัตย์!" *ฮิฮิ*
สยองขวัญ! ไม่มีใครควรกำหนดให้ผู้ใช้เปิดเผยชื่อผู้ใช้และรหัสผ่าน ข้อมูลรับรองกับอีกหนึ่งบริการ ไม่มีการรับประกันว่าองค์กรที่อยู่เบื้องหลังบริการนี้จะรักษาความปลอดภัยของข้อมูลและจะไม่รวบรวมข้อมูลส่วนบุคคลมากเกินความจำเป็น อาจฟังดูบ้า แต่บางแอปยังคงใช้แนวทางปฏิบัตินี้อยู่!
วันนี้มีมาตรฐานเดียวที่อนุญาตให้บริการหนึ่งใช้ข้อมูลของอีกบริการได้อย่างปลอดภัย น่าเสียดายที่มาตรฐานดังกล่าวใช้ศัพท์แสงและคำศัพท์มากมาย ซึ่งทำให้เข้าใจยาก จุดประสงค์ของเนื้อหานี้คือเพื่ออธิบายวิธีทำงานโดยใช้ภาพประกอบง่ายๆ (คิดว่าภาพวาดของฉันดูเหมือนการระบายสีของเด็กๆ เหรอ อืม!)
อย่างไรก็ตาม คู่มือนี้มีให้ในรูปแบบวิดีโอด้วย:
ท่านสุภาพบุรุษและสุภาพสตรี ยินดีต้อนรับ: OAuth 2.0
เป็นมาตรฐานความปลอดภัยที่อนุญาตให้แอปพลิเคชันหนึ่งได้รับสิทธิ์ในการเข้าถึงข้อมูลในอีกแอปพลิเคชันหนึ่ง ลำดับขั้นตอนการออกใบอนุญาต [การอนุญาต] (หรือ ยินยอม [ยินยอม]) มักจะโทร การอนุญาต [การอนุญาต] หรือ ที่ได้รับมอบอำนาจ [มอบอำนาจ]. ด้วยมาตรฐานนี้ คุณอนุญาตให้แอปพลิเคชันอ่านข้อมูลหรือใช้ฟังก์ชันของแอปพลิเคชันอื่นในนามของคุณโดยไม่ต้องให้รหัสผ่าน ระดับ!
ตัวอย่างเช่น สมมติว่าคุณค้นพบไซต์ที่ชื่อว่า "Unlucky Pun of the Day" [ปุนแย่ของวัน] และตัดสินใจที่จะลงทะเบียนเพื่อรับการเล่นรายวันในรูปแบบของข้อความทางโทรศัพท์ คุณชอบไซต์นี้มาก และคุณตัดสินใจที่จะแบ่งปันกับเพื่อนๆ ทุกคน ท้ายที่สุดแล้วทุกคนชอบการเล่นที่น่าขนลุกใช่ไหม?
“โชคร้ายของวันนี้: ได้ยินเกี่ยวกับผู้ชายที่สูญเสียร่างกายซีกซ้ายไปหรือเปล่า? ตอนนี้เขาพูดถูกเสมอ!” (การแปลโดยประมาณ เนื่องจากต้นฉบับมีการเล่นสำนวนของตัวเอง - การแปลโดยประมาณ)
เป็นที่ชัดเจนว่าการเขียนถึงแต่ละคนจากรายชื่อผู้ติดต่อไม่ใช่ตัวเลือก และถ้าคุณเป็นเหมือนฉันแม้แต่นิดเดียว คุณจะทำทุกอย่างเพื่อหลีกเลี่ยงงานที่ไม่จำเป็น โชคดีที่ Terrible Pun of the Day สามารถเชิญเพื่อนของคุณทั้งหมดได้ด้วยตัวมันเอง! ในการทำเช่นนี้ คุณเพียงแค่เปิดการเข้าถึงอีเมลของผู้ติดต่อของคุณ - ไซต์จะส่งคำเชิญให้พวกเขาเอง (กฎ OAuth)!
“ใครๆ ก็ชอบเล่นสำนวน! - เข้าสู่ระบบแล้ว? “คุณต้องการอนุญาตให้เว็บไซต์ Terrible Pun of the Day เข้าถึงรายชื่อผู้ติดต่อของคุณหรือไม่? - ขอบคุณ! จากนี้ไป เราจะส่งการแจ้งเตือนทุกวันไปยังทุกคนที่คุณรู้จัก จนกว่าจะหมดเวลา! คุณเป็นเพื่อนที่ดีที่สุด!"
- เลือกบริการอีเมลของคุณ
- หากจำเป็น ให้ไปที่ไซต์อีเมลและลงชื่อเข้าใช้บัญชีของคุณ
- ให้สิทธิ์ Terrible Pun of the Day ในการเข้าถึงผู้ติดต่อของคุณ
- กลับไปที่เว็บไซต์ Terrible Pun of the Day
ในกรณีที่คุณเปลี่ยนใจ แอปพลิเคชันที่ใช้ OAuth ยังมีวิธีเพิกถอนการเข้าถึงอีกด้วย เมื่อคุณตัดสินใจว่าไม่ต้องการแบ่งปันผู้ติดต่อกับ Terrible Pun of the Day อีกต่อไป คุณสามารถไปที่ไซต์อีเมลและลบไซต์ pun ออกจากรายการแอปพลิเคชันที่ได้รับอนุญาต
โฟลว์ OAuth
เราเพิ่งผ่านสิ่งที่เรียกว่า ไหล [ไหล] OAuth ในตัวอย่างของเรา โฟลว์นี้ประกอบด้วยขั้นตอนที่มองเห็นได้ รวมถึงขั้นตอนที่มองไม่เห็นหลายขั้นตอน ซึ่งสองบริการตกลงในการแลกเปลี่ยนข้อมูลอย่างปลอดภัย ตัวอย่าง Terrible Pun of the Day ก่อนหน้านี้ใช้โฟลว์ OAuth 2.0 ที่พบบ่อยที่สุด ซึ่งเรียกว่าโฟลว์ "รหัสการให้สิทธิ์" [โฟลว์ "รหัสการให้สิทธิ์"].
ก่อนที่จะลงลึกในรายละเอียดเกี่ยวกับวิธีการทำงานของ OAuth เรามาพูดถึงความหมายของคำศัพท์บางคำกัน:
- เจ้าของทรัพยากร:
มันคือคุณ! คุณเป็นเจ้าของข้อมูลประจำตัว ข้อมูลของคุณ และควบคุมกิจกรรมทั้งหมดที่อาจดำเนินการในบัญชีของคุณ - ไคลเอนต์:
แอปพลิเคชัน (เช่น บริการ Terrible Pun of the Day) ที่ต้องการเข้าถึงหรือดำเนินการบางอย่างในนามของ เจ้าของทรัพยากรก. - เซิร์ฟเวอร์การอนุญาต:
แอปพลิเคชั่นที่รู้ เจ้าของทรัพยากร'a และที่คุณ เจ้าของทรัพยากร'มีบัญชีอยู่แล้ว - เซิร์ฟเวอร์ทรัพยากร:
Application Programming Interface (API) หรือบริการที่ ไคลเอนต์ ต้องการใช้ในนาม เจ้าของทรัพยากรก. - เปลี่ยนเส้นทาง URI:
ลิงค์ที่ว่า เซิร์ฟเวอร์การอนุญาต จะเปลี่ยนเส้นทาง เจ้าของทรัพยากร'และหลังจากอนุญาตแล้ว ไคลเอนต์'ที่. บางครั้งเรียกว่า "Callback URL" - ประเภทการตอบกลับ:
ประเภทของข้อมูลที่คาดว่าจะได้รับ ไคลเอนต์. ที่พบมากที่สุด ประเภทการตอบกลับ'โอห์มคือรหัสนั่นคือ ไคลเอนต์ คาดว่าจะได้รับ รหัสอนุญาต. - ขอบเขต:
นี่คือคำอธิบายโดยละเอียดของการอนุญาตที่จำเป็น ไคลเอนต์'y เช่น การเข้าถึงข้อมูลหรือดำเนินการบางอย่าง - ความยินยอม:
เซิร์ฟเวอร์การอนุญาต หมวกผ้าไม่มีปีก ขอบเขตร้องขอ ไคลเอนต์'อ้อมและถาม เจ้าของทรัพยากร'a, เขาพร้อมที่จะให้ ไคลเอนต์'มีสิทธิ์ที่เหมาะสม - รหัสลูกค้า:
ID นี้ใช้เพื่อระบุตัวตน ไคลเอนต์'บน เซิร์ฟเวอร์การอนุญาต'จ. - ความลับของลูกค้า:
นี่คือรหัสผ่านที่รู้เท่านั้น ไคลเอนต์'คุณและ เซิร์ฟเวอร์การอนุญาต'ที่. อนุญาตให้แบ่งปันข้อมูลเป็นการส่วนตัว - รหัสอนุญาต:
รหัสชั่วคราวที่มีอายุการใช้งานสั้นซึ่ง ไคลเอนต์ ให้ เซิร์ฟเวอร์การอนุญาตเพื่อแลกกับ การเข้าถึง Token. - การเข้าถึง Token:
คีย์ที่ลูกค้าจะใช้ในการสื่อสารด้วย เซิร์ฟเวอร์ทรัพยากรอ้อม ประเภทของป้ายหรือคีย์การ์ดที่ให้ ไคลเอนต์'ได้รับอนุญาตให้ขอข้อมูลหรือดำเนินการกับ เซิร์ฟเวอร์ทรัพยากรอีในนามของคุณ
หมายเหตุ: บางครั้ง Authorization Server และ Resource Server เป็นเซิร์ฟเวอร์เดียวกัน อย่างไรก็ตาม ในบางกรณี สิ่งเหล่านี้อาจเป็นเซิร์ฟเวอร์ที่แตกต่างกัน แม้ว่าจะไม่ได้อยู่ในองค์กรเดียวกันก็ตาม ตัวอย่างเช่น Authorization Server อาจเป็นบริการของบุคคลที่สามที่ Resource Server เชื่อถือ
ตอนนี้เราได้กล่าวถึงแนวคิดหลักของ OAuth 2.0 แล้ว ลองกลับไปที่ตัวอย่างของเราและดูสิ่งที่เกิดขึ้นในโฟลว์ OAuth ให้ละเอียดยิ่งขึ้น
- คุณ, เจ้าของทรัพยากรคุณต้องการให้บริการ Terrible Pun of the Day (ไคลเอนต์y) เข้าถึงผู้ติดต่อของคุณเพื่อให้พวกเขาสามารถส่งคำเชิญไปยังเพื่อนของคุณทั้งหมด
- ไคลเอนต์ เปลี่ยนเส้นทางเบราว์เซอร์ไปยังหน้า เซิร์ฟเวอร์การอนุญาต'a และรวมไว้ในแบบสอบถาม รหัสลูกค้า, เปลี่ยนเส้นทาง URI, ประเภทการตอบกลับ และอย่างน้อยหนึ่งรายการ ขอบเขต (สิทธิ์) มันต้องการ
- เซิร์ฟเวอร์การอนุญาต ยืนยันตัวคุณโดยขอชื่อผู้ใช้และรหัสผ่านหากจำเป็น
- เซิร์ฟเวอร์การอนุญาต แสดงแบบฟอร์ม ความยินยอม (confirmations) พร้อมรายชื่อทั้งหมด ขอบเขตร้องขอ ไคลเอนต์อ้อม คุณตกลงหรือปฏิเสธ
- เซิร์ฟเวอร์การอนุญาต เปลี่ยนเส้นทางคุณไปยังไซต์ ไคลเอนต์'a, ใช้ เปลี่ยนเส้นทาง URI พร้อมกับ รหัสอนุญาต (รหัสอนุญาต).
- ไคลเอนต์ สื่อสารโดยตรงกับ เซิร์ฟเวอร์การอนุญาต'ohm (ข้ามเบราว์เซอร์ เจ้าของทรัพยากร'a) และส่งอย่างปลอดภัย รหัสลูกค้า, ความลับของลูกค้า и รหัสอนุญาต.
- เซิร์ฟเวอร์การอนุญาต ตรวจสอบข้อมูลและตอบกลับด้วย การเข้าถึง Token'om (โทเค็นการเข้าถึง)
- ขณะนี้ ไคลเอนต์ สามารถใช้ การเข้าถึง Token เพื่อส่งคำขอไปที่ เซิร์ฟเวอร์ทรัพยากร เพื่อรับรายชื่อผู้ติดต่อ
รหัสลูกค้าและความลับ
นานมาแล้วก่อนที่คุณจะอนุญาตให้ Terrible Pun of the Day เข้าถึงผู้ติดต่อของคุณ Client และ Authorization Server ได้สร้างความสัมพันธ์ในการทำงาน Authorization Server สร้าง Client ID และ Client Secret (บางครั้งเรียกว่า App ID и ความลับของแอพ) และส่งไปยังไคลเอ็นต์เพื่อการโต้ตอบเพิ่มเติมภายใน OAuth
"- สวัสดี! ฉันต้องการร่วมงานกับคุณ! - แน่นอน ไม่มีปัญหา! นี่คือรหัสลูกค้าและความลับของคุณ!”
ชื่อมีความหมายว่าต้องเก็บความลับของไคลเอ็นต์ไว้เป็นความลับเพื่อให้ไคลเอนต์และเซิร์ฟเวอร์การอนุญาตเท่านั้นที่รู้ ท้ายที่สุดด้วยความช่วยเหลือของเขาที่ Authorization Server ยืนยันความจริงของลูกค้า
แต่นั่นไม่ใช่ทั้งหมด... โปรดยินดีต้อนรับ OpenID Connect!
OAuth 2.0 ออกแบบมาสำหรับ การอนุญาต - เพื่อให้การเข้าถึงข้อมูลและฟังก์ชันจากแอปพลิเคชันหนึ่งไปยังอีกแอปพลิเคชันหนึ่ง (OIDC) เป็นเลเยอร์บางๆ ที่ด้านบนของ OAuth 2.0 ที่เพิ่มรายละเอียดการเข้าสู่ระบบและโปรไฟล์ของผู้ใช้ที่ลงชื่อเข้าใช้บัญชี องค์กรของเซสชันการเข้าสู่ระบบมักถูกเรียกว่า การรับรองความถูกต้อง [การรับรองความถูกต้อง]และข้อมูลเกี่ยวกับผู้ใช้ที่เข้าสู่ระบบ (เช่น about เจ้าของทรัพยากร'จ), — ข้อมูลส่วนบุคคล [ตัวตน]. หาก Authorization Server รองรับ OIDC บางครั้งจะเรียกว่า ผู้ให้บริการข้อมูลส่วนบุคคล [ผู้ให้บริการข้อมูลประจำตัว]เพราะมันให้ ไคลเอนต์'มีข้อมูลเกี่ยวกับ เจ้าของทรัพยากร'จ.
OpenID Connect ช่วยให้คุณสามารถใช้สถานการณ์ที่สามารถใช้การเข้าสู่ระบบเพียงครั้งเดียวในหลายๆ แอปพลิเคชัน วิธีการนี้เรียกอีกอย่างว่า เข้าสู่ระบบเดียวใน (สป.). ตัวอย่างเช่น แอปพลิเคชันอาจรองรับการรวม SSO กับโซเชียลเน็ตเวิร์ก เช่น Facebook หรือ Twitter ทำให้ผู้ใช้สามารถใช้บัญชีที่ตนมีอยู่แล้วและต้องการใช้
โฟลว์ (โฟลว์) OpenID Connect มีลักษณะเหมือนกับในกรณีของ OAuth ข้อแตกต่างเพียงอย่างเดียวคือในคำขอหลัก ขอบเขตเฉพาะที่ใช้คือ openid,-อ ไคลเอนต์ ในที่สุดก็ถูกใจ การเข้าถึง Tokenและ โทเค็น ID.
เช่นเดียวกับในโฟลว์ OAuth การเข้าถึง Token ใน OpenID Connect นี่คือค่าบางอย่างที่ไม่ชัดเจน ไคลเอนต์'ที่. จากมุมมอง ไคลเอนต์'а การเข้าถึง Token แสดงถึงสตริงของอักขระที่ส่งผ่านไปพร้อมกับคำขอแต่ละรายการ เซิร์ฟเวอร์ทรัพยากร'y ซึ่งกำหนดว่าโทเค็นนั้นถูกต้องหรือไม่ โทเค็น ID แสดงถึงสิ่งที่แตกต่างไปจากเดิมอย่างสิ้นเชิง
ID Token คือ JWT
โทเค็น ID เป็นสตริงอักขระที่มีรูปแบบพิเศษที่เรียกว่า JSON Web Token หรือ JWT (บางครั้งโทเค็น JWT จะออกเสียงเหมือน "jots"). สำหรับผู้สังเกตการณ์ภายนอก JWT อาจดูเหมือนพูดพล่อยๆ ที่เข้าใจยาก แต่ ไคลเอนต์ สามารถดึงข้อมูลต่างๆ จาก JWT เช่น ID, ชื่อผู้ใช้, เวลาเข้าสู่ระบบ, วันหมดอายุ โทเค็น ID'a การปรากฏตัวของความพยายามที่จะแทรกแซง JWT ข้อมูลภายใน โทเค็น ID'จะเรียกว่า แอพพลิเคชั่น [การอ้างสิทธิ์].
ในกรณีของ OIDC ก็มีวิธีมาตรฐานเช่นกัน ไคลเอนต์ อาจขอข้อมูลเพิ่มเติมเกี่ยวกับบุคคล [ตัวตน] จาก เซิร์ฟเวอร์การอนุญาต'a ตัวอย่างเช่น ที่อยู่อีเมลที่ใช้ การเข้าถึง Token.
เรียนรู้เพิ่มเติมเกี่ยวกับ OAuth และ OIDC
ดังนั้นเราจึงทบทวนสั้นๆ ว่า OAuth และ OIDC ทำงานอย่างไร พร้อมเจาะลึกหรือยัง? ต่อไปนี้เป็นทรัพยากรเพิ่มเติมที่จะช่วยให้คุณเรียนรู้เพิ่มเติมเกี่ยวกับ OAuth 2.0 และ OpenID Connect:
เช่นเคย อย่าลังเลที่จะแสดงความคิดเห็น หากต้องการติดตามข่าวสารล่าสุดของเรา สมัครสมาชิก и Okta สำหรับนักพัฒนา!
ปล.จากผู้แปล
อ่านเพิ่มเติมในบล็อกของเรา:
- «";
- «";
- «";
- «'
ที่มา: will.com