จุดประสงค์ของ“ Refresh Token” คืออะไร?


96

ฉันมีโปรแกรมที่ทำงานร่วมกับ YouTube Live Streaming API มันทำงานบนตัวจับเวลาดังนั้นมันจึงค่อนข้างง่ายสำหรับฉันที่จะตั้งโปรแกรมเพื่อดึง Access Token ใหม่ทุกๆ 50 นาทีด้วย Refresh Token คำถามของฉันคือทำไม?

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



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

คำตอบ:


90

โดยทั่วไปจะใช้โทเค็นการรีเฟรชเพื่อรับโทเค็นการเข้าถึงใหม่

เพื่อแยกความแตกต่างอย่างชัดเจนของโทเค็นทั้งสองนี้และหลีกเลี่ยงการปะปนกันต่อไปนี้เป็นฟังก์ชันที่กำหนดในOAuth 2.0 Authorization Framework :

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

ตอนนี้เพื่อตอบคำถามของคุณเกี่ยวกับสาเหตุที่คุณยังคงได้รับโทเค็นการรีเฟรชแทนที่จะเป็นเพียงการรักษาความปลอดภัยโทเค็นการเข้าถึงเหตุผลหลักที่ Internet Engineering Task Force จัดทำขึ้นในโทเค็นการรีเฟรชคือ:

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

สำหรับข้อมูลที่ละเอียดและสมบูรณ์ของ OAuth 2.0 Flow โปรดลองอ่านข้อมูลอ้างอิงต่อไปนี้:


5
โทเค็นการรีเฟรชควรช่วยรับโทเค็นการรีเฟรชใหม่ด้วยหรือไม่
Gherman

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

2
@JustAMartin ในฐานะไคลเอ็นต์ OAuth2 หากไม่มีโทเค็นการรีเฟรชฉันจะต้องเริ่มขั้นตอนการอนุญาตทั้งหมดอีกครั้ง (ให้ผู้ใช้ 'เข้าสู่ระบบ' และให้สิทธิ์อีกครั้ง การรีเฟรชโทเค็นข้ามข้อกำหนดนี้เป็น 'หลักฐาน' ประเภทหนึ่งว่าฉันในฐานะลูกค้าได้รับอนุญาตจากผู้ใช้ในการขอโทเค็นการเข้าถึงแล้ว
jrahhali

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

8

@Teyam กล่าวถึง SO post เหตุใด OAuth v2 จึงมีทั้งการเข้าถึงและรีเฟรชโทเค็น แต่ฉันชอบคำตอบอื่นที่นั่น: https://stackoverflow.com/a/12885823/254109

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


3
ยกเว้นมีเหตุผลด้านความปลอดภัยตามที่ @Teyam กล่าวไว้: "refresh_token จะแลกเปลี่ยนกับเซิร์ฟเวอร์การอนุญาตเท่านั้นในขณะที่ access_token แลกเปลี่ยนกับเซิร์ฟเวอร์ทรัพยากร"
huyz

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

6

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

รีเฟรชโทเค็นเพื่อไม่ให้ผู้ใช้รำคาญ

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

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

รีเฟรชโทเค็นเพื่อเพิ่มความปลอดภัย

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

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

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


5

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.