ไทย

oauth
การไหลแฝง
รหัสการอนุญาต
PKCE

การไหลแฝง vs. การไหลของรหัสการอนุญาต: ทำไมการไหลแฝงถึงไม่ปลอดภัยอีกต่อไป?

ทำไมถึงมี "การไหลของรหัสการอนุญาต" ใน OAuth 2.0 ทั้งที่มี "การไหลแฝง" อยู่แล้ว? มาค้นหารายละเอียดเกี่ยวกับสองประเภทนี้และเข้าใจว่าทำไมคุณควรหลีกเลี่ยงการใช้การไหลแฝง

Darcy Ye

Developer

1/3/2024

หยุดเสียเวลาเป็นสัปดาห์กับการยืนยันตัวตนผู้ใช้

เปิดตัวแอปที่ปลอดภัยเร็วขึ้นด้วย Logto ผสานการยืนยันตัวตนผู้ใช้ภายในไม่กี่นาทีและมุ่งเน้นที่ผลิตภัณฑ์หลักของคุณ

เริ่มต้นใช้งาน

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

ในบทความนี้ เราจะสำรวจความแตกต่างระหว่างทั้งสองประเภทรหัสนี้และให้เหตุผลว่าทำไมคุณควรหลีกเลี่ยงการใช้การไหลแฝงมากกว่าไปใช้การไหลของรหัสการอนุญาต

OAuth 2.0 คืออะไร?

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

เมื่อคนพูดถึง OAuth เรามักหมายถึง OAuth 2.0 หรือที่รู้จักว่า "Open Authorization" ซึ่งเป็นโปรโตคอลที่ขนาดเล็กซึ่งอนุญาตให้เว็บไซต์หรือแอปพลิเคชันใช้ทรัพยากรจากบริการเว็บอื่น ๆ ในนามของผู้ใช้ มันเข้ามาแทนที่ OAuth 1.0 ในปี 2012 และนับแต่นั้นได้กลายเป็นมาตรฐานที่ได้รับการยอมรับอย่างกว้างขวางสำหรับการอนุญาตทางดิจิตอล OAuth 2.0 ถูกออกแบบมาเพื่อให้การเข้าถึงที่มีการควบคุมสำหรับผู้ใช้ โดยอนุญาตให้แอปพลิเคชันลูกค้าหรือที่เรียกว่าแอปพลิเคชันผู้ใช้งานมีสิทธิพิเศษเฉพาะในการโต้ตอบกับทรัพยากรที่แสดงถึงผู้ใช้ โดยทั้งหมดนี้จะไม่เปิดเผยรายละเอียดการเข้าสู่ระบบของผู้ใช้

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

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

การไหลแฝงคืออะไร?

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

การไหลแฝงทำงานอย่างไร?

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

ความเสี่ยงด้านความปลอดภัยของการไหลแฝง

การไหลแฝงมีช่องโหว่ด้านความปลอดภัยหลายประการ:

การเปิดเผยโทเค็น: โทเค็นการเข้าถึงถูกส่งกลับไปยังลูกค้าใน URL fragment ซึ่งสามารถถูกดักจับได้ง่ายโดยฝ่ายโจมตีที่มีเจตนาไม่ดี ทำให้โทเค็นการเข้าถึงมีความเสี่ยงที่จะถูกขโมยและใช้งานผิด
การโจมตี CSRF: การไหลแฝงมีความเสี่ยงต่อการถูกโจมตี Cross-Site Request Forgery (CSRF) ซึ่งเว็บไซต์ที่เป็นอันตรายสามารถหลอกล่อผู้ใช้ให้อนุญาตการเข้าถึงที่ไม่ได้รับอนุญาตให้แก่บัญชีของพวกเขา

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

การไหลของรหัสการอนุญาตคืออะไร?

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

การไหลของรหัสการอนุญาตทำงานอย่างไรสำหรับลูกค้าเอกชนที่มีส่วนประกอบเซิร์ฟเวอร์?

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

การไหลของรหัสการอนุญาตทำงานอย่างไรสำหรับลูกค้าสาธารณะด้วย PKCE?

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

ศึกษาข้อมูลเพิ่มเติมเกี่ยวกับ PKCE