เหตุใด OAuth v2 จึงมีทั้งโทเค็นการเข้าถึงและรีเฟรช

ส่วน 4.2 ของร่างโปรโตคอล OAuth 2.0 ระบุว่าเซิร์ฟเวอร์การอนุญาตสามารถส่งคืนทั้งสองได้ access_token (ซึ่งใช้ในการตรวจสอบสิทธิ์ของตัวเองด้วยทรัพยากร) เช่นเดียวกับ a refresh_tokenซึ่งใช้เพื่อสร้างใหม่อย่างแท้จริงaccess_token:

https://tools.ietf.org/html/rfc6749#section-4.2

ทำไมถึงมีทั้งคู่? ทำไมไม่เพียงแค่ทำให้access_tokenครั้งสุดท้ายตราบเท่าที่refresh_tokenและไม่มีrefresh_token?

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

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

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

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

นี่คือหัวข้อที่ดีพูดคุยเกี่ยวกับการใช้งานของสัญญาณรีเฟรช: OAuth หอจดหมายเหตุ

ข้อความจากด้านบนพูดถึงวัตถุประสงค์ด้านความปลอดภัยของโทเค็นการรีเฟรช:

รีเฟรชโทเค็น ... ลดความเสี่ยงของการรั่วไหลของ access_token ที่ยาวนาน (Param แบบสอบถามในล็อกไฟล์บนเซิร์ฟเวอร์ทรัพยากรที่ไม่ปลอดภัยเบต้าหรือแอปเซิร์ฟเวอร์เซิร์ฟเวอร์ที่มีการเข้ารหัสต่ำไคลเอ็นต์ JS SDK บนไซต์ https ที่ไม่ใช่ https ที่ทำให้ access_token คุกกี้ ฯลฯ )

ลิงก์สำหรับการสนทนาซึ่งจัดทำโดย Catchdave มีจุดที่ถูกต้อง (ต้นฉบับลิงค์ตาย) ที่ ทำโดย Dick Hardt ซึ่งฉันเชื่อว่าควรกล่าวถึงที่นี่นอกเหนือจากสิ่งที่เขียนไว้ด้านบน:

การระลึกถึงโทเค็นการรีเฟรชของฉันเพื่อความปลอดภัยและการเพิกถอน < ... >

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

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

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

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

ระบบที่ใช้โทเค็นการเข้าถึงระยะยาวควรทำงานอย่างไร

เซิร์ฟเวอร์อนุญาตให้ลูกค้าเข้าถึงข้อมูลของผู้ใช้ภายในขอบเขตที่กำหนดไว้ล่วงหน้าโดยการออกโทเค็น ตามที่เราต้องการเก็บโทเค็นที่เพิกถอนได้เราต้องเก็บโทเค็นพร้อมกับแฟล็ก "เพิกถอน" ที่ตั้งค่าไว้หรือไม่ได้ตั้งค่า (มิเช่นนั้นคุณจะทำสิ่งนั้นด้วยโทเค็นที่มีอยู่ในตัวเองได้อย่างไร)len(users) x len(registered clients) x len(scopes combination)บันทึก . คำขอ API ทุกครั้งจะต้องเข้าถึงฐานข้อมูล แม้ว่าจะเป็นเรื่องไม่สำคัญนักที่จะทำการสืบค้นฐานข้อมูลดังกล่าวที่มีประสิทธิภาพ O (1) จุดล้มเหลวเพียงจุดเดียวอาจส่งผลเสียต่อความสามารถในการขยายขนาดและประสิทธิภาพของระบบ

ระบบที่ใช้โทเค็นการรีเฟรชที่มีอายุการใช้งานนานและโทเค็นการเข้าถึงระยะสั้นควรทำงานอย่างไร

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

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

อย่างไรก็ตามเรายังคงต้องเก็บฐานข้อมูลของโทเค็นการรีเฟรช แต่จำนวนคำขอไปยังฐานข้อมูลนี้จะถูกกำหนดโดยอายุการใช้งานของโทเค็นการเข้าถึง (ยิ่งอายุการใช้งานนานขึ้นเท่าใดอัตราการเข้าถึงจะลดลง)

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

ความสมดุล

รีเฟรชโทเค็นบางส่วนกำจัด SPoF (จุดเดียวของความล้มเหลว) ของฐานข้อมูล Access Token แต่ก็มีข้อเสียที่เห็นได้ชัด

1. หน้าต่าง". กรอบเวลาระหว่างเหตุการณ์ "ผู้ใช้ยกเลิกการเข้าถึง" และ "การเข้าถึงถูกรับประกันว่าจะถูกเพิกถอน"

2. ความซับซ้อนของลอจิกไคลเอ็นต์

   ไม่มีการรีเฟรชโทเค็น

   • ส่งคำขอ API ด้วยโทเค็นการเข้าถึง
   • ถ้าโทเค็นการเข้าถึงไม่ถูกต้องล้มเหลวและขอให้ผู้ใช้รับรองความถูกต้องอีกครั้ง

   ด้วยโทเค็นการรีเฟรช

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

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

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

คิดถึงสถานการณ์แบบนี้ คุณออกผู้ใช้โทเค็นการเข้าถึง 3600 วินาทีและรีเฟรชโทเค็นนานกว่าหนึ่งวัน

1. ผู้ใช้เป็นผู้ใช้ที่ดีเขาอยู่ที่บ้านและเปิด / ปิดการช็อปปิ้งเว็บไซต์ของคุณและค้นหาบน iPhone ของเขา ที่อยู่ IP ของเขาจะไม่เปลี่ยนแปลงและมีการโหลดต่ำมากบนเซิร์ฟเวอร์ของคุณ ชอบหน้า 3-5 หน้าทุกนาที เมื่อ 3600 วินาทีบนโทเค็นการเข้าถึงของเขาสิ้นสุดลงเขาต้องใช้โทเค็นใหม่ที่มีโทเค็นการรีเฟรช เราในด้านเซิร์ฟเวอร์ตรวจสอบประวัติกิจกรรมและที่อยู่ IP ของเขาคิดว่าเขาเป็นมนุษย์และประพฤติตน เราอนุญาตให้โทเค็นการเข้าถึงใหม่ของเขาเพื่อใช้บริการของเราต่อไป ผู้ใช้ไม่จำเป็นต้องป้อนชื่อผู้ใช้ / รหัสผ่านอีกครั้งจนกว่าจะครบหนึ่งวันของการรีเฟรชโทเค็นเอง

2. ผู้ใช้เป็นความประมาทของผู้ใช้ เขาอาศัยอยู่ในนิวยอร์กสหรัฐอเมริกาและได้ปิดโปรแกรมไวรัสของเขาและถูกแฮ็กโดยแฮกเกอร์ในโปแลนด์ เมื่อแฮ็กเกอร์ได้รับโทเค็นการเข้าถึงและรีเฟรชโทเค็นเขาพยายามที่จะปลอมตัวเป็นผู้ใช้และใช้บริการของเรา แต่หลังจากโทเค็นการเข้าถึงระยะสั้นหมดอายุเมื่อแฮกเกอร์พยายามรีเฟรชโทเค็นการเข้าถึงเราบนเซิร์ฟเวอร์ได้สังเกตเห็นการเปลี่ยนแปลง IP อย่างมากในประวัติศาสตร์พฤติกรรมผู้ใช้ (เฮ้เข้าสู่ระบบคนนี้ในสหรัฐอเมริกาและตอนนี้รีเฟรชการเข้าถึงในโปแลนด์ หลังจากเพียง 3600s ???) เรายุติกระบวนการรีเฟรชทำให้โทเค็นการรีเฟรชเป็นโมฆะและแจ้งให้ป้อนชื่อผู้ใช้ / รหัสผ่านอีกครั้ง

3. ผู้ใช้เป็นที่เป็นอันตรายของผู้ใช้ เขาตั้งใจจะใช้บริการของเราในทางที่ผิดโดยโทร 1,000 ครั้ง API ของเราทุกนาทีโดยใช้หุ่นยนต์ เขาสามารถทำได้จนถึง 3600 วินาทีต่อมาเมื่อเขาพยายามรีเฟรชโทเค็นการเข้าถึงเราสังเกตเห็นพฤติกรรมของเขาและคิดว่าเขาอาจไม่ใช่มนุษย์ เราปฏิเสธและยุติกระบวนการรีเฟรชและขอให้เขาป้อนชื่อผู้ใช้ / รหัสผ่านอีกครั้ง สิ่งนี้อาจทำลายการไหลอัตโนมัติของหุ่นยนต์ของเขา อย่างน้อยก็ทำให้เขาอึดอัด

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

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

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

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

เพื่อกำจัดความสับสนคุณต้องเข้าใจบทบาทของความลับของลูกค้าและรหัสผ่านผู้ใช้ซึ่งแตกต่างกันมาก

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

ในการรับโทเค็นการเข้าถึงเริ่มต้นและโทเค็นการรีเฟรชสิ่งที่จำเป็นคือ:

• ID ผู้ใช้
• รหัสผ่านผู้ใช้
• รหัสลูกค้า
• ความลับของลูกค้า

ในการรับโทเค็นการเข้าถึงที่รีเฟรชอย่างไรก็ตามไคลเอนต์ใช้ข้อมูลต่อไปนี้:

• รหัสลูกค้า
• ความลับของลูกค้า
• โทเค็นการรีเฟรช

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

นอกจากนี้ยังแสดงให้เห็นว่าการสูญเสียโทเค็นการรีเฟรชจะไม่มีปัญหาเพราะไม่ทราบรหัสลูกค้าและความลับ นอกจากนี้ยังแสดงให้เห็นว่าการรักษาลูกค้าและรหัสลับของลูกค้าเป็นความลับที่สำคัญ

คำตอบนี้มาจาก Justin Richer ผ่านรายการอีเมลมาตรฐานของ OAuth 2 นี่คือการโพสต์ด้วยการอนุญาตของเขา

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

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

OpenID Connect ไม่เพียงให้ข้อมูลผู้ใช้แก่คุณจากโทเค็นการเข้าถึง แต่ยังให้โทเค็น ID ด้วย นี่เป็นข้อมูลแยกต่างหากที่ส่งตรงถึงลูกค้าไม่ใช่ AS หรือ RS ใน OIDC คุณควรพิจารณาว่าใครบางคน“ เข้าสู่ระบบ” จริง ๆ โดยโปรโตคอลถ้าคุณสามารถรับโทเค็น ID สด การรีเฟรชมันไม่น่าจะเพียงพอ

สำหรับข้อมูลเพิ่มเติมโปรดอ่านhttp://oauth.net/articles/authentication/

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

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

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

ทำไมไม่เพียงทำให้ access_token มีอายุการใช้งานนานกว่า refresh_token และไม่มี refresh_token อยู่ล่ะ

นอกจากคำตอบที่ยอดเยี่ยมที่คนอื่น ๆ ให้ไว้มีอีกเหตุผลว่าทำไมจะใช้โทเค็นรีเฟรชและเกี่ยวข้องกับการเรียกร้อง

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

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

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

คุณไม่สามารถยกเลิกโทเค็นการเข้าถึงได้เพียงโทเค็นการรีเฟรช

คำตอบนี้ได้รับการรวบรวมโดยความช่วยเหลือของผู้พัฒนาอาวุโสสองคน (John Brayton และ David Jennes)

เหตุผลหลักในการใช้โทเค็นการรีเฟรชคือการลดพื้นผิวการโจมตี

สมมุติว่าไม่มีรหัสรีเฟรชและลองดูตัวอย่างนี้:

อาคารมี 80 ประตู ประตูทุกบานถูกเปิดด้วยกุญแจเดียวกัน กุญแจจะเปลี่ยนทุกๆ 30 นาที ในตอนท้ายของ 30 นาทีฉันต้องมอบกุญแจเก่าแก่ผู้สร้างกุญแจและรับกุญแจใหม่

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

คำถาม: ในช่วง 30 นาทีที่ผ่านมาฉันมีโอกาสแฮ็คกุญแจจำนวนเท่าใด? ฉันมีโอกาสแฮ็ค 80 ครั้งทุกครั้งที่คุณใช้คีย์ (คิดว่านี่เป็นการร้องขอเครือข่ายและส่งโทเค็นการเข้าถึงเพื่อระบุตัวตนของคุณ) นั่นคือพื้นผิวการโจมตี 80X

ตอนนี้ลองทำตัวอย่างเดียวกัน แต่คราวนี้สมมติว่ามีคีย์รีเฟรช

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

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

คำถาม: ในช่วง 30 นาทีฉันมีโอกาสแฮ็คกับคีย์รีเฟรชกี่ครั้ง 80? ไม่ฉันมีโอกาสแฮ็คเพียง 1 ครั้งเท่านั้น ในช่วงเวลาที่ผู้ให้บริการจัดส่งสื่อสารกับผู้ผลิตกุญแจ นั่นคือพื้นผิวการโจมตี 1X ฉันมีโอกาสแฮ็คกับกุญแจ 80 ครั้ง แต่พวกเขาไม่ดีหลังจาก 30 นาที

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

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

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

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

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

การแบ่งส่วนเป็นสิ่งที่ดีสำหรับความปลอดภัย

สุดท้าย แต่ไม่ท้ายสุดก็เห็นคำตอบที่ยอดเยี่ยมนี้

โทเค็นการรีเฟรชใดที่ไม่เกี่ยวกับ

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

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

แต่ถ้าคุณมีrefresh_tokenที่access_tokenเวลาอยู่เป็นระยะสั้นเพื่อให้แฮ็กเกอร์เป็นเรื่องยากที่จะตัดของคุณaccess_tokenเพราะมันจะไม่ถูกต้องหลังจากช่วงเวลาสั้น ๆ Access_tokenสามารถดึงกลับมาได้โดยใช้ไม่เพียงrefresh_tokenแต่โดยclient_idและโดยclient_secretที่แฮ็กเกอร์คนนั้นไม่มี

ในขณะที่รีเฟรชโทเค็นจะถูกเก็บรักษาไว้โดยเซิร์ฟเวอร์การอนุญาต โทเค็นการเข้าถึงมีอยู่ในตัวเองเพื่อให้เซิร์ฟเวอร์ทรัพยากรสามารถตรวจสอบได้โดยไม่ต้องจัดเก็บซึ่งจะช่วยประหยัดการดึงข้อมูลในกรณีที่มีการตรวจสอบความถูกต้อง อีกจุดที่ขาดหายไปในการสนทนามาจาก rfc6749 # page-55

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

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

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

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

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

ขั้นแรกให้ลูกค้าตรวจสอบสิทธิ์กับเซิร์ฟเวอร์การอนุญาตโดยให้สิทธิ์การให้สิทธิ์

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

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

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

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

ไคลเอนต์รับรองความถูกต้องกับเซิร์ฟเวอร์การให้สิทธิ์โดยให้โทเค็นการรีเฟรช

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