รหัสสถานะ HTTP 401 หรือ 403? ความแตกต่างของข้อผิดพลาดการรับรองตัวตนและการอนุญาต

ทุกครั้งที่คุณโหลดเว็บเพจ ชำระเงิน หรือเข้าสู่แอป จะมีบทสนทนาที่มองไม่เห็นเกิดขึ้นระหว่างอุปกรณ์ของคุณกับเซิร์ฟเวอร์ มันเหมือนกับการส่งข้อความและรอคำตอบ—บางครั้งมันก็เป็นเครื่องหมายยกนิ้ว บางครั้งก็เป็นคำบอก 'ลองอีกครั้ง' และบางครั้ง มันก็คือ 'ไม่' อย่างตรงไปตรงมา การตอบสนองเหล่านี้ที่เรียกว่า HTTP status codes คือตัวช่วยเหลือที่ไม่มีใครรู้ของอินเตอร์เน็ต คอยแนะแนวการสื่อสารและทำให้ทุกอย่างทำงานได้อย่างราบรื่น—หรืออย่างน้อยก็จะบอกให้คุณรู้เมื่อมันไม่ราบรื่น

HTTP status codes คืออะไร#

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

200: ทุกอย่างสมบูรณ์แบบ#

คุณถามหาครัวซองต์ คนทำขนมยิ้มให้ ยื่นให้แล้วกล่าวว่า “นี่คุณได้เลย!” นั่นคือ HTTP 200 OK—คำขอสำเร็จ และทุกอย่างทำงานตามที่คาดไว้

รหัสสถานะ HTTP 200 OK เป็นหนึ่งในรหัสที่ใช้กันทั่วไปมากที่สุด แสดงว่าคำขอจากไคลเอนต์ได้รับแล้ว เข้าใจ และประมวลผลสำเร็จโดยเซิร์ฟเวอร์

301: เราได้ย้ายที่อยู่#

คุณมาถึงที่เบเกอรี่ที่ชื่นชอบ แต่มีป้ายบอกว่า “เราย้ายไปที่เลขที่ 123 ถนนใหม่” นี่คือ 301 Moved Permanently เซิร์ฟเวอร์บอกไคลเอนต์ของคุณให้ไปที่ที่อยู่ใหม่โดยอัตโนมัติ

รหัสสถานะ HTTP 301 Moved Permanently หมายถึงว่าทรัพยากรที่ขอได้ย้ายไปยัง URL ใหม่อย่างถาวร รหัสสถานะนี้แจ้งให้ไคลเอนต์ (เช่น เบราว์เซอร์หรือไคลเอนต์ API) อัปเดตบันทึกและใช้ URL ใหม่สำหรับคำขอในอนาคต

404: ขอโทษ ไม่มีที่นี่#

คุณถามหาคุกกี้ช็อกโกแลตแบบเป็นชิ้น และคนทำขนมกล่าวว่า “เราไม่ทำอันนั้นที่นี่” นั่นคือ 404 Not Found—ทรัพยากรที่คุณกำลังมองหาไม่มีอยู่บนเซิร์ฟเวอร์

รหัสสถานะ HTTP 404 Not Found หมายถึงว่าเซิร์ฟเวอร์ไม่พบทรัพยากรที่ขอ การตอบสนองนี้หมายความว่าคำขอของไคลเอนต์ถูกต้อง แต่เซิร์ฟเวอร์ไม่สามารถค้นหาทรัพยากรที่ถูกขอได้

401: คุณคือใคร?#

คุณพยายามเข้าห้องรับรอง VIP แต่เจ้าหน้าที่รักษาความปลอดภัยหยุดคุณและบอกว่า “คุณต้องแสดงบัตรสมาชิกของคุณ” นั่นคือ 401 Unauthorized—ต้องการการรับรองตัวตนก่อนเข้าถึงทรัพยากร

รหัสสถานะ HTTP 401 Unauthorized หมายถึงว่าคำขอของไคลเอนต์ยังไม่ได้รับการใช้เนื่องจากขาดข้อมูลประจำตัวที่ถูกต้อง เซิร์ฟเวอร์ต้องการให้ไคลเอนต์รับรองตัวตนเพื่อเข้าถึงทรัพยากรที่ขอ

403: ไม่ใช่สำหรับคุณ#

คุณแสดงบัตรสมาชิกของคุณ แต่เจ้าหน้าที่รักษาความปลอดภัยกล่าวว่า “เฉพาะสมาชิกแพลตินัมเท่านั้นที่สามารถเข้าได้” นั่นคือ 403 Forbidden—คุณได้รับการรับรองตัวตนแล้ว แต่ไม่มีสิทธิ์ที่จำเป็นในการเข้าถึงทรัพยากรนั้น

รหัสสถานะ HTTP 403 Forbidden หมายถึงว่าเซิร์ฟเวอร์เข้าใจคำขอของไคลเอนต์ แต่ปฏิเสธที่จะรองรับคำขอเนื่องจากไคลเอนต์ไม่มีสิทธิ์ที่จำเป็น นี่แตกต่างจากสถานะ 401 Unauthorized เพราะไคลเอนต์ได้รับการรับรองตัวตนแล้ว (หรือคำขอไม่ต้องการการรับรองตัวตน) แต่การเข้าถึงทรัพยากรถูกปฏิเสธอย่างชัดเจน

500: เตาอบมีไฟ#

คุณทำการสั่งซื้อตอนนี้ แต่จู่ๆ ควันเริ่มไหลออกมาจากครัว คนทำขนมบอกว่า “เราไม่สามารถรองรับคำสั่งของคุณได้; มีปัญหาภายในเกิดขึ้น” นั่นคือ 500 Internal Server Error—เซิร์ฟเวอร์พบปัญหาที่ไม่คาดคิด

รหัสสถานะ HTTP 500 Internal Server Error หมายถึงว่าเซิร์ฟเวอร์พบเงื่อนไขที่ไม่คาดคิดซึ่งทำให้ไม่สามารถรับรองคำขอได้ มันเป็นการตอบสนองข้อผิดพลาดทั่วไปและไม่ให้อธิบายรายละเอียดเฉพาะเกี่ยวกับสิ่งที่ผิดพลาด

503: ไม่มีชั่วคราว#

คุณเยี่ยมชมเบเกอรี่ แต่มีป้ายว่า “ปิดสำหรับการบำรุงรักษา” เบเกอรี่จะเปิดใหม่ในภายหลัง นั่นคือ 503 Service Unavailable—เซิร์ฟเวอร์ไม่สามารถรองรับคำขอของคุณชั่วคราว มักเนื่องจากการโอเวอร์โหลดหรือการบำรุงรักษา

รหัสสถานะ HTTP 503 Service Unavailable หมายถึงว่าเซิร์ฟเวอร์ไม่สามารถรองรับคำขอชั่วคราวได้ นี่อาจเกิดจากโอเวอร์โหลดเซิร์ฟเวอร์ การบำรุงรักษา หรือเงื่อนไขชั่วคราวอื่นๆ ไม่เหมือนกับ 500 Internal Server Error 503 บ่งบอกว่าสถานการณ์คาดว่าจะถูกแก้ไขเร็วๆ นี้

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

คิดถึงพวกมันเหมือนสัญญาณที่มืออาชีพและเป็นมาตรฐานในบทสนทนาของอินเตอร์เน็ต

ในบทความนี้ ฉันต้องการมุ่งเน้นไปที่ข้อผิดพลาด 401 และ 403 เนื่องจากพวกมันเกี่ยวข้องอย่างใกล้ชิดกับการรับรองตัวตน (AuthN) และการอนุญาต (AuthZ)

เมื่อใดควรใช้ 401 Unauthorized?#

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

401 unauthorized ต้องมีหัว WWW-Authenticate รวมถึงรายละเอียดเกี่ยวกับวิธีการรับรองตัวตน

ดังนั้น อะไรคือลักษณะการใช้งานทั่วไปของการใช้ 401 Unauthorized?

1. การรับรองตัวตนขาดหาย

   คำขอไม่มีข้อมูลประจำตัวการรับรองตัวตนที่ต้องการ ตัวอย่างเช่น: มีคำขอไปยังจุดสิ้นสุด API ที่ป้องกันโดยไม่มีหัว Authorization

2. ข้อมูลประจำตัวการรับรองตัวตนไม่ถูกต้อง

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

3. โทเค็นการรับรองตัวตนหมดอายุ

   โทเค็นการรับรองตัวตนมีค่า แต่หมดอายุ จำเป็นต้องให้ไคลเอนต์รับรองตัวตนใหม่ ตัวอย่าง: โทเค็น JWT กับวันที่หมดอายุที่ผ่านไป (claim exp)

4. หัว authorization ขาดหายหรือผิดรูป

   หัว authorization จำเป็นแต่ไม่ได้ให้มาหรือมีรูปแบบไม่ถูกต้อง

5. โปรแกรมรับรองตัวตนที่ไม่ได้รับการสนับสนุน

   เซิร์ฟเวอร์ไม่สนับสนุนวิธีการรับรองตัวตนที่ไคลเอนต์ให้ ตัวอย่างเช่น: ไคลเอนต์ส่งหัวการรับรองแบบ Basic แต่เซิร์ฟเวอร์สนับสนุนเฉพาะโทเค็น Bearer

6. การยกเลิกเซสชันหรือโทเค็นไม่ถูกต้อง

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

ตัวอย่างการตอบสนอง

เมื่อใดควรใช้ 403 Forbidden?#

รหัสสถานะ HTTP 403 Forbidden หมายถึงว่าเซิร์ฟเวอร์เข้าใจคำขอและตัวตนของไคลเอนต์ (หากรับรองตัวตนแล้ว) แต่ปฏิเสธการเข้าถึงเนื่องจากสิทธิ์ไม่เพียงพอ มันแสดงอย่างชัดเจนว่า “คุณไม่ได้รับอนุญาตให้ทำสิ่งนี้” ซึ่งแน่ใจว่าจะมีข้อจำกัดการเข้าถึงที่ชัดเจนและเสริมสร้างนโยบายความปลอดภัย

ความแตกต่างระหว่าง 401 Unauthorized และ 403 Forbidden อยู่ในบทบาทของพวกเขาภายในบริบทของการรับรองตัวตนและการอนุญาต

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

เพื่อดูความแตกต่างที่ละเอียดเกี่ยวกับ authN และ authZ ดูบทความเหล่านี้

What is AuthZ

What is AuthN

ดังนั้น อะไรคือลักษณะการใช้งานทั่วไปของการใช้ 403 Forbidden?

1. ได้รับการรับรองตัวตนแต่ขาดสิทธิ์

   ไคลเอนต์เข้าสู่ระบบหรือได้รับการรับรองตัวตนแต่ไม่มีสิทธิ์หรือบทบาทที่ต้องการ ตัวอย่าง: ผู้ใช้ที่มีบทบาท “viewer” พยายามลบไฟล์ ซึ่งต้องการสิทธิ์ “editor”

2. การจำกัดการเข้าถึงทรัพยากร

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

3. บล็อค IP หรือภูมิภาค

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

4. การกระทำที่ถูกบล็อคโดยนโยบาย

   ไคลเอนต์พยายามทำสิ่งที่ห้ามโดยนโยบายหรือกฎของเซิร์ฟเวอร์ ตัวอย่าง: ผู้ใช้พยายามปรับเปลี่ยนทรัพยากรที่ถูกทำเครื่องหมายว่า “อ่านอย่างเดียว”

5. ทรัพยากรคงที่ถูกบล็อค

   เซิร์ฟเวอร์ปฏิเสธการเข้าถึงไฟล์หรือไดเรกทอรีคงที่บางอย่างเพื่อเหตุผลด้านความปลอดภัย

   ตัวอย่าง: ผู้ใช้พยายามเข้าถึง .htaccess หรือไฟล์การตั้งค่าเซิร์ฟเวอร์

6. บัญชีถูกระงับหรือปิดการใช้งาน

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

7. การกระทำที่ต้องการสิทธิ์ที่ยกระดับ

   การกระทำที่ขอต้องการสิทธิพิเศษพิเศษ (เช่น admin หรือ superuser) ตัวอย่าง: ผู้ใช้ทั่วไปพยายามเข้าถึงจุดสิ้นสุดที่มีเฉพาะ admin

ตัวอย่างการตอบสนอง:

ฉันจะแก้ไขข้อผิดพลาด 401 unauthorized ได้อย่างไร#

ข้อผิดพลาด 401 โดยทั่วไปหมายถึงการรับรองตัวตนจำเป็นต้องและล้มเหลว

ตรวจสอบข้อมูลประจำตัว#

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

ตรวจสอบวิธีการรับรองตัวตน#

เซิร์ฟเวอร์อาจคาดหวังวิธีการรับรองตัวตนที่แตกต่างไปจากที่ให้ นี่อาจเกิดขึ้นถ้าไคลเอนต์และเซิร์ฟเวอร์ไม่สอดคล้องในโปรโตคอลการรับรองตัวตน ใช้วิธีการที่ถูกต้อง (เช่น Basic, Bearer, API Key) ตามที่ระบุโดยเซิร์ฟเวอร์และตรวจสอบไวยากรณ์ที่ถูกต้องในหัว

ตรวจสอบการตอบสนองของเซิร์ฟเวอร์#

ตรวจสอบเนื้อหาการตอบสนองเพื่อดูรายละเอียดข้อผิดพลาดและดูที่หัว WWW-Authenticate สำหรับคำแนะนำการรับรองตัวตน

ยืนยันคำขอ#

ยืนยันจุดสิ้นสุด, พารามิเตอร์คำถาม, และโฮสต์ว่ามีความถูกต้องและตรวจสอบว่าทรัพยากรที่คุณเข้าถึงต้องการการรับรองตัวตน

ตรวจสอบปัญหาโทเค็น#

ถอดรหัสและตรวจสอบโทเค็น (เช่น ด้วย https://logto.io/jwt-decoder) เพื่อความถูกต้อง, การหมดอายุ, และข้อเรียกร้องและตรวจสอบผู้ใช้งานของโทเค็น (aud) สอดคล้องกับข้อกำหนดของ API

ฉันจะแก้ไขข้อผิดพลาด 403 forbidden ได้อย่างไร#

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

ยืนยันสิทธิ์#

ยืนยันว่าบัญชีของคุณ, คีย์ API, หรือโทเค็นมีสิทธิ์ที่จำเป็นสำหรับทรัพยากร ตรวจสอบว่าทรัพยากรถูกจำกัดให้กับบทบาทหรือกลุ่มเฉพาะใดบ้าง

ยืนยันการรับรองตัวตนถูกต้อง#

ตรวจสอบให้แน่ใจว่าคุณได้รับการรับรองตัวตนอย่างถูกต้อง (เช่น ด้วยโทเค็นหรือข้อมูลประจำตัวที่ถูกต้อง)

ตรวจสอบวิธีการรับรองตัวตนที่เซิร์ฟเวอร์ต้องการสองครั้ง

ตรวจสอบทรัพยากร#

ยืนยันว่าทรัพยากรที่ขอมีอยู่และคุณมีการเข้าถึง ถ้าใช้ APIs ตรวจสอบข้อกำหนดจุดสิ้นสุดในเอกสาร

มองหาการบล็อก IP หรือที่ตั้ง#

ตรวจสอบว่าที่อยู่ IP ของคุณหรือที่ตั้งภูมิศาสตร์ถูกจำกัดโดยเซิร์ฟเวอร์

ตรวจสอบนโยบายเซิร์ฟเวอร์#

ตรวจสอบให้แน่ใจว่าการกระทำที่ขอไม่ละเมิดกฎหรือนโยบายเซิร์ฟเวอร์ (เช่น การเข้าถึงทรัพยากรแบบอ่านอย่างเดียว)

ตรวจสอบการตอบสนองของเซิร์ฟเวอร์#

วิเคราะห์เนื้อหาตอบสนองเพื่อดูรายละเอียดที่อธิบายเหตุผลของข้อผิดพลาด 403

คำขอเดียวจะสามารถคืนทั้ง 401 และ 403 ได้หรือไม่#

ไม่ คำขอ HTTP เดียวไม่สามารถคืนทั้งสถานะ 401 Unauthorized และ 403 Forbidden ในเวลาเดียวกันได้เพราะการตอบสนอง HTTP จะรวมเพียงหนึ่งสถานะ

การใช้จริงของรหัสข้อผิดพลาด 401 และ 403 ในการรับรองตัวตนและการอนุญาต#

ในการพัฒนาแอปพลิเคชันสมัยใหม่ 401 Unauthorized และ 403 Forbidden เป็นสองรหัสสถานะ HTTP ที่ผู้พัฒนาพบเจอบ่อย แม้ว่าพวกมันอาจดูคล้ายกัน แต่ความหมายและการใช้งานของพวกมันแตกต่างกันอย่างชัดเจน เพื่อทำให้ความแตกต่างของพวกมันชัดเจน บทความนี้นำเสนอการใช้เหล่านี้ในสถานการณ์จริง เช่น การรับรองตัวตน, การอนุญาต, การใช้งานหลายสัญชาติ และการรับรองตัวตนหลายปัจจัย (MFA)

1. สถานการณ์การเข้าสู่ระบบ: ผู้ใช้พยายามเข้าถึงหน้าเว็บที่ป้องกันโดยไม่เข้าสู่ระบบหรือให้ข้อมูลประจำตัวที่ถูกต้อง เซิร์ฟเวอร์ตอบและปล่อยข้อผิดพลาด 401 Unauthorized: “คุณต้องเข้าสู่ระบบหรือให้ข้อมูลประจำตัวที่ถูกต้องเพื่อเข้าถึงหน้านี้”
2. สถานการณ์การควบคุมการเข้าถึง: ผู้ใช้เดิมเข้าสู่ระบบสำเร็จแต่พยายามเข้าถึงหน้าเว็บที่เฉพาะผู้ดูแลระบบได้เท่านั้นโดยไม่มีบทบาทผู้ดูแลระบบ เซิร์ฟเวอร์ตอบและปล่อย 403 Forbidden: “คุณเข้าสู่ระบบแล้ว แต่คุณไม่มีสิทธิ์เข้าถึงหน้านี้”
3. สถานการณ์หลายสัญชาติ: ผู้ใช้เดิมเข้าสู่ระบบแล้วแต่เป็นของ Tenant A และพยายามเข้าถึงทรัพยากรใน Tenant B ซึ่งพวกเขาไม่มีการเข้าถึง เซิร์ฟเวอร์ตอบและปล่อย 403 Forbidden: “คุณได้รับการรับรองตัวตนแล้ว แต่คุณไม่มีสิทธิ์เข้าถึงทรัพยากรใน Tenant B”
4. สถานการณ์ MFA: ผู้ใช้พยายามเข้าสู่ระบบแต่ยังไม่ได้ทำการรับรองตัวตนหลายปัจจัย (MFA) ที่ต้องการให้เสร็จสิ้น เซิร์ฟเวอร์ตอบและปล่อยข้อผิดพลาด 401 Unauthorized: “การรับรองตัวตนยังไม่สมบูรณ์ โปรดทำ MFA ให้เสร็จสิ้นเพื่อดำเนินการต่อ”

การใช้ Logto เป็นผู้ให้บริการการรับรองตัวตนและการอนุญาต#

Logto เป็นผู้ให้บริการการรับรองตัวตนหลักที่ให้วิธีการสำคัญเช่นการเข้าสู่ระบบโดยไม่ใช้รหัสผ่าน อีเมลและรหัสผ่าน MFA SSO ขององค์กร และการเข้าสู่ระบบโซเชียล ทั้งหมดนี้เป็นไปตามโปรโตคอลมาตรฐานแบบเปิด เช่น OIDC, OAuth 2.0 และ SAML

Logto Cloud ยังให้คุณสมบัติการอนุญาตที่สำคัญ รวมถึง Role-Based Access Control (RBAC), Organizations (Multi-Tenancy) และ Custom Token Claims เพื่อตอบสนองความต้องการด้านการอนุญาตหลากหลาย