401 Unauthorized คืออะไร? และทำไมชื่อมันหลอก

401 กับ 403 และเพื่อนบ้าน

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

เฮดเดอร์ที่ทุกคนลืม

สเปกของ HTTP เขียนไว้ชัดว่า response 401 ต้องมีเฮดเดอร์ WWW-Authenticate บอกวิธีพิสูจน์ตัวตนมาด้วย 401 ที่ไม่มีเฮดเดอร์นี้ถือว่าเป็น response ที่ไม่ถูกต้องตามสเปก

ในทางปฏิบัติ API จำนวนมากตอบ 401 เปล่า ๆ พร้อม JSON โดยไม่มีเฮดเดอร์นี้ ทั้งที่เบราว์เซอร์และ HTTP client ใช้มันตัดสินใจว่าจะทำอะไรต่อ — มันคือเฮดเดอร์ที่ทำให้เบราว์เซอร์เด้งกล่องใส่ username/password ของ basic auth ขึ้นมา

ถ้าคุณกำลังเขียน API ให้ส่งมันด้วย ใช้ "WWW-Authenticate: Bearer" สำหรับ token หรือ "WWW-Authenticate: Basic realm=..." สำหรับ basic auth ส่วนถ้ากำลังไล่ปัญหา API ของคนอื่น การที่ไม่มีเฮดเดอร์นี้บอกเราว่า 401 ตัวนั้นเขียนขึ้นเองในโค้ด ไม่ได้มาจากชั้น auth มาตรฐาน ซึ่งเป็นเบาะแสว่าควรไปดูตรงไหน

สาเหตุที่เจอบ่อย เรียงจากมากไปน้อย

• token หมดอายุ access token ส่วนใหญ่ออกแบบให้อายุสั้นอยู่แล้ว วิธีแก้คือขอใหม่ ไม่ใช่ไปยืดอายุมัน
• API key ผิดหรือไม่ได้ส่ง เช็กว่าใช้ key ของสภาพแวดล้อมที่ถูกต้อง — เอา key ของ staging ไปยิง production ได้ 401 แบบนี้พอดี
• รูปแบบ Authorization header ผิด พิมพ์ "Bearer" ตัวใหญ่เล็กไม่ตรง ลืมเว้นวรรค หรือมีตัวขึ้นบรรทัดใหม่ติดมาจากการก๊อปวาง — พังเงียบ ๆ ทั้งนั้น
• ตั้งค่า basic auth ผิดฝั่งเซิร์ฟเวอร์ พาธไปยัง .htpasswd ผิด หรือไฟล์รหัสผ่านถูกสร้างด้วยรูปแบบ hash ที่เซิร์ฟเวอร์อ่านไม่ได้
• เซสชันหมดอายุ กับเว็บทั่วไปนี่คือกรณี "ถูก logout" ธรรมดา ไม่ใช่บั๊ก
• นาฬิกาเซิร์ฟเวอร์เพี้ยนเมื่อใช้ JWT ถ้าเวลาต่างกันเกินค่าที่ token ยอมรับ token ที่ยังใช้ได้จะถูกปฏิเสธว่า "ยังไม่ถึงเวลา" หรือ "หมดอายุ" ให้เช็กเวลาทั้งสองเครื่อง
• Authorization header หายระหว่างทาง — อยู่ในหัวข้อถัดไป เพราะเป็นตัวที่กินเวลามากที่สุด

กับดัก: proxy ที่กิน Authorization header

หัวข้อนี้ต้องแยกออกมาเพราะโค้ดถูก ข้อมูลรับรองถูก แต่ยังได้ 401 อยู่ดี

reverse proxy และ CGI บางแบบตัดเฮดเดอร์ Authorization ทิ้งก่อนที่มันจะไปถึงแอปพลิเคชัน Apache ที่ใช้ mod_cgi กับ PHP-FPM คือเคสคลาสสิก — ถ้าไม่เปิด CGIPassAuth หรือไม่ได้ส่งต่อเฮดเดอร์ไว้ชัด ๆ ฝั่ง PHP จะไม่เห็นมันเลย และทุก request ที่ยืนยันตัวตนมาแล้วจะกลายเป็นไม่ระบุตัวตนหมด

อาการที่บ่งชี้ชัดคือ request เดียวกันยิงตรงเข้าพอร์ตของแอปแล้วผ่าน แต่ยิงผ่าน URL สาธารณะแล้วไม่ผ่าน ถ้าทำให้เกิดความต่างนี้ได้ แปลว่าปัญหาอยู่ที่ชั้น proxy ไม่ใช่โค้ด auth ของเรา

วิธียืนยัน: log เฮดเดอร์ดิบที่แอปได้รับจริง ๆ ถ้าไม่มี Authorization ในนั้นทั้งที่ฝั่ง client ส่งแน่ ๆ แปลว่ามีอะไรระหว่างทางเอาออกไป ถ้าเป็น Apache ให้เพิ่ม "CGIPassAuth On" ถ้าเป็น Nginx ให้เช็กว่าบล็อก proxy_pass ไม่ได้กรองมันทิ้ง ถ้าใช้โฮสติ้งสำเร็จรูปให้ถามซัพพอร์ตว่าส่งเฮดเดอร์นี้ผ่านไหม

ไล่ตรวจตามลำดับนี้

• ยืนยันก่อนว่าข้อมูลรับรองถูกส่งออกไปจริง log เฮดเดอร์ฝั่ง client หรือใช้ "curl -v" ซึ่งจะพิมพ์สิ่งที่ส่งออกไปให้ดู
• ทดสอบข้อมูลรับรองเดียวกันด้วย curl ยิงตรงไปที่ endpoint ถ้า curl ผ่านแต่แอปเราไม่ผ่าน ปัญหาอยู่ที่ client ของเรา ไม่ใช่เซิร์ฟเวอร์
• เช็กว่า token ยังไม่หมดอายุ ถ้าเป็น JWT ให้ถอดรหัสดูค่า exp — อย่าเดา ให้ดูของจริง
• เทียบนาฬิกาเซิร์ฟเวอร์ถ้าเกี่ยวกับ JWT เวลาเพี้ยนแค่ไม่กี่นาทีก็ทำให้ token ที่ใช้ได้ถูกปฏิเสธ
• log เฮดเดอร์ที่เซิร์ฟเวอร์ได้รับจริง นี่คือจุดที่เฮดเดอร์ที่ถูกตัดทิ้งจะโผล่ให้เห็น
• เช็กว่า endpoint ต้องการรูปแบบไหน บาง API ต้องการ "Bearer <token>" บางตัวต้องการเฮดเดอร์ "X-API-Key" บางตัวรับผ่าน query parameter — ส่งค่าที่ถูกแต่ผิดวิธีก็ยังได้ 401
• อ่าน body ของ response หลาย API ใส่รหัสข้อผิดพลาดใน JSON ที่แยกได้ว่า "หมดอายุ" "ไม่ถูกต้อง" หรือ "ถูกเพิกถอน" ซึ่งเป็นคนละปัญหาและแก้คนละแบบ

ถ้าเราเป็นคนตั้งระบบป้องกันเอง

เมื่อเราเป็นฝ่ายส่ง 401 ออกไป มีไม่กี่ข้อที่ทำแล้วชีวิตทุกคนง่ายขึ้นมาก

ส่ง WWW-Authenticate เสมอตามที่บอกไปข้างบน มันเป็นข้อบังคับ และเป็นตัวที่บอก client ว่าต้องทำอะไรต่อ

แยก "หมดอายุ" ออกจาก "ไม่ถูกต้อง" ใน body คำว่า token หมดอายุบอก client ให้ไปขอใหม่ ส่วน token ไม่ถูกต้องบอกให้เริ่มยืนยันตัวตนใหม่ทั้งหมด ถ้าตอบข้อความคลุมเครือเหมือนกันทั้งสองกรณี client ก็ต้องเดาเอา

อย่าใช้ 401 เพื่อซ่อนว่ามีทรัพยากรอยู่จริง ถ้าต้องการปกปิดว่ามีของอยู่ไหมให้ตอบ 404 ซึ่งเป็นแนวปฏิบัติที่ยอมรับกัน เพราะ 401 เป็นการยืนยันว่ามีของอยู่และคุ้มค่าที่จะพยายามเข้า

จำกัดจำนวนครั้งที่ยืนยันตัวตนล้มเหลว endpoint ที่ตอบ 401 คือเป้าหมายของเครื่องมือยิงรหัสผ่านโดยตรง การเปิด endpoint ล็อกอินไว้ไม่จำกัดคือการเชิญให้มาลอง

ใช้ basic auth บน HTTPS เท่านั้น basic auth ส่งข้อมูลรับรองในรูปที่ถอดกลับได้ง่ายมาก ถ้าวิ่งบน HTTP ธรรมดาก็เท่ากับส่งรหัสผ่านแบบเปิดเผย