OAuth Authorization vs Authentication

Question 1

คำศัพท์ OAuth รบกวนฉันมานานแล้ว การให้สิทธิ์ OAuth เป็นไปตามที่บางคนแนะนำหรือเป็นการตรวจสอบสิทธิ์

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

การตรวจสอบสิทธิ์ OAuth คืออะไร (ทุกบทความบอกว่าไม่ใช่) ซึ่งฉันใช้มันต้องการให้ผู้ใช้ระบุข้อมูลรับรองซึ่งจะพิสูจน์ได้ว่าผู้ใช้ควร / ไม่ควรมีสิทธิ์เข้าถึงหรือไม่

ดังนั้นดูเหมือนว่า OAuth ไม่ใช่ Authorization NOR Authentication เนื่องจากสิ่งเหล่านี้ต้องดำเนินการโดยกระบวนการอื่น แล้วห่ามันคืออะไร? เป็นกระบวนการในการสื่อสารโทเค็นหรือไม่? เป็นคำปุยที่ไม่มีความหมายเฉพาะหรือไม่?

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

Question 2

OAuth เป็นข้อกำหนดสำหรับการอนุญาต

OAuth 2.0 เป็นข้อกำหนดสำหรับการอนุญาต แต่ไม่ใช่สำหรับการตรวจสอบสิทธิ์ RFC 6749, 3.1 Authorization Endpointกล่าวอย่างชัดเจนดังนี้:

จุดสิ้นสุดการให้สิทธิ์ใช้เพื่อโต้ตอบกับเจ้าของทรัพยากรและรับสิทธิ์การอนุญาต เซิร์ฟเวอร์การอนุญาตต้องยืนยันตัวตนของเจ้าของทรัพยากรก่อน วิธีที่เซิร์ฟเวอร์การอนุญาตตรวจสอบสิทธิ์เจ้าของทรัพยากร (เช่นชื่อผู้ใช้และรหัสผ่านล็อกอินคุกกี้เซสชัน) อยู่นอกเหนือขอบเขตของข้อกำหนดนี้

การตรวจสอบ OAuth?

การรับรองความถูกต้องเกี่ยวข้องกับข้อมูล "ใครคือ" การให้สิทธิ์จะให้ข้อมูลเกี่ยวกับ "ใครให้สิทธิ์อะไรแก่ใคร" ขั้นตอนการอนุญาตมีการพิสูจน์ตัวตนเป็นขั้นตอนแรก เป็นสาเหตุที่คนมักสับสน

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

OpenID Connect

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

จากมุมมองของพวก OpenID การตรวจสอบสิทธิ์ตาม OAuth นั้นไม่ปลอดภัยเพียงพอ แต่ต้องยอมรับว่าผู้คนชอบการตรวจสอบสิทธิ์ OAuth ด้วยเหตุนี้พวก OpenID จึงตัดสินใจกำหนดข้อกำหนดใหม่OpenID Connectที่ด้านบนของ OAuth 2.0

ใช่สิ่งนี้ทำให้ผู้คนสับสนมากขึ้น

คำจำกัดความประโยคเดียวของ OAuth 2.0 และ OpenID Connect

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

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

^{(ขออภัยคำจำกัดความเหล่านี้ตัดตอนมาจากหน้าภาพรวมของ บริษัท ของฉัน)}

คำจำกัดความจากมุมมองของผู้ปฏิบัติงาน

การพิสูจน์ตัวตนเป็นกระบวนการในการกำหนดหัวเรื่อง (= ตัวระบุเฉพาะ) ของผู้ใช้ปลายทาง มีหลายวิธีในการกำหนดหัวเรื่อง ID และรหัสผ่านลายนิ้วมือการจดจำม่านตา ฯลฯ

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