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

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

โทเค็นการรีเฟรชจะหมดอายุหรือไม่

ดูการใช้ OAuth 2.0 เพื่อเข้าถึง Google APIสำหรับข้อมูลเพิ่มเติมเกี่ยวกับขั้นตอนการทำงานของ Google OAuth2

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

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

บางสถานการณ์อาจช่วยแสดงให้เห็นถึงจุดประสงค์ของการเข้าถึงและรีเฟรชโทเค็นและการแลกเปลี่ยนเชิงวิศวกรรมในการออกแบบระบบ oauth2 (หรือระบบตรวจสอบอื่น ๆ ):

สถานการณ์สมมติของเว็บแอป

ในสถานการณ์ของเว็บแอปคุณมีตัวเลือกสองทาง:

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

ลองนึกภาพว่ามีคนจัดการลักลอบเซสชันของคุณ สิ่งเดียวที่เป็นไปได้คือขอหน้าเว็บของคุณ

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

เปรียบเทียบ 1 และ 2:

ใน 1 access_token และ refresh_token เดินทางข้ามสายระหว่างเซิร์ฟเวอร์ authorzation (google ในกรณีของคุณ) และเซิร์ฟเวอร์แอปของคุณ นี้จะทำในช่องทางที่ปลอดภัย แฮ็กเกอร์สามารถจี้เซสชั่น แต่พวกเขาจะสามารถโต้ตอบกับแอปเว็บของคุณเท่านั้น ใน 2 แฮ็กเกอร์สามารถนำ access_token ออกไปและสร้างคำขอของพวกเขาเองไปยังทรัพยากรที่ผู้ใช้ได้ให้สิทธิ์การเข้าถึง แม้ว่าแฮ็กเกอร์จะเข้าถึง access_token พวกเขาจะมีเพียงหน้าต่างสั้น ๆ ที่พวกเขาสามารถเข้าถึงทรัพยากรได้

วิธีที่ refresh_token และ clientid / secret เป็นที่ทราบกันโดยเฉพาะกับเซิร์ฟเวอร์ทำให้เป็นไปไม่ได้จากเว็บเบราว์เซอร์ในการเข้าถึงระยะยาว

สมมติว่าคุณกำลังใช้ oauth2 และตั้งเวลาการเข้าถึงโทเค็นนาน:

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

สถานการณ์มือถือ

บนมือถือมีบางสถานการณ์ที่ฉันรู้:

1. เก็บ clientid / secret บนอุปกรณ์และให้อุปกรณ์ควบคุมการเข้าถึงทรัพยากรของผู้ใช้

2. ใช้เซิร์ฟเวอร์แอพพลิเคชั่นแบ็กเอนด์เพื่อเก็บ clientid / secret และทำการ orchestration ใช้ access_token เป็นคีย์เซสชันและส่งผ่านระหว่างไคลเอ็นต์และเซิร์ฟเวอร์แอป

เปรียบเทียบ 1 และ 2

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

ความยาวหมดอายุ

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

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

หวังว่าการโพสต์ความยาวค่อนข้างมีประโยชน์

นอกเหนือจากการตอบกลับอื่น ๆ :

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

ตัวอย่างของความเสี่ยงเหล่านั้นในชีวิตจริง:

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

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

• แอปพลิเคชันแบ็กเอนด์ RS สามารถเอาต์ซอร์ซไปยังบุคคลที่สามที่น่าเชื่อถือมากขึ้นหรือน้อยลง

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

ความคิดล่าสุด Refresh Tokens เสนอการป้องกันเพียงเล็กน้อยหากมีต่อลูกค้าที่ถูกบุกรุก

มันเป็นมาตรการรักษาความปลอดภัย หากแอปของคุณถูกโจมตีผู้โจมตีจะสามารถเข้าถึงโทเค็นการเข้าถึงระยะสั้นเท่านั้นและไม่มีวิธีการสร้างแอปใหม่

รีเฟรชโทเค็นยังหมดอายุ แต่พวกเขาควรจะมีชีวิตอยู่นานกว่าโทเค็นการเข้าถึง