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

การไหลของรหัสการอนุญาต และ การไหลแฝง เป็นสองประเภทกระบวนการที่ใช้บ่อยใน 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 ของโทเค็นได้ด้วยข้อจำกัดของเบราว์เซอร์

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

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

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

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

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

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

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

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

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

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

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

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

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

การไหลแฝง vs. การไหลของรหัสการอนุญาต#

การไหลของรหัสการอนุญาตสามารถขจัดปัญหาด้านความปลอดภัยของการไหลแฝงได้หรือไม่?#

คำตอบคือ ใช่:

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

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

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