PKCE: การรักษาความปลอดภัยให้ไคลเอนต์สาธารณะ

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

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

PKCE (RFC 7636) เพิ่มข้อมูลลับที่สร้างขึ้นแบบไดนามิกลงในกระบวนการรหัสการอนุญาต ก่อนเริ่มกระบวนการ ไคลเอนต์จะสร้างสตริงสุ่มที่ผ่านการสุ่มอย่างปลอดภัยทางการเข้ารหัสและมีความยาว 43-128 อักขระ เรียกว่าตัวตรวจสอบรหัส สตริงนี้ไม่ซ้ำกันในคำขอการอนุญาตแต่ละครั้ง และจะไม่ถูกส่งไปจนกว่าจะถึงขั้นตอนแลกเปลี่ยนโทเค็น

ไคลเอนต์คำนวณรหัสท้าทายจากตัวตรวจสอบรหัส: code_challenge = BASE64URL(SHA256(code_verifier)) การใช้ SHA256 เป็นวิธีที่ RFC 7636 กำหนด (วิธี "plain" ซึ่งส่งตัวตรวจสอบรหัสโดยตรงไม่ใช่วิธีที่แนะนำ) รหัสท้าทายเป็นการแปลงตัวตรวจสอบรหัสทางเดียว ซึ่งหมายความว่าการทราบรหัสท้าทายไม่ได้ทำให้ทราบตัวตรวจสอบรหัส

คำขอการอนุญาตจะมีพารามิเตอร์เพิ่มเติมสองรายการ: "code_challenge=BASE64URL(SHA256(verifier))&code_challenge_method=S256" เซิร์ฟเวอร์การอนุญาตจะจัดเก็บรหัสท้าทายที่เชื่อมโยงกับรหัสการอนุญาตที่ออกให้ ในขั้นตอนนี้จะไม่มีการส่งข้อมูลลับไปยังเซิร์ฟเวอร์ ซึ่งช่วยป้องกันไม่ให้ข้อมูลลับถูกดักจับ

ระหว่างการแลกเปลี่ยนโทเค็น (คำขอ POST ไปยังปลายทางโทเค็น) ไคลเอนต์จะส่ง "code_verifier=ORIGINAL_RANDOM_STRING" ไปพร้อมกับรหัสการอนุญาต เซิร์ฟเวอร์การอนุญาตจะคำนวณ BASE64URL(SHA256(code_verifier)) และตรวจสอบว่าตรงกับ code_challenge ที่จัดเก็บไว้ มีเพียงไคลเอนต์ที่ถูกต้องซึ่งสร้างตัวตรวจสอบรหัสเท่านั้นที่ผ่านการตรวจสอบนี้ได้

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

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

แม้ว่า RFC 7636 จะอธิบายไว้ในตอนแรกว่าเป็นวิธีแก้ปัญหาสำหรับไคลเอ็นต์สาธารณะ (ไคลเอ็นต์ที่ไม่มีความลับของไคลเอ็นต์) แต่ OAuth Security BCP และ OAuth 2.1 กำหนดให้ไคลเอ็นต์ทุกประเภทต้องใช้ PKCE รวมถึงไคลเอ็นต์แบบเก็บความลับที่มีความลับของไคลเอ็นต์ด้วย PKCE มอบการป้องกันที่ไม่ขึ้นกับการตรวจสอบสิทธิ์ของไคลเอ็นต์ จึงเป็นประโยชน์กับไคลเอ็นต์ทุกประเภท

OAuth 2.1 (draft-ietf-oauth-v2-1) รวบรวมแนวปฏิบัติที่ดีที่สุดด้านความปลอดภัยจาก OAuth 2.0 Security BCP ไว้ในเอกสารฉบับเดียว โดยกำหนดให้กระบวนการใช้รหัสการอนุญาตทุกแบบต้องใช้ PKCE ยกเลิกการใช้กระบวนการโดยนัย และกำหนดให้ต้องหมุนเวียนโทเค็นการต่ออายุ PKCE จึงเป็นพื้นฐานขั้นต่ำที่จำเป็นสำหรับการนำ OAuth 2.0 ไปใช้ใหม่ทุกกรณี

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

ใน PKCE ตัวตรวจสอบรหัสและค่าท้าทายรหัสมีความสัมพันธ์กันอย่างไร

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