OAuth 2 แตกต่างจาก OAuth 1 อย่างไร

ในแง่ง่ายมากมีคนอธิบายความแตกต่างระหว่าง OAuth 2 และ OAuth 1 ได้ไหม

OAuth 1 ล้าสมัยแล้วหรือยัง เราควรใช้ OAuth 2 หรือไม่ ฉันไม่เห็นการใช้งาน OAuth 2 มากมาย ส่วนใหญ่ยังคงใช้ OAuth 1 อยู่ซึ่งทำให้ฉันสงสัยว่า OAuth 2 พร้อมใช้งานแล้ว ใช่ไหม?

Eran ค้อน Lahav ได้ทำงานที่ยอดเยี่ยมในการอธิบายส่วนใหญ่ของความแตกต่างในบทความของเขาแนะนำ OAuth 2.0 เพื่อสรุปนี่คือความแตกต่างที่สำคัญ:

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

OAuth 2.0 ไม่ต้องการให้แอปพลิเคชันไคลเอนต์มีการเข้ารหัสอีกต่อไป สิ่งนี้ฟังกลับไปที่ Twitter Auth API เก่าซึ่งไม่ต้องการแอปพลิเคชันสำหรับโทเค็นแฮช HMAC และสตริงคำขอ ด้วย OAuth 2.0 แอปพลิเคชันสามารถทำการร้องขอโดยใช้โทเค็นที่ออกให้เท่านั้นผ่าน HTTPS

ลายเซ็น OAuth 2.0 นั้นซับซ้อนน้อยกว่ามาก ไม่มีการแยกพิเศษการเรียงลำดับหรือการเข้ารหัสพิเศษอีกต่อไป

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

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

ผมเห็นคำตอบที่ดีขึ้นที่นี่ แต่สิ่งที่ฉันพลาดเป็นแผนภาพบางและตั้งแต่ผมต้องทำงานร่วมกับฤดูใบไม้ผลิกรอบฉันมาข้ามคำอธิบายของพวกเขา

ฉันพบว่าไดอะแกรมต่อไปนี้มีประโยชน์มาก พวกเขาแสดงให้เห็นถึงความแตกต่างในการสื่อสารระหว่างฝ่ายที่มี OAuth2 และ OAuth1

OAuth 2

OAuth 1

คำอธิบายก่อนหน้านี้ล้วนเป็น IMO ที่ละเอียดและซับซ้อนเกินไป กล่าวง่ายๆคือ OAuth 2 มอบการรักษาความปลอดภัยให้กับโปรโตคอล HTTPS OAuth 1 ไม่ต้องการสิ่งนี้ดังนั้นจึงมีวิธีอื่นในการจัดการกับการโจมตีหลายแบบ วิธีการเหล่านี้ต้องการให้แอพพลิเคชั่นมีส่วนร่วมในโปรโตคอลความปลอดภัยบางอย่างที่ซับซ้อนและอาจนำไปใช้งานได้ยาก ดังนั้นจึงง่ายกว่าที่จะใช้ HTTPS เพื่อความปลอดภัยเพื่อให้นักพัฒนาแอปพลิเคชันไม่จำเป็นต้องกังวลเกี่ยวกับเรื่องนี้

สำหรับคำถามอื่น ๆ ของคุณคำตอบนั้นขึ้นอยู่กับ บริการบางอย่างไม่ต้องการใช้ HTTPS ได้รับการพัฒนาก่อน OAuth 2 หรือมีข้อกำหนดอื่น ๆ ซึ่งอาจทำให้ไม่สามารถใช้ OAuth 2 ได้นอกจากนี้ยังมีการถกเถียงกันมากมายเกี่ยวกับโปรโตคอล OAuth 2 เอง อย่างที่คุณเห็น Facebook, Google และอีกสองสามคนมีโพรโทคอลเวอร์ชันที่แตกต่างกันเล็กน้อย ดังนั้นบางคนก็ติดกับ OAuth 1 เพราะมันมีความสม่ำเสมอมากกว่าในแพลตฟอร์มที่ต่างกัน เมื่อเร็ว ๆ นี้โพรโทคอล OAuth 2 ได้รับการสรุปแล้ว แต่เรายังไม่ได้เห็นว่าจะมีการนำไปใช้อย่างไร

หมายเหตุมีข้อโต้แย้งด้านความปลอดภัยที่ร้ายแรงต่อการใช้ Oauth 2:

หนึ่งบทความเยือกเย็น

และอีกเทคนิคหนึ่ง

หมายเหตุสิ่งเหล่านี้มาจากผู้เขียนหลักของ Oauth 2

ประเด็นสำคัญ:

• Oauth 2 ไม่มีการรักษาความปลอดภัยบน SSL ในขณะที่ Oauth 1 ไม่ขึ้นกับการขนส่ง

• ในแง่หนึ่ง SSL นั้นไม่ปลอดภัยที่เซิร์ฟเวอร์จะไม่ตรวจสอบการเชื่อมต่อและไลบรารีไคลเอ็นต์ทั่วไปทำให้ง่ายต่อการเพิกเฉยต่อความล้มเหลว

  ปัญหาเกี่ยวกับ SSL / TLS คือเมื่อคุณล้มเหลวในการตรวจสอบใบรับรองในฝั่งไคลเอ็นต์การเชื่อมต่อยังคงใช้งานได้ เมื่อใดก็ตามที่ละเลยข้อผิดพลาดจะนำไปสู่ความสำเร็จนักพัฒนาจะทำเช่นนั้น เซิร์ฟเวอร์ไม่มีวิธีบังคับใช้การตรวจสอบใบรับรองและแม้ว่าจะทำได้ผู้โจมตีจะไม่แน่นอน

• คุณสามารถกำจัดความปลอดภัยทั้งหมดของคุณออกไปได้ซึ่งทำได้ยากกว่าใน OAuth 1.0:

  ปัญหาที่อาจเกิดขึ้นทั่วไปที่สองคือการพิมพ์ผิด คุณจะพิจารณาว่ามันเป็นการออกแบบที่เหมาะสมเมื่อไม่ใช้อักขระหนึ่งตัว ('s' ใน 'https') ทำให้ความปลอดภัยทั้งหมดของโทเค็นลดลงหรือไม่ หรืออาจส่งคำขอ (ผ่านการเชื่อมต่อ SSL / TLS ที่ถูกต้องและตรวจสอบแล้ว) ไปยังปลายทางที่ไม่ถูกต้อง (พูดว่า ' http://gacebook.com ' หรือไม่) โปรดจำไว้ว่าความสามารถในการใช้โทเค็นผู้ถือ OAuth จากบรรทัดคำสั่งนั้นชัดเจนว่าเป็นผู้สนับสนุนโทเค็นผู้สนับสนุนกรณีใช้

ความปลอดภัยของโปรโตคอล OAuth 1.0 ( RFC 5849 ) ขึ้นอยู่กับการสันนิษฐานว่ารหัสลับที่ฝังอยู่ในแอปพลิเคชันไคลเอนต์สามารถเก็บเป็นความลับได้ อย่างไรก็ตามสมมติฐานที่ไร้เดียงสา

ใน OAuth 2.0 ( RFC 6749 ) แอปพลิเคชันไคลเอนต์ไร้เดียงสาดังกล่าวเรียกว่าไคลเอนต์ที่เป็นความลับ ในทางกลับกันแอปพลิเคชันไคลเอนต์ในสภาพแวดล้อมที่ยากที่จะเก็บรหัสลับเป็นความลับเรียกว่าลูกค้าสาธารณะ ดู2.1 ประเภทลูกค้าสำหรับรายละเอียด

ในแง่นั้น OAuth 1.0 เป็นข้อกำหนดเฉพาะสำหรับลูกค้าที่เป็นความลับ

" OAuth 2.0 และ Road to Hell " กล่าวว่า OAuth 2.0 มีความปลอดภัยน้อยกว่า แต่ไม่มีความแตกต่างในทางปฏิบัติในระดับความปลอดภัยระหว่างไคลเอนต์ OAuth 1.0 และ OAuth 2.0 ไคลเอนต์ที่เป็นความลับ OAuth 1.0 ต้องการคำนวณลายเซ็น แต่ไม่ปรับปรุงความปลอดภัยหากมั่นใจแล้วว่าคีย์ลับทางฝั่งไคลเอ็นต์สามารถเก็บเป็นความลับได้ การคำนวณลายเซ็นเป็นเพียงการคำนวณที่ยุ่งยากโดยไม่มีการปรับปรุงความปลอดภัยในทางปฏิบัติ ฉันหมายถึงเมื่อเปรียบเทียบกับความเรียบง่ายที่ไคลเอนต์ OAuth 2.0 เชื่อมต่อกับเซิร์ฟเวอร์ผ่าน TLS และเพิ่งนำเสนอclient_idและclient_secretไม่สามารถพูดได้ว่าการคำนวณที่ยุ่งยากนั้นดีกว่าในเรื่องของความปลอดภัย

นอกจากนี้ RFC 5849 (OAuth 1.0) ไม่ได้พูดถึงสิ่งใดเกี่ยวกับตัวเปลี่ยนเส้นทางแบบเปิดในขณะที่ RFC 6749 (OAuth 2.0) ทำ นั่นคือoauth_callbackพารามิเตอร์ของ OAuth 1.0 สามารถกลายเป็นช่องโหว่ด้านความปลอดภัย

ดังนั้นฉันไม่คิดว่า OAuth 1.0 ปลอดภัยกว่า OAuth 2.0

ความปลอดภัย OAuth 1.0 ขึ้นอยู่กับการคำนวณลายเซ็น ลายเซ็นถูกคำนวณโดยใช้คีย์ลับที่คีย์ลับเป็นคีย์ที่ใช้ร่วมกันสำหรับ HMAC-SHA1 ( RFC 5849, 3.4.2 ) หรือคีย์ส่วนตัวสำหรับ RSA-SHA1 ( RFC 5849, 3.4.3 ) ใครก็ตามที่รู้รหัสลับสามารถคำนวณลายเซ็นได้ ดังนั้นหากคีย์ลับถูกบุกรุกความซับซ้อนของการคำนวณลายเซ็นนั้นไม่มีความหมาย แต่ก็ซับซ้อน

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

เช่นเดียวกัน OAuth 2.0 ลูกค้าที่เป็นความลับจะใช้เงื่อนไขเดียวกัน หากเงื่อนไขเป็นที่พอใจแล้วจะมีปัญหาในการสร้างการเชื่อมต่อที่ปลอดภัยโดยใช้ TLS และส่งclient_idและclient_secretไปยังเซิร์ฟเวอร์การอนุญาตผ่านการเชื่อมต่อที่ปลอดภัยหรือไม่? มีระดับความปลอดภัยที่แตกต่างกันมากระหว่าง OAuth 1.0 และ OAuth 2.0 ไคลเอนต์ที่เป็นความลับหรือไม่หากทั้งคู่พึ่งพาเงื่อนไขเดียวกัน

ฉันไม่พบเหตุผลที่ดีสำหรับ OAuth 1.0 ที่จะตำหนิ OAuth 2.0 ข้อเท็จจริงก็คือ (1) OAuth 1.0 เป็นเพียงข้อกำหนดเฉพาะสำหรับลูกค้าที่เป็นความลับและ (2) OAuth 2.0 ได้ลดความซับซ้อนของโปรโตคอลสำหรับลูกค้าที่เป็นความลับและสนับสนุนลูกค้าสาธารณะเช่นกัน ไม่ว่าจะรู้จักกันดีหรือไม่ก็ตามแอปพลิเคชั่นสมาร์ทโฟนจัดอยู่ในประเภทไคลเอนต์สาธารณะ ( RFC 6749, 9 ) ซึ่งได้รับประโยชน์จาก OAuth 2.0

ไม่จำเป็นต้องมีลายเซ็น OAuth 2.0 สำหรับการเรียก API จริง ๆ เมื่อสร้างโทเค็นแล้ว มีโทเค็นการรักษาความปลอดภัยเดียวเท่านั้น

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

ที่นี่อธิบายถึงความแตกต่างระหว่าง OAuth 1.0 และ 2.0 กับวิธีการทำงานของทั้งคู่

เห็นได้ชัดว่า OAuth 2 เสียเวลา (จากปากของใครบางคนที่มีส่วนร่วมอย่างมาก):

https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529

เขาพูดว่า (แก้ไขเพื่อความกะทัดรัดและความกล้าหาญเพื่อเน้น):

... ฉันไม่สามารถเชื่อมโยงกับมาตรฐาน OAuth 2.0 ได้อีกต่อไป ฉันลาออกบทบาทของฉันในฐานะนักเขียนและบรรณาธิการนำชื่อของฉันออกจากสเปคและออกจากคณะทำงาน การลบชื่อของฉันออกจากเอกสารฉันพยายามอย่างหนักเป็นเวลาสามปีและมากกว่าสองร่างไม่ใช่เรื่องง่าย การตัดสินใจที่จะเดินหน้าต่อไปจากความพยายามที่ฉันนำมานานกว่าห้าปีได้ก่อให้เกิดความเจ็บปวด

... ในตอนท้ายฉันได้ข้อสรุปว่า OAuth 2.0 เป็นโปรโตคอลที่ไม่ดี WS- * ไม่ดี มันไม่ดีพอที่ฉันไม่ต้องการที่จะเชื่อมโยงกับมันอีกต่อไป ... เมื่อเปรียบเทียบกับ OAuth 1.0 ข้อมูลจำเพาะ 2.0 นั้นซับซ้อนกว่าทำงานร่วมกันน้อยกว่ามีประโยชน์น้อยกว่าไม่สมบูรณ์และที่สำคัญที่สุดคือปลอดภัยน้อยกว่า

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

หากคุณต้องการคำอธิบายขั้นสูงคุณต้องอ่านรายละเอียดทั้งสองอย่าง:

https://oauth.net/core/1.0a/

https://oauth.net/2/

หากคุณต้องการคำอธิบายที่ชัดเจนเกี่ยวกับความแตกต่างของการไหลสิ่งนี้อาจช่วยคุณได้:

OAuth 1.0 Flow

1. แอปพลิเคชันไคลเอนต์ลงทะเบียนกับผู้ให้บริการเช่น Twitter
2. Twitter นำเสนอ“ ความลับของผู้บริโภค” ให้กับลูกค้าโดยเฉพาะสำหรับแอปพลิเคชันนั้น
3. แอปไคลเอ็นต์ลงนามคำขอ OAuth ทั้งหมดไปยัง Twitter ด้วย"ความลับของผู้บริโภค" ที่เป็นเอกลักษณ์
4. หากคำขอ OAuth ใด ๆ มีรูปแบบข้อมูลที่ขาดหายไปหรือลงนามไม่ถูกต้องคำขอจะถูกปฏิเสธ

OAuth 2.0 Flow

1. แอปพลิเคชันไคลเอนต์ลงทะเบียนกับผู้ให้บริการเช่น Twitter
2. Twitter นำเสนอ“ ความลับของลูกค้า” ให้กับลูกค้าโดยเฉพาะสำหรับแอปพลิเคชันนั้น
3. โปรแกรมไคลเอนต์รวมถึง “ความลับลูกค้า”กับทุกคำขอทั่วไปว่าเป็น http หัว
4. หากคำขอ OAuth ใด ๆ มีรูปแบบข้อมูลที่ขาดหายไปหรือมีความลับที่ไม่ถูกต้องคำขอจะถูกปฏิเสธ

ที่มา: https://codiscope.com/oauth-2-0-vs-oauth-1-0/

OAuth 2.0 สัญญาว่าจะทำให้สิ่งต่าง ๆ ง่ายขึ้นด้วยวิธีการดังต่อไปนี้:

1. จำเป็นต้องใช้ SSL สำหรับการสื่อสารทั้งหมดที่จำเป็นในการสร้างโทเค็น นี่เป็นความซับซ้อนที่ลดลงอย่างมากเนื่องจากไม่จำเป็นต้องใช้ลายเซ็นที่ซับซ้อนอีกต่อไป
2. ไม่จำเป็นต้องใช้ลายเซ็นสำหรับการเรียก API จริง ๆ หลังจากสร้างโทเค็นแล้ว - SSL ขอแนะนำอย่างยิ่งที่นี่
3. เมื่อสร้างโทเค็นแล้ว OAuth 1.0 จำเป็นต้องให้ไคลเอ็นต์ส่งโทเค็นความปลอดภัยสองรายการในการเรียก API ทุกครั้งและใช้ทั้งคู่เพื่อสร้างลายเซ็น OAuth 2.0 มีโทเค็นความปลอดภัยเพียงหนึ่งเดียวและไม่จำเป็นต้องมีลายเซ็น
4. มีการระบุไว้อย่างชัดเจนว่าส่วนใดของโปรโตคอลที่นำไปใช้งานโดย "เจ้าของทรัพยากร" ซึ่งเป็นเซิร์ฟเวอร์จริงที่ใช้ API และส่วนใดที่อาจใช้งานโดย "เซิร์ฟเวอร์การอนุญาต" แยกต่างหาก ซึ่งจะทำให้ง่ายขึ้นสำหรับผลิตภัณฑ์อย่าง Apigee ที่จะให้การสนับสนุน OAuth 2.0 กับ API ที่มีอยู่

แหล่งที่มา: http://blog.apigee.com/detail/oauth_differences

จากมุมมองด้านความปลอดภัยฉันจะไปหา OAuth 1. ดูOAuth 2.0 และถนนสู่นรก

อ้างจากลิงค์นั้น: "ถ้าคุณใช้ 1.0 เรียบร้อยแล้วให้เพิกเฉย 2.0 มันไม่มีค่าจริงเกิน 1.0 (ตอนนี้ฉันเดาว่านักพัฒนาไคลเอ็นต์ของคุณจะหา 1.0 ลายเซ็นได้แล้วตอนนี้)

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