เหตุใดจึงมีโฟลว์ "รหัสการอนุญาต" ใน OAuth2 เมื่อโฟลว์ "โดยนัย" ทำงานได้ดี?

ด้วยโฟลว์ "นัย" ไคลเอนต์ (น่าจะเป็นเบราว์เซอร์) จะได้รับโทเค็นการเข้าถึงหลังจากเจ้าของทรัพยากร (เช่นผู้ใช้) ให้การเข้าถึง

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

โฟลว์ทั้งสองมีผลลัพธ์เหมือนกันแน่นอน: โทเค็นการเข้าถึง อย่างไรก็ตามการไหล "โดยนัย" นั้นง่ายกว่ามาก

คำถาม: ทำไมต้องรำคาญกับโฟลว์ "รหัสการอนุญาต" เมื่อการไหลของตะเข็บ "โดยนัย" ถึงจะใช้ได้ ทำไมไม่ใช้ "นัย" สำหรับเว็บเซิร์ฟเวอร์ด้วย

มันทำงานได้มากขึ้นทั้งกับผู้ให้บริการและลูกค้า

tl; dr:ทั้งหมดนี้เป็นเพราะเหตุผลด้านความปลอดภัย

OAuth 2.0 ต้องการเป็นไปตามเกณฑ์ทั้งสองนี้:

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

รายละเอียดด้านล่าง:

โฟลว์ทางอ้อมเป็นไปได้เฉพาะในสภาพแวดล้อมของเบราว์เซอร์เนื่องจากเหตุผลด้านความปลอดภัย:

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

• พวกเขาไม่ได้เป็นส่วนหนึ่งของคำขอ HTTP ดังนั้นจึงไม่สามารถอ่านได้โดยเซิร์ฟเวอร์และเนื่องจากพวกเขาไม่สามารถดักจับโดยเซิร์ฟเวอร์ตัวกลาง / เราเตอร์ (นี่เป็นสิ่งสำคัญ)
• มีอยู่ในเบราว์เซอร์เท่านั้น - ฝั่งไคลเอ็นต์ - ดังนั้นวิธีเดียวที่จะอ่านส่วนแฮชคือการใช้ JavaScript ที่ทำงานบนหน้าเว็บ

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

โฟลว์ implicit ยังมีปัญหาด้านความปลอดภัยที่ต้องใช้ตรรกะเพิ่มเติมเพื่อแก้ไขปัญหา / หลีกเลี่ยงตัวอย่างเช่น:

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

ในโฟลว์การให้สิทธิ์รหัสนั้นเป็นไปไม่ได้ที่จะส่งโทเค็นการเข้าถึงโดยตรงในพารามิเตอร์ URL เนื่องจากพารามิเตอร์ URL เป็นส่วนหนึ่งของคำขอ HTTP ดังนั้นเซิร์ฟเวอร์ตัวกลาง / เราเตอร์ใด ๆ ที่คำขอของคุณจะผ่าน (อาจเป็นหลายร้อย) อ่านโทเค็นการเข้าถึงหากคุณไม่ได้ใช้การเชื่อมต่อที่เข้ารหัส (HTTPS) เพื่อให้สิ่งที่เรียกว่าการโจมตีแบบ Man-in-the-middle

การส่งผ่านโทเค็นการเข้าถึงโดยตรงในพารามิเตอร์ URL อาจเป็นไปได้ในทางทฤษฎี แต่การรับรองความถูกต้องจะต้องตรวจสอบให้แน่ใจว่า URI การเปลี่ยนเส้นทางใช้ HTTPS พร้อมการเข้ารหัส TLS และใบรับรอง SSL ที่ 'เชื่อถือได้' (โดยทั่วไปจากผู้ออกใบรับรอง เพื่อให้แน่ใจว่าเซิร์ฟเวอร์ปลายทางนั้นถูกต้องตามกฎหมายและคำขอ HTTP นั้นถูกเข้ารหัสอย่างสมบูรณ์ การมีนักพัฒนาซอฟต์แวร์ทั้งหมดซื้อใบรับรอง SSL และกำหนดค่า SSL บนโดเมนของตนอย่างถูกต้องจะเป็นปัญหาใหญ่และจะชะลอการยอมรับอย่างมาก นี่คือเหตุผลที่คนกลางใช้ "รหัสการอนุญาต" แบบใช้ครั้งเดียวโดยมีเงื่อนไขว่ามีเพียงผู้รับที่ถูกกฎหมายเท่านั้นที่จะสามารถแลกเปลี่ยน (เพราะคุณต้องการความลับของลูกค้า) และรหัสนั้นจะไร้ประโยชน์กับแฮ็กเกอร์ที่อาจขัดขวางการทำธุรกรรม (เพราะพวกเขาไม่ '

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

นัยไหลทำให้การไหลเวียนของทั้งสวยง่าย แต่ยังมีความปลอดภัยน้อย
เนื่องจากแอปพลิเคชันไคลเอนต์ซึ่งโดยปกติแล้ว JavaScript ที่ทำงานภายในเบราว์เซอร์จะเชื่อถือได้น้อยกว่าจะไม่มีการส่งคืนโทเค็นการรีเฟรชสำหรับการเข้าถึงที่ยาวนาน
คุณควรใช้โฟลว์นี้สำหรับแอปพลิเคชันที่ต้องการการเข้าถึงข้อมูลของผู้ใช้ชั่วคราว (ไม่กี่ชั่วโมง)
การส่งคืนโทเค็นการเข้าถึงไปยังไคลเอนต์ JavaScript ยังหมายความว่าแอปพลิเคชันที่ใช้เบราว์เซอร์ของคุณต้องใช้ความระมัดระวังเป็นพิเศษ - คิดถึง XSS Attacks ที่อาจทำให้โทเค็นการเข้าถึงรั่วไหลไปยังระบบอื่น ๆ

https://labs.hybris.com/2012/06/05/oauth2-the-implicit-flow-aka-as-the-client-side-flow

จากข้อมูลจำเพาะ OAuth :

4.2 การอนุญาตโดยปริยาย

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

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

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

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

ดังนั้นสิ่งที่เราสามารถพิจารณา:

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

2. โทเค็นการเข้าถึงเกิดขึ้นในแถบที่อยู่ของเบราว์เซอร์เพื่อให้ผู้ใช้สามารถคัดลอก URL และส่งไปยังบุคคลอื่นและจะถูกบันทึกเป็นผู้ใช้นั่นคือสิ่งที่ต้องการการแก้ไขเซสชัน แต่เบราว์เซอร์ทำการเปลี่ยนเส้นทางเพิ่มเติมด้วยการแทนที่ประวัติเพื่อลบส่วนของแฮชออกจาก URL นอกจากนี้ยังเป็นไปได้ที่แฮ็กเกอร์จะขโมยโทเค็นการเข้าถึงโดยดมทราฟฟิก HTTP แต่สามารถป้องกัน HTTPS ได้อย่างง่ายดาย ส่วนขยายเบราว์เซอร์ที่เป็นอันตรายบางอย่างสามารถเข้าถึง URL จากแถบที่อยู่ แต่ท้ายที่สุดแล้วนี่เป็นสถานการณ์ที่เลวร้ายเช่นใบรับรอง HTTPS ที่เสียหาย และแม้แต่การไหลของรหัสรับรองความถูกต้องก็ไม่สามารถช่วยอีเธอร์ได้ที่นี่ ดังนั้นสิ่งที่ฉันเห็นคือผ่านโทเค็นการเข้าถึงผ่านส่วนย่อยของ URL ที่มีความปลอดภัยอย่างแน่นอน

3. การแยกโทเค็นการเข้าถึงแบบชั่วคราวและโทเค็นการรีเฟรชนั้นไม่มีประโยชน์เมื่อใช้ HTTPS และโดยสุจริตแล้วไม่มีประโยชน์แม้แต่บน HTTP ดิบ แต่ความจริงที่ว่าลูกค้าผ่านโฟลว์โดยปริยายไม่สามารถรับโทเค็นการรีเฟรชก็เป็นเรื่องไร้สาระเช่นกัน

ดังนั้นฉันคิดว่าเราควรแนะนำการไหลของเงินทุนใหม่ "ปลอดภัยโดยนัย" ซึ่งทำงานได้อย่างเคร่งครัดบน https, อนุญาตโทเค็นการรีเฟรช (หรือเราควรกำจัดพวกมันออกทั้งหมด) และเป็นที่นิยมมากกว่ากระแสการอนุญาต Auth Cose

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

วิธีนี้ใช้งานได้และปลอดภัยเนื่องจากสามารถเพิกถอนโทเค็นการรีเฟรชได้ หากลูกค้าบอกว่าพวกเขาทำโทรศัพท์หายหรือแล็ปท็อปหรือแฮกเกอร์ไปที่เดสก์ท็อปเราสามารถยกเลิกโทเค็นการรีเฟรชทั้งหมดสำหรับผู้ใช้รายนั้นได้ ในระหว่างกระบวนการทั้งหมดไม่มีข้อมูลที่สามารถระบุตัวตนได้ (PII) เคยแตะรหัสของเรา - คือรหัสผ่านของผู้ใช้

การไหลของรหัสนั้นยอดเยี่ยม แต่ใช้งานได้มากกว่า MS ไม่มีไลบรารี่ Angular ที่จะจัดการกับมันในปัจจุบันดังนั้นฉันต้องเขียนมัน หากคุณสนใจฉันสามารถช่วยคุณได้

คำตอบของฉันคือ: คุณไม่สามารถใช้โฟลว์โดยนัยในลักษณะที่ปลอดภัยและเรียบง่ายกับเซิร์ฟเวอร์เว็บแอป

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

ดังนั้นโทเค็นควรถูกส่งผ่านไปยังเว็บแอปโดยใช้ URL การเปลี่ยนเส้นทางใช่ไหม

ดังที่ @NicolasGarnier อธิบายไว้ในคำตอบและความคิดเห็นของเขาไม่มีทางที่จะส่งโทเค็นเป็นส่วน URL - มันจะไม่เข้าถึงเซิร์ฟเวอร์เว็บแอป

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

ดังนั้นจึงไม่มีวิธีส่งโทเค็นใน URL การเปลี่ยนเส้นทาง นั่นเป็นเหตุผลที่คุณต้องมีการโทรครั้งที่สอง (จากเซิร์ฟเวอร์การตรวจสอบสิทธิ์ไปยังไคลเอนต์ (แต่เป็น URL ใด?) หรือจากไคลเอ็นต์ไปยังเซิร์ฟเวอร์การตรวจสอบสิทธิ์ (การโทรครั้งที่สองในโฟลว์รหัสการอนุญาต)