SAML เทียบกับการเข้าสู่ระบบแบบรวมศูนย์ด้วย OAuth

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

พวกเขาแก้ปัญหาที่แตกต่างกัน

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

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

เป็นสองสิ่งที่แตกต่างกันอย่างสิ้นเชิง

ตัวอย่างบางส่วนที่อาจช่วยได้

OAuth นึกถึงทวิตเตอร์ สมมติว่าคุณใช้Google Buzzและ Twitter และคุณต้องการเขียนแอปเพื่อให้ทั้งสองซิงค์กัน โดยพื้นฐานแล้วคุณสามารถสร้างความไว้วางใจระหว่างแอปและทวิตเตอร์ของคุณได้ ครั้งแรกที่คุณเชื่อมโยงแอปกับ twitter คุณจะต้องลงชื่อเข้าใช้ twitter แบบคลาสสิกจากนั้นกล่องยืนยันจะปรากฏขึ้นและถามว่า "คุณต้องการให้สิทธิ์เข้าถึง«ชื่อแอปของคุณ»หรือไม่" เมื่อคุณคลิก "ใช่" ความไว้วางใจได้ถูกสร้างขึ้นและตอนนี้แอปของคุณสามารถทำหน้าที่เป็นคุณบน Twitter ได้แล้ว สามารถอ่านโพสต์ของคุณและสร้างใหม่ได้

SAML - สำหรับ SAML ให้นึกถึง "ข้อตกลง" บางประเภทระหว่างระบบสมาชิกสองระบบที่ไม่เกี่ยวข้องกัน ในกรณีของเราเราสามารถใช้ US Airways และ Hertz ได้ ไม่มีชุดข้อมูลรับรองที่ใช้ร่วมกันที่สามารถนำคุณจากไซต์หนึ่งไปยังอีกไซต์หนึ่งได้ แต่สมมติว่าเฮิรตซ์ต้องการเสนอ "ดีล" ให้กับ US Airways (จริงอยู่ที่ฉันรู้ว่านี่เป็นตัวอย่างที่รุนแรง แต่อดทนกับฉัน) หลังจากซื้อเที่ยวบินแล้วพวกเขาจะเสนอรถเช่าฟรีให้กับสมาชิกประธานกรรมการ US Airways และ Hertz จะสร้างความไว้วางใจบางรูปแบบและวิธีระบุตัวผู้ใช้ ในกรณีของเรา "ID federated" ของเราคือที่อยู่อีเมลและจะเป็นวิธีการหนึ่งที่ Hertz เชื่อมั่นว่าผู้ให้บริการข้อมูลประจำตัวของ US Airways จะส่งมอบโทเค็นที่ถูกต้องและปลอดภัย หลังจากจองเที่ยวบินผู้ให้บริการข้อมูลประจำตัวของสายการบิน US Airways จะสร้างโทเค็นและเติมข้อมูลว่าพวกเขาตรวจสอบสิทธิ์ผู้ใช้อย่างไรรวมถึง "แอตทริบิวต์" เกี่ยวกับบุคคลในกรณีของเราแอตทริบิวต์ที่สำคัญที่สุดคือระดับสถานะของเขาใน US Airways เมื่อเติมโทเค็นแล้วจะส่งผ่านการอ้างอิงบางประเภทหรือเข้ารหัสใน url และเมื่อเราไปที่ Hertz จะตรวจสอบโทเค็นตรวจสอบความถูกต้องและตอนนี้สามารถอนุญาตให้เช่ารถฟรีได้

ปัญหาของตัวอย่าง SAML นี้เป็นกรณีการใช้งานพิเศษเพียงกรณีเดียวจากหลาย ๆ กรณี SAML เป็นมาตรฐานและมีเกือบหลายวิธีที่คุณสามารถนำไปใช้ได้

หรือถ้าคุณไม่ดูแลเกี่ยวกับการอนุญาตคุณสามารถเกือบยืนยันว่าเข้าไปยุ่งเกี่ยวกับการตรวจสอบผ่าน SAML และOpenID

ดูคำอธิบายง่ายๆที่สรุปไว้ที่นี่:

หลายคนสับสนเกี่ยวกับความแตกต่างระหว่าง SAML, OpenID และ OAuth แต่จริงๆแล้วมันง่ายมาก แม้ว่าจะมีการทับซ้อนกันบ้าง แต่นี่เป็นวิธีง่ายๆในการแยกแยะความแตกต่างระหว่างทั้งสาม

OpenID - การลงชื่อเพียงครั้งเดียวสำหรับผู้บริโภค

SAML - การลงชื่อเพียงครั้งเดียวสำหรับผู้ใช้ระดับองค์กร

OAuth - การอนุญาต API ระหว่างแอปพลิเคชัน

สำหรับ folks สบายกับรูปแบบการออกแบบ OO ผมคิดว่ามีข้อพิสูจน์ที่ดีที่จะรูปแบบเสื้อคลุม ลองนึกถึงรูปแบบFacade , DecoratorและProxy พื้นฐานเหล่านี้ทั้งหมดเดียวกันพวกเขากำลังเพียงห่อ ... ความแตกต่างคือความตั้งใจของแต่ละรูปแบบ

ในทำนองเดียวกันSAML, OAuth และ OpenID ล้วนเอื้อให้เกิดความตั้งใจที่แตกต่างกันผ่านกลไกพื้นฐานทั่วไปซึ่งเป็นการเปลี่ยนเส้นทางไปยังผู้ให้บริการ / ผู้มีอำนาจในการระบุตัวตนสำหรับการโต้ตอบส่วนตัวบางอย่างตามด้วยการเปลี่ยนเส้นทางไปยังแอปของบุคคลที่สามที่มา

เมื่อมองไปรอบ ๆ บนเน็ตคุณจะพบความทับซ้อนระหว่างความสามารถของโปรโตคอล การรับรองความถูกต้องผ่าน OAuthนั้นสมเหตุสมผลอย่างยิ่ง SSO ผ่าน OAuth อาจไม่สมเหตุสมผลนักแม้ว่า SAML และ OpenID จะมุ่งเน้นไปที่ข้อมูลประจำตัวแบบรวมศูนย์โดยเฉพาะ

คำถามของตัวเองในบริบทขององค์กร SAML เสียงที่เหมาะสมมากกว่า OAuth สำหรับ SSO ฉันพนันได้เลยว่าหากคุณดูแอปของบุคคลที่สามที่คุณต้องการรวมเข้ากับข้อมูลประจำตัวขององค์กรคุณจะพบว่าแอปเหล่านี้ได้รับการออกแบบมาให้ทำงานร่วมกับ SAML / LDAP / Radius เป็นต้น IMO OAuth เหมาะสมกว่าสำหรับการโต้ตอบทางอินเทอร์เน็ต ระหว่างแอปพลิเคชันหรือแอปพลิเคชันที่ประกอบด้วยสถาปัตยกรรมเชิงบริการในสภาพแวดล้อมขององค์กรขนาดใหญ่

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

พวกเขาจัดการกรณีการใช้งานที่ละเอียดอ่อน

• SAML - การแบ่งปันข้อมูลรับรอง (เช่น SSO) ของผู้ใช้ไปยังผู้ให้บริการต่างๆ (เช่นเว็บหรือบริการบนเว็บ)
• OAuth - ผู้ใช้ที่มอบหมายให้แอปเข้าถึงทรัพยากรในนามของเขา / เธอ

พบบทความดีๆที่นี่

SAML (ภาษามาร์กอัปเพื่อยืนยันความปลอดภัย) ได้รับการกำหนดมาตรฐานเพื่อให้บรรลุการลงชื่อเพียงครั้งเดียว (SSO) สหพันธ์และการจัดการข้อมูลประจำตัว

ตัวอย่าง : ผู้ใช้ (หลัก) รับรองความถูกต้องกับเว็บไซต์จองเที่ยวบิน AirFlyer (ผู้ให้บริการข้อมูลประจำตัว) ซึ่งกำหนดค่า SSO ผ่าน SAML ด้วยเว็บไซต์จองรถรับส่ง Shuttler (ผู้ให้บริการ) เมื่อตรวจสอบสิทธิ์กับ Flyer แล้วผู้ใช้สามารถจองรถรับส่งบน Shuttler ได้โดยไม่ต้องมีการตรวจสอบสิทธิ์

OAuth (Open Authorization) เป็นมาตรฐานสำหรับการอนุญาตทรัพยากร ไม่จัดการกับการรับรองความถูกต้อง

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

SAML มี "โปรไฟล์" มากมายให้เลือกเพื่อให้ผู้ใช้รายอื่น "เข้าสู่ระบบ" ไซต์ของคุณ SAML-P หรือ SAML Passive เป็นเรื่องธรรมดามากและค่อนข้างง่ายในการตั้งค่า WS-Trust นั้นคล้ายกันและยังอนุญาตให้มีการรวมกลุ่มระหว่างเว็บไซต์

OAuth ออกแบบมาเพื่อการอนุญาต คุณสามารถอ่านเพิ่มเติมได้ที่นี่:

OpenID และ OAuth ต่างกันอย่างไร

SAMLมีไว้สำหรับการรับรองความถูกต้อง - ส่วนใหญ่ใช้ในสถานการณ์การลงชื่อเพียงครั้งเดียว OAuthมีไว้สำหรับการอนุญาตการเป็นตัวแทนทรัพยากร

JSON Web Token (JWT)เป็นทางเลือกสำหรับ SAML XML Token JWT สามารถใช้กับ OAuth ได้

ข้อมูลอ้างอิงที่ดีคือSAML กับ OAuth: ฉันควรใช้อันไหน

คำว่าสหพันธ์หมายถึงตัวตนการเชื่อมต่อข้ามระบบจริงๆ มันเกี่ยวข้องกับ SSO แต่ก็ไม่เหมือนกัน ฉันพบว่าบล็อกโพสต์นี้มีประโยชน์มากในแง่ของความหมายของสหพันธ์