ประวัติศาสตร์ของ OAuth: จากรหัสผ่านสู่มาตรฐานระดับโลก
คุณเห็นสิ่งนี้อยู่ทุกวัน คุณคลิก "Login with Google" หรือ "Login with GitHub" โดยไม่ต้องพิมพ์รหัสผ่าน และเข้าสู่เว็บไซต์ได้ทันที
สิ่งนี้ทำงานได้เพราะ OAuth ซึ่งเป็นมาตรฐานความปลอดภัยระดับโลก แต่มันไม่ได้เริ่มต้นมาแบบนี้ แต่มันวิวัฒนาการขึ้นมาเพื่อแก้ปัญหาใหญ่ๆ หลายอย่าง
ปัญหาของรหัสผ่าน
ในยุคแรกๆ คุณต้องสร้างรหัสผ่านใหม่สำหรับทุกเว็บไซต์ ซึ่งทำให้เกิดปัญหาใหญ่ 3 ประการ:
- ผู้คนใช้รหัสผ่านเดียวกันในทุกที่ หากเว็บไซต์หนึ่งข้อมูลรั่วไหล บัญชีอื่นๆ ทั้งหมดก็ตกอยู่ในความเสี่ยง
- ผู้คนลืมรหัสผ่าน พวกเขาเสียเวลาไปกับการคลิก "forgot password" มากกว่าการใช้งานเว็บเสียอีก
- เว็บไซต์เห็นรหัสผ่านดิบของคุณ หากเว็บไซต์ถูกแฮ็ก รหัสผ่านของคุณก็จะหลุดออกไปทันที
วิวัฒนาการของความปลอดภัย
Basic Auth: คุณส่งชื่อผู้ใช้และรหัสผ่านไปพร้อมกับทุกคำขอ หากคุณไม่ได้ใช้ HTTPS แฮ็กเกอร์ก็สามารถเห็นข้อมูลทุกอย่างได้
Session Cookies: คุณล็อกอินเพียงครั้งเดียวและได้รับ session ID ซึ่งดีขึ้นกว่าเดิม แต่คุกกี้สามารถถูกขโมยได้ผ่านการโจมตีอย่าง XSS หรือ CSRF นอกจากนี้ เว็บไซต์หนึ่งยังไม่สามารถใช้การล็อกอินของคุณเพื่อสื่อสารกับอีกเว็บไซต์หนึ่งได้
API Keys: คุณมอบคีย์พิเศษให้กับเว็บไซต์ ซึ่งดีกว่าเพราะคุณไม่ต้องส่งรหัสผ่าน อย่างไรก็ตาม API keys มักจะมีอำนาจมากเกินไป หากคุณให้ API key แก่แอปหนึ่ง แอปนั้นอาจมีอำนาจในการอ่านอีเมล ส่งข้อความ และลบชื่อบัญชีของคุณได้ มันเหมือนกับการที่คุณมอบกุญแจรถให้พนักงานรับรถ (valet) ของโรงแรม แต่กุญแจนั้นดันเปิดประตูบ้านคุณได้ด้วย
ทางออกของ OAuth: กุญแจ valet
OAuth เปลี่ยนเกมนี้ไปอย่างสิ้นเชิง แทนที่จะให้รหัสผ่าน คุณจะให้ "token" แทน ให้ลองนึกภาพว่ามันคือกุญแจ valet กุญแจ valet ช่วยให้คนขับรถสามารถจอดรถให้คุณได้ แต่ไม่สามารถเปิดกระโปรงท้ายรถหรือเข้าถึงบ้านของคุณได้
การทำงานของ OAuth ในทางปฏิบัติ:
- คุณต้องการใช้ Canva และดึงรูปภาพจาก Google
- Canva ขออนุญาตจาก Google
- Google ถามคุณว่า: "Canva สามารถดูรูปภาพของคุณได้หรือไม่?"
- คุณตอบว่า: "ได้ แต่ให้ดูได้อย่างเดียว ห้ามลบอะไรทั้งนั้น"
- Google มอบ token เฉพาะเจาะจงให้แก่ Canva
Canva จะไม่มีวันเห็นรหัสผ่าน Google ของคุณ แม้ว่าแฮ็กเกอร์จะขโมย token นั้นไปได้ พวกเขาก็ทำได้เพียงดูรูปภาพในช่วงเวลาสั้นๆ เท่านั้น พวกเขาไม่สามารถเปลี่ยนรหัสผ่านหรือโอนเงินของคุณได้
ความปลอดภัยสมัยใหม่: PKCE
แอปมือถือและเว็บแอปมีจุดอ่อนอย่างหนึ่ง คือพวกมันไม่สามารถซ่อนความลับได้ดีนัก เพื่อแก้ไขปัญหานี้ เราจึงใช้ PKCE (Proof Key for Code Exchange)
มันทำงานเหมือนกับระบบการจอง:
- แอปสร้างรหัสลับขึ้นมา (the verifier)
- แอปส่งรหัสที่ผ่านการ hash แล้ว (the challenge) ไปยัง Google
- เมื่อแอปขอ token มันจะส่งรหัสลับต้นฉบับไปด้วย
- Google จะตรวจสอบว่ารหัสตรงกับ challenge หรือไม่
หากตรงกัน Google จะทราบว่าเป็นแอปเดิม หากไม่ตรงกัน Google จะบล็อกคำขอนั้น สิ่งนี้ช่วยป้องกันไม่ให้แฮ็กเกอร์ขโมย authorization code ของคุณได้
แผนผังเส้นทางของ OAuth
- 2007 (OAuth 1.0): ซับซ้อนมากและใช้คณิตศาสตร์ขั้นสูง
- 2012 (OAuth 2.0): เร็วขึ้นและง่ายขึ้น โดยใช้ token และต้องใช้ HTTPS
- 2016 (OAuth 2.0 + PKCE): เพิ่มความปลอดภัยสำหรับแอปมือถือและเว็บแอปสมัยใหม่
- 2023 (OAuth 2.1): มาตรฐานระดับทอง (gold standard) ใหม่ ซึ่งตัดวิธีการเก่าๆ ที่ไม่ปลอดภัยออกไป
บทเรียนสำคัญ: อย่าให้รหัสผ่านของคุณกับแอปอื่น แต่ให้ "ตั๋ว" ที่มีขอบเขตจำกัดและมีวันหมดอายุแทน เพื่อให้คุณยังคงเป็นผู้ควบคุมทุกอย่าง
ที่มา: https://dev.to/gophernment/oauth-elaaaebbprawatisaastr-cchaakrhasphaan-suumaatrthaanolk-16b4