OAuth 2.1 มาแล้ว: สิ่งที่คุณต้องรู้

บทนำ#

ตั้งแต่ OAuth 2.0 (RFC 6749) ออกมาในปี 2012 โลกของเว็บและแอพบนมือถือก็เปลี่ยนไปมาก ผู้คนกำลังย้ายจากเดสก์ท็อปไปยังอุปกรณ์มือถือ และแอพพลิเคชันแบบหน้าเดียว (SPA) ก็กำลังเป็นที่นิยมเต็มที่ นอกจากนี้ยังมีเฟรมเวิร์กใหม่ ๆ และเทคโนโลยีเว็บเกิดขึ้นมากมายอีกด้วย ด้วยการเปลี่ยนแปลงเหล่านี้ ความท้าทายด้านความปลอดภัยก็เพิ่มขึ้นเช่นกัน เพื่อให้ทันกับเทคโนโลยีเว็บล่าสุด RFCs ใหม่ ๆ เช่น Proof Key for Code Exchange (PKCE) ถูกปล่อยออกมาอย่างต่อเนื่องเพื่อเพิ่มความสามารถให้กับ OAuth 2.0 มันได้กลายเป็นเรื่องจำเป็นที่จะรวมเอามาตรการที่ดีที่สุดสำหรับข้อกำหนดด้านความปลอดภัยของวันนี้ไว้ทั้งหมด นั่นคือเหตุผลที่ OAuth 2.1 กำลังจะมา

ใน OAuth 2.1 ที่กำลังจะมา กลุ่มการทำงาน OAuth ตั้งเป้าที่จะรวมเอามาตรการที่ดีที่สุดและข้อแนะนำด้านความปลอดภัยไว้ในเอกสารเดียว ที่ Logto เราให้ความสำคัญกับมาตรฐานและแนวปฏิบัติที่ดีที่สุดล่าสุดของ OAuth ในบทความนี้ เราจะสำรวจความแตกต่างหลักระหว่าง OAuth 2.0 และ OAuth 2.1 และวิธีที่พวกเขาได้รับการยอมรับใน Logto

PKCE ต้องใช้สำหรับผู้ใช้งาน OAuth ทั้งหมดที่ใช้ Authorization Code flow#

หนึ่งในความเปลี่ยนแปลงที่สำคัญที่สุดใน OAuth 2.1 คือ Proof Key for Code Exchange (PKCE) ต้องใช้สำหรับผู้ใช้งาน OAuth ทั้งหมดที่ใช้ Authorization Code flow PKCE เป็นส่วนขยายความปลอดภัยที่ป้องกันการแย่งชิงรหัสการอนุญาต มันมีประโยชน์อย่างยิ่งสำหรับแอปพลิเคชันบนมือถือและ SPA ที่ไม่สามารถเก็บความลับของลูกค้าได้อย่างปลอดภัย

ผู้ใช้งาน OAuth สามารถจัดเป็นสองประเภทตามความสามารถในการเก็บความลับได้อย่างปลอดภัย:

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

2. ลูกค้าสาธารณะ: ลูกค้าเหล่านี้ไม่สามารถเก็บความลับได้อย่างปลอดภัย เช่น แอปมือถือและ SPA ความลับของลูกค้าสามารถถูกสกัดจากโค้ดฝั่งลูกค้าได้อย่างง่ายดาย และยากที่จะปกป้องมันจากผู้โจมตี

สำหรับลูกค้าสาธารณะ PKCE เป็นมาตรการความปลอดภัยที่จำเป็น มันทำให้มั่นใจว่ารหัสการอนุญาตสามารถเปลี่ยนได้โดยลูกค้าที่ได้เรียกร้องคำขอการอนุญาตเท่านั้น

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

ใน OAuth 2.1 PKCE กลายเป็นข้อบังคับสำหรับลูกค้า OAuth ทั้งหมดที่ใช้ Authorization Code flow โดยไม่คำนึงถึงสถานะความลับของพวกเขา ไม่ว่าจะเป็นความลับหรือสาธารณะ การเปลี่ยนแปลงนี้ทำให้การป้องกันระหว่างการดักจับรหัสการอนุญาตเป็นไปอย่างเป็นสากล

ที่ Logto การตรวจสอบกระบวนการ PKCE ถูกเปิดใช้งานโดยอัตโนมัติสำหรับทั้งลูกค้าสาธารณะและลูกค้าที่เป็นความลับ

สำหรับ SPA และแอปมือถือ PKCE เป็นมาตรการความปลอดภัยที่จำเป็นในการปกป้องกระบวนการบริการรหัสการอนุญาตใน Logto คำขอการอนุญาตที่ขาดการท้าทายรหัสจะถูกปฏิเสธอย่างรวดเร็วโดยเซิร์ฟเวอร์การอนุญาตของ Logto

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

การจับคู่ URI การเปลี่ยนเส้นทางอย่างสมบูรณ์#

URI การเปลี่ยนเส้นทาง (Uniform Resource Identifier) คือตำแหน่งปลายทางหรือ URL เฉพาะที่เซิร์ฟเวอร์การอนุญาตเปลี่ยนเส้นทางผู้ใช้กลับหลังจากกระบวนการยืนยันและการอนุญาตสิ้นสุดลง

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

การจับคู่สตริง URI การเปลี่ยนเส้นทางอย่างสมบูรณ์ถูกแนะนำครั้งแรกใน OAuth 2.0 Security Best Current Practices ส่วนข้อ 4.1 แนวทางปฏิบัตินี้ทำให้มั่นใจว่า URI การเปลี่ยนเส้นทางต้องตรงกับคู่ที่ลงทะเบียนกับเซิร์ฟเวอร์การอนุญาต การเบี่ยงเบนใด ๆ จาก URI การเปลี่ยนเส้นทางที่ลงทะเบียนจะส่งผลให้เกิดคำตอบข้อผิดพลาด

เราได้รับคำร้องจากชุมชนมากมายเกี่ยวกับการนำการจับคู่แบบอักษรพิเศษสำหรับ URI การเปลี่ยนเส้นทางในขณะที่การจับคู่แบบอักษรพิเศษสามารถให้ความสะดวกสบายสำหรับนักพัฒนาที่จัดการหลายโดเมนย่อยหรือเส้นทาง โดยเฉพาะกับจำนวนโดเมนย่อยแบบสุ่มมาก มันยังแนะนำความเสียงของการโจมตีการเปลี่ยนเส้นทางที่เปิดอยู่ เช่นกัน สำหรับตัวอย่างการดูอันตรายจากการละเลยการตรวจสอบความถูกต้องของ URI การเปลี่ยนเส้นทาง โปรดดูที่บล็อกโพสต์ A brief OAuth security recap ของเรา

สอดคล้องกับมาตรฐานความปลอดภัยที่เข้มงวดของ OAuth 2.1 Logto ใช้การจับคู่สตริง URI การเปลี่ยนเส้นทางอย่างสมบูรณ์ การตัดสินใจนี้ให้ความสำคัญกับความปลอดภัยของกระบวนการ OAuth แทนที่จะใช้การจับคู่แบบอักษรพิเศษ เราแนะนำให้นักพัฒนาลงทะเบียน URI การเปลี่ยนเส้นทางที่เป็นไปได้ทั้งหมดกับเซิร์ฟเวอร์การอนุญาตของ Logto 这样的保护能够确保 URI การเปลี่ยนเส้นทางได้อย่างครบถ้วนและช่วยลดและสนับสนุนความสามารถในการป้องกันข้อเสียความปลอดภัยที่อาจเกิดขึ้น

การยุติกระบวนการไร้ซึ่งการให้สิทธิ์การประทับรับรอง#

กระบวนการการให้สิทธิ์ที่ไม่มีใน OAuth 2.0 ถูกออกแบบสำหรับ SPAs ที่บนเว็บไซต์สามารถใช้ส่งตรงของผู้ใช้อย่างถาวรลงใน URL fragment หลังการยืนยันของผู้ใช้ และเข้าไปได้โดยตรงโดยเวลา

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

ใน OAuth 2.0 Security Best Current Practices ได้กล่าวไว้ชัดเจนว่า:

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

ดังนั้น กระบวนการที่ไม่มีการให้สิทธิ์ได้รับการยุติออกจาก OAuth 2.1 อย่างเป็นทางการ

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

การยุติกระบวนการยินยอมรหัสเจ้าของทรัพยากร (ROPC)#

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

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

ต่อมาในส่วนที่ 2.4 ของ OAuth 2.0 Security Best Current Practices การห้ามใช้ประเภทการอนุญาต ROPC ได้เน้นย้ำอีกครั้งว่า ไม่ควรใช้เป็นเด็ดขาด เป็นผลให้ประเภทการอนุญาต ROPC ถูกถอดออกจากสเปคของ OAuth 2.1

เนื่องจากความเสี่ยงด้านความปลอดภัยสูงที่เกี่ยวข้องกับประเภทการอนุญาต ROPC ทาง Logto จึงไม่เคยรองรับมัน หากใครยังคงใช้กระบวนการยืนยันผู้ใช้งานด้วยชื่อผู้ใช้และรหัสผ่านในแอปพลิเคชันที่มีอยู่เดิมของคุณ เราขอแนะนำให้ย้ายไปใช้วิธีที่ปลอดภัยกว่า เช่น การใช้กระบวนการรหัสการอนุญาตหรือการอนุญาตของลูกค้าเท่านั้น Logto มี SDKs ต่าง ๆ และแนวทางในการรวมกระบวนการ OAuth ที่ปลอดภัยเหล่านี้ในแอปพลิเคชันของคุณได้อย่างไร้รอยต่อ

เราเข้าใจว่านักพัฒนาอาจต้องการออกแบบหรือโฮสต์อินเตอร์เฟซลงชื่อเข้าใช้ด้วยตัวเองเพื่อประสบการณ์ผลิตภัณฑ์ที่ดีที่สุด ที่ Logto เรามีตัวเลือกการปรับแต่งประสบการณ์การลงชื่อเข้าใช้ (SIE) หลากหลาย รวมถึงการตั้งค่าแบรนด์และ CSS ที่กำหนดได้ นอกจากนี้เรายังมีโครงการที่กำลังดำเนินการอื่น ๆ เช่น การนำ UI ของคุณมาเอง และการลงชื่อเข้าใช้โดยตรง เพื่อให้นักพัฒนามีความยืดหยุ่นมากขึ้นในการนำอินเตอร์เฟซลงชื่อเข้าใช้ของตนเองมาใช้งานในขณะที่ยังรักษาความปลอดภัยการใช้งาน OAuth ตามมาตรฐาน

สรุป#

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