การรักษาความปลอดภัย REST API ของฉันด้วย OAuth ในขณะที่ยังคงอนุญาตให้ตรวจสอบสิทธิ์ผ่านผู้ให้บริการ OAuth บุคคลที่สาม (ใช้ DotNetOpenAuth)

ฉันมีผลิตภัณฑ์ที่มี REST API ตรงไปตรงมาเพื่อให้ผู้ใช้ผลิตภัณฑ์สามารถรวมเข้ากับคุณสมบัติของผลิตภัณฑ์ได้โดยตรงโดยไม่ต้องใช้ส่วนต่อประสานผู้ใช้บนเว็บของฉัน

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

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

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

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

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

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

ก่อนอื่นฉันต้องการเน้นความแตกต่างระหว่างการรับรองความถูกต้องและการอนุญาต:

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

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

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

OpenID มุ่งเน้นไปที่การใช้การตรวจสอบสิทธิ์ OAuth มุ่งเน้นไปที่การประยุกต์ใช้การอนุมัติ อย่างไรก็ตามบริการบางอย่างเช่น Facebook และ Twitter ได้เลือกที่จะใช้ OAuth สำหรับการตรวจสอบและการอนุญาตแทนการใช้ OpenID สำหรับการตรวจสอบและ OAuth สำหรับการให้สิทธิ์

ตอนนี้สำหรับโครงการของคุณเองฉันขอแนะนำให้คุณตรวจสอบเทมเพลตโครงการASP.NET MVC 2 OpenID (C #) ที่มีอยู่ใน VS Gallery นอกกรอบมาพร้อมกับการรับรองความถูกต้องของ OpenID และการสนับสนุน OAuth Service Provider ซึ่งหมายความว่าผู้ใช้ของคุณสามารถเข้าสู่ระบบด้วย OpenID และแอปพลิเคชันและบริการของบุคคลที่สามสามารถใช้ OAuth เพื่อทำการเรียก API ไปยังเว็บไซต์ของคุณและเข้าถึงข้อมูลผู้ใช้

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

ฉันสงสัยว่าคุณจะไม่มีอะไรมากหากมีสิ่งที่ต้องทำในหน้าการอนุญาต มันมาพร้อมกับ OAuth อย่างที่ฉันพูดไว้ก่อนหน้านี้และนั่นอาจเพียงพอสำหรับคุณ

ก่อนอื่นเลย คุณต้องแยกจิตใจ API ของคุณ - จากวิธีการรับรองความถูกต้อง

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

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

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

ทางเลือกเดียวที่แท้จริงของ OAuth เท่าที่ฉันเห็นคือ OAuth 2.0 และการพิสูจน์ตัวตนพื้นฐานอย่างง่าย

นอกจากนั้นคุณกำลังพูดถึงการรับรองความถูกต้องโดยใช้ Open-ID หรือข้อมูลประจำตัว Facebook ฯลฯ นี่เป็นอีกคำถามที่คุณต้องถามตัวเอง แต่มันอยู่นอกขอบเขตของ API และ OAuth จริงๆ สำหรับฉันแล้วรู้สึกถึงคำถามเพิ่มเติมเกี่ยวกับการสร้างผู้ใช้ในบริการของคุณ ฉันอาจจะผิด