OAuth 2 ป้องกันสิ่งต่าง ๆ เช่นการโจมตีเล่นซ้ำโดยใช้โทเค็นความปลอดภัยได้อย่างไร

ตามที่ผมเข้าใจมันห่วงโซ่ต่อไปของเหตุการณ์ที่เกิดขึ้นใน OAuth 2 เพื่อให้Site-Aเข้าถึงผู้ใช้Site-Bข้อมูลจาก

1. Site-AลงทะเบียนSite-Bและรับ Secret และ ID
2. เมื่อผู้ใช้บอกSite-Aต่อการเข้าถึงSite-B, ผู้ใช้จะถูกส่งไปSite-Bที่พวกเขาบอกSite-Bว่าพวกเขาจะแน่นอนชอบที่จะให้Site-Aสิทธิ์กับข้อมูลที่เฉพาะเจาะจง
3. Site-Bเปลี่ยนเส้นทางผู้ใช้กลับไปที่Site-Aพร้อมกับรหัสการอนุญาต
4. Site-Aจากนั้นส่งรหัสการอนุญาตพร้อมกับความลับของมันกลับไปเพื่อSite-Bตอบแทนโทเค็นความปลอดภัย
5. Site-Aจากนั้นทำการร้องขอSite-Bในนามของผู้ใช้โดยการรวมโทเค็นความปลอดภัยพร้อมกับคำขอ

ทั้งหมดนี้ทำงานอย่างไรในแง่ของความปลอดภัยและการเข้ารหัสในระดับสูง? OAuth 2 ป้องกันสิ่งต่าง ๆ เช่นการโจมตีเล่นซ้ำโดยใช้โทเค็นความปลอดภัยได้อย่างไร

OAuth 2.0 ทำงานอย่างไรในชีวิตจริง:

ฉันกำลังขับรถโดยร้านเบเกอรี่ของ Olaf ระหว่างเดินทางไปทำงานเมื่อฉันเห็นโดนัทที่อร่อยที่สุดในหน้าต่าง - ฉันหมายถึงสิ่งนั้นหยดความดีของช็อคโกแลต ดังนั้นฉันจึงเข้าไปข้างในและเรียกร้องให้ "ฉันต้องมีโดนัทนั้น" เขากล่าวว่า "แน่นอนว่าจะได้ $ 30"

ใช่ฉันรู้ว่า $ 30 สำหรับหนึ่งโดนัท! มันจะต้องอร่อย! ฉันไปถึงกระเป๋าเงินเมื่อจู่ๆฉันก็ได้ยินเสียงพ่อครัวร้องว่า "ไม่! ไม่มีโดนัทสำหรับคุณ" ฉันถามว่า: ทำไม เขาบอกว่าเขายอมรับการโอนเงินทางธนาคารเท่านั้น

อย่างจริงจัง? ใช่เขาจริงจัง ฉันเกือบจะเดินไปที่นั่น แต่โดนัทเรียกฉันออกมา: "กินฉันฉันอร่อย ... " ฉันจะไม่เชื่อฟังคำสั่งซื้อจากโดนัทได้อย่างไร ฉันว่าโอเค

เขาส่งโน้ตพร้อมชื่อของเขาให้ฉัน (พ่อครัวไม่ใช่โดนัท): "บอกพวกเขาว่า Olaf ส่งคุณ" ชื่อของเขาเป็นที่ทราบอยู่แล้วดังนั้นฉันไม่รู้ว่าจุดที่พูดนั้นเป็นอะไร แต่ก็โอเค

ฉันขับรถไปธนาคารหนึ่งชั่วโมงครึ่ง ฉันส่งบันทึกไปยังพนักงาน ฉันบอกเธอว่า Olaf ส่งฉันมา เธอทำให้ฉันดูอย่างใดอย่างหนึ่งแบบที่บอกว่า "ฉันอ่านได้"

เธอจดบันทึกของฉันถามรหัสของฉันถามฉันว่าเงินเท่าไรที่จะให้เขา ฉันบอกเธอ $ 30 เหรียญ เธอเขียนหวัดแล้วส่งโน้ตอีกอันให้ฉัน อันนี้มีตัวเลขอยู่จำนวนหนึ่งฉันเดาว่านั่นเป็นวิธีที่พวกเขาติดตามบันทึก

ณ จุดนี้ฉันหิวโหย ฉันรีบออกไปจากที่นั่นหนึ่งชั่วโมงครึ่งต่อมาฉันกลับมายืนอยู่หน้าโอลาฟพร้อมกับจดบันทึก เขาหยิบมันดูมันแล้วพูดว่า "ฉันจะกลับมา"

ฉันคิดว่าเขาได้รับโดนัทของฉัน แต่หลังจาก 30 นาทีฉันก็เริ่มสงสัย ดังนั้นฉันจึงถามคนที่อยู่หลังเคาน์เตอร์ "Where's Olaf?" เขาพูดว่า "เขาไปรับเงิน" "คุณหมายถึงอะไร" "เขารับทราบถึงธนาคาร"

หือ ... ดังนั้นโอลาฟจึงรับทราบว่าธนาคารให้ฉันและกลับไปที่ธนาคารเพื่อรับเงินออกจากบัญชีของฉัน เนื่องจากเขาได้ทราบว่าธนาคารให้ฉันธนาคารรู้ว่าเขาเป็นคนที่ฉันพูดถึงและเพราะฉันพูดกับธนาคารที่พวกเขารู้ว่าจะให้เขาเพียง $ 30

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

ฮะ. ขณะที่ฉันกำลังเดินกลับไปที่รถของฉันโทรศัพท์ของฉันดังขึ้น ฉันไม่ตื๊อตอบมันอาจเป็นงานของฉันที่จะโทรหาฉันเจ้านายของฉันช่างเป็นแบบนี้ นอกจากนี้ฉันยังไม่ทันได้นึกถึงกระบวนการที่เพิ่งทำไป

ฉันหมายถึงคิดว่า: ฉันสามารถให้ Olaf นำเงิน 30 เหรียญออกจากบัญชีธนาคารของฉันโดยไม่ต้องให้ข้อมูลบัญชีของเขากับเขา และฉันไม่ต้องกังวลว่าเขาจะเอาเงินมากเกินไปเพราะฉันบอกธนาคารว่าเขาได้รับอนุญาตให้ใช้เงินเพียง $ 30 และธนาคารรู้ว่าเขาเป็นคนที่ใช่เพราะเขามีข้อความที่ให้ฉันมอบให้กับโอลาฟ

ตกลงแน่ใจว่าฉันอยากจะส่งเขา $ 30 จากกระเป๋าของฉัน แต่ตอนนี้เขามีโน้ตนั้นฉันสามารถบอกให้ธนาคารรับเงินได้ 30 ดอลลาร์ทุกสัปดาห์จากนั้นฉันจะแสดงที่ร้านเบเกอรี่และฉันไม่ต้องไปที่ธนาคารอีกต่อไป ฉันยังสามารถสั่งโดนัททางโทรศัพท์ได้ด้วยถ้าฉันต้องการ

แน่นอนฉันไม่เคยทำอย่างนั้น - โดนัทนั่นน่ารังเกียจ

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

จากสิ่งที่ฉันได้อ่านนี่คือการทำงานทั้งหมด:

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

โดยรวมแล้ว OAuth 2 จริง ๆ แล้วเป็นรูปแบบการรักษาความปลอดภัยที่ง่ายมากและการเข้ารหัสไม่เคยเข้ามามีบทบาทโดยตรง ทั้งลับและโทเค็นความปลอดภัยเป็นรหัสผ่านเป็นหลักและสิ่งทั้งหมดนั้นปลอดภัยโดยการรักษาความปลอดภัยของการเชื่อมต่อ https

OAuth 2 ไม่มีการป้องกันการโจมตีเล่นซ้ำของ Security Token หรือ Secret แต่จะอาศัยเว็บไซต์ B ทั้งหมดที่รับผิดชอบรายการเหล่านี้และไม่ให้พวกเขาออกไปและพวกเขาจะถูกส่งผ่าน https ขณะอยู่ระหว่างการขนส่ง (https จะปกป้องพารามิเตอร์ URL)

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

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

นี่คือตัวอย่างกรณีการใช้งาน:

1. ฉันเข้าสู่ระบบ LinkedIn และต้องการเชื่อมต่อเพื่อนบางคนที่อยู่ในสมุดติดต่อ Gmail ของฉัน LinkedIn สนับสนุนสิ่งนี้ มันจะขอทรัพยากรที่ปลอดภัย (รายชื่อผู้ติดต่อ gmail ของฉัน) จาก gmail ดังนั้นฉันคลิกปุ่มนี้:
   

2. หน้าเว็บปรากฏขึ้นและจะแสดงหน้าเข้าสู่ระบบ Gmail เมื่อฉันป้อนบัญชีและรหัสผ่าน:
   

3. จากนั้น Gmail จะแสดงหน้าความยินยอมซึ่งฉันคลิก "ยอมรับ":

4. ตอนนี้ LinkedIn สามารถเข้าถึงผู้ติดต่อของฉันใน Gmail:

ด้านล่างเป็นแผนผังลำดับงานของตัวอย่างด้านบน:

ขั้นตอนที่ 1: LinkedIn ขอโทเค็นจากเซิร์ฟเวอร์การอนุญาตของ Gmail

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

ขั้นตอนที่ 3: ผู้ใช้ให้การอนุญาตแก่ LinkedIn เพื่อเข้าถึงข้อมูล Gmail

ขั้นตอนที่ 4: เซิร์ฟเวอร์การอนุญาต Gmail ตอบกลับด้วยโทเค็นการเข้าถึง

ขั้นตอนที่ 5: LinkedIn เรียก Gmail API ด้วยโทเค็นการเข้าถึงนี้

ขั้นตอนที่ 6: เซิร์ฟเวอร์ทรัพยากร Gmail ส่งคืนผู้ติดต่อของคุณหากโทเค็นการเข้าถึงนั้นถูกต้อง (โทเค็นจะได้รับการยืนยันโดยเซิร์ฟเวอร์ทรัพยากร Gmail)

คุณจะได้รับเพิ่มเติมจากรายละเอียดเกี่ยวกับ OAuth ที่นี่

รูปที่ 1 ยกจากRFC6750 :

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

นี่คือวิธีการทำงานของ Oauth 2.0 อธิบายได้ดีในบทความนี้

นี่คืออัญมณี:

https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

สรุปสั้น ๆ มาก:

OAuth กำหนดสี่บทบาท:

1. เจ้าของทรัพยากร
2. ไคลเอนต์
3. เซิร์ฟเวอร์ทรัพยากร
4. เซิร์ฟเวอร์การอนุญาต

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

เหตุผลที่มี OAuth อยู่เนื่องจากไม่ปลอดภัยสำหรับ GMail ในการจัดเก็บชื่อผู้ใช้และรหัสผ่าน Yahoo ของคุณ

คำตอบอื่น ๆ นั้นมีรายละเอียดมากและตอบคำถามจำนวนมากที่กล่าวถึงโดย OP

ในการอธิบายอย่างละเอียดและโดยเฉพาะเพื่อตอบคำถามของ OP "วิธี OAuth 2 ป้องกันสิ่งต่าง ๆ เช่นการโจมตีซ้ำโดยใช้ Security Token ได้อย่างไร" มีการป้องกันเพิ่มเติมสองประการในคำแนะนำอย่างเป็นทางการสำหรับการใช้ OAuth 2:

1) โทเค็นมักจะมีระยะเวลาหมดอายุสั้น ๆ ( http://tools.ietf.org/html/rfc6819#section-5.1.5.3 ):

เวลาหมดอายุสั้น ๆ สำหรับโทเค็นเป็นวิธีการป้องกันภัยคุกคามต่อไปนี้:

• เล่นใหม่ ...

2) เมื่อไซต์โทเค็นถูกใช้งานข้อเสนอแนะคือจะไม่แสดงเป็นพารามิเตอร์ URL แต่ในฟิลด์ส่วนหัวคำขอการให้สิทธิ์ ( http://tools.ietf.org/html/rfc6750 ):

ลูกค้าควรทำการร้องขอที่ได้รับการรับรองความถูกต้องด้วยโทเค็นผู้ถือโดยใช้ฟิลด์หัวข้อการร้องขอ "การอนุญาต" ที่มีรูปแบบการให้สิทธิ์ HTTP "ผู้ถือ" ...

ไม่ควรใช้วิธี "application / x-www-form-urlencoded" ยกเว้นในบริบทของแอปพลิเคชันที่เบราว์เซอร์ที่เข้าร่วมไม่สามารถเข้าถึงฟิลด์ "หัวข้อการขออนุมัติ" ...

URI Query Parameter ... รวมอยู่ในเอกสารการใช้งานในปัจจุบัน ไม่แนะนำให้ใช้งานเนื่องจากข้อบกพร่องด้านความปลอดภัย

นี่อาจเป็นคำอธิบายที่ง่ายที่สุดเกี่ยวกับวิธีการทำงานของ OAuth2 สำหรับประเภทการให้สิทธิ์ทั้ง 4 ประเภทนั่นคือการไหล 4 แบบที่แอพสามารถรับโทเค็นการเข้าถึง

ความคล้ายคลึงกัน

โฟลว์ประเภท Grant ทั้งหมดมี 2 ส่วน:

• รับโทเค็นการเข้าถึง
• ใช้โทเค็นการเข้าถึง

ส่วนที่ 2 'การใช้โทเค็นการเข้าถึง'จะเหมือนกันสำหรับโฟลว์ทั้งหมด

ข้อแตกต่าง

ส่วนที่ 1 ของโฟลว์'รับโทเค็นการเข้าถึง'สำหรับแต่ละประเภททุนจะแตกต่างกันไป

อย่างไรก็ตามโดยทั่วไปสามารถสรุปส่วนได้รับ 'โทเค็นการเข้าถึง'ประกอบด้วย 5 ขั้นตอน:

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

นี่คือไดอะแกรมแบบเคียงข้างกันเปรียบเทียบการไหลของการให้สิทธิ์แต่ละประเภทแตกต่างกันตาม 5 ขั้นตอน

แผนภาพนี้มาจากhttps://blog.oauth.io/introduction-oauth2-flow-diagrams/

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

ข้อมูลรับรองลูกค้า : หากแอปของคุณให้บริการผู้ใช้คนเดียว

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

รหัสการอนุญาต : วิธีที่ดีที่สุดในการขออนุมัติผู้ใช้

โดยนัย : หากคุณเป็นแอพมือถือหรือแอปหน้าเดียว

มีคำอธิบายเพิ่มเติมของตัวเลือกที่นี่: https://blog.oauth.io/choose-oauth2-flow-grant-types-for-app/