ทุกครั้งที่คุณโหลดเว็บเพจ ชำระเงิน หรือเข้าสู่แอป จะมีบทสนทนาที่มองไม่เห็นเกิดขึ้นระหว่างอุปกรณ์ของคุณกับเซิร์ฟเวอร์ มันเหมือนกับการส่งข้อความและรอคำตอบ—บางครั้งมันก็เป็นเครื่องหมายยกนิ้ว บางครั้งก็เป็นคำบอก 'ลองอีกครั้ง' และบางครั้ง มันก็คือ 'ไม่' อย่างตรงไปตรงมา การตอบสนองเหล่านี้ที่เรียกว่า 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?
การรับรองตัวตนขาดหาย
คำขอไม่มีข้อมูลประจำตัวการรับรองตัวตนที่ต้องการ ตัวอย่างเช่น: มีคำขอไปยังจุดสิ้นสุด API ที่ป้องกันโดยไม่มีหัว Authorization
ข้อมูลประจำตัวการรับรองตัวตนไม่ถูกต้อง
ไคลเอนต์ให้ข้อมูลประจำตัว แต่ผิดหรือไม่ตรงกับที่เซิร์ฟเวอร์ต้องการ ตัวอย่างเช่น ผู้ใช้ส่งคีย์ API ที่ผิดหรือโทเค็นที่ผิดรูป
โทเค็นการรับรองตัวตนหมดอายุ
โทเค็นการรับรองตัวตนมีค่า แต่หมดอายุ จำเป็นต้องให้ไคลเอนต์รับรองตัวตนใหม่ ตัวอย่าง: โทเค็น JWT กับวันที่หมดอายุที่ผ่านไป (claim exp)
หัว authorization ขาดหายหรือผิดรูป
หัว authorization จำเป็นแต่ไม่ได้ให้มาหรือมีรูปแบบไม่ถูกต้อง
โปรแกรมรับรองตัวตนที่ไม่ได้รับการสนับสนุน
เซิร์ฟเวอร์ไม่สนับสนุนวิธีการรับรองตัวตนที่ไคลเอนต์ให้ ตัวอย่างเช่น: ไคลเอนต์ส่งหัวการรับรองแบบ Basic แต่เซิร์ฟเวอร์สนับสนุนเฉพาะโทเค็น Bearer
การยกเลิกเซสชันหรือโทเค็นไม่ถูกต้อง
เซสชันของผู้ใช้ได้รับการยกเลิก หรือโทเค็นของพวกเขาถูกยกเลิก ตัวอย่างเช่น: ผู้ใช้ออกจากระบบ แต่โทเค็นเดียวกันใช้เพื่อเข้าถึงทรัพยากรที่ป้องกัน
ตัวอย่างการตอบสนอง
เมื่อใดควรใช้ 403 Forbidden?#
รหัสสถานะ HTTP 403 Forbidden หมายถึงว่าเซิร์ฟเวอร์เข้าใจคำขอและตัวตนของไคลเอนต์ (หากรับรองตัวตนแล้ว) แต่ปฏิเสธการเข้าถึงเนื่องจากสิทธิ์ไม่เพียงพอ มันแสดงอย่างชัดเจนว่า “คุณไม่ได้รับอนุญาตให้ทำสิ่งนี้” ซึ่งแน่ใจว่าจะมีข้อจำกัดการเข้าถึงที่ชัดเจนและเสริมสร้างนโยบายความปลอดภัย
ความแตกต่างระหว่าง 401 Unauthorized และ 403 Forbidden อยู่ในบทบาทของพวกเขาภายในบริบทของการรับรองตัวตนและการอนุญาต
การอนุญาตเป็นกลไกที่แยกต่างหากจาก authentication ในขณะที่การรับรองตัวตนระบุว่าคุณคือใคร การอนุมัติกำหนดว่าคุณสามารถเข้าถึงทรัพยากรใดและสามารถทำฟอร์มีต่าง ๆ ใด
เพื่อดูความแตกต่างที่ละเอียดเกี่ยวกับ authN และ authZ ดูบทความเหล่านี้
What is AuthZ
What is AuthN
ดังนั้น อะไรคือลักษณะการใช้งานทั่วไปของการใช้ 403 Forbidden?
ได้รับการรับรองตัวตนแต่ขาดสิทธิ์
ไคลเอนต์เข้าสู่ระบบหรือได้รับการรับรองตัวตนแต่ไม่มีสิทธิ์หรือบทบาทที่ต้องการ ตัวอย่าง: ผู้ใช้ที่มีบทบาท “viewer” พยายามลบไฟล์ ซึ่งต้องการสิทธิ์ “editor”
การจำกัดการเข้าถึงทรัพยากร
การเข้าถึงทรัพยากรถูกจำกัดให้เฉพาะผู้ใช้หรือกลุ่มบางกลุ่ม ตัวอย่างเช่น: เอกสารที่แบ่งปันเฉพาะกับผู้ใช้บางคนถูกเข้าถึงโดนคนที่ไม่อยู่ในรายการสิทธิ์เข้าถึง
บล็อค IP หรือภูมิภาค
ที่อยู่ IP ของไคลเอนต์หรือที่ตั้งภูมิศาสตร์ถูกบล็อคโดยเซิร์ฟเวอร์ ตัวอย่าง: ผู้ใช้จากภูมิภาคที่ถูกจำกัดพยายามเข้าถึงบริการที่ดำเนินการเฉพาะในบางประเทศ
การกระทำที่ถูกบล็อคโดยนโยบาย
ไคลเอนต์พยายามทำสิ่งที่ห้ามโดยนโยบายหรือกฎของเซิร์ฟเวอร์ ตัวอย่าง: ผู้ใช้พยายามปรับเปลี่ยนทรัพยากรที่ถูกทำเครื่องหมายว่า “อ่านอย่างเดียว”
ทรัพยากรคงที่ถูกบล็อค
เซิร์ฟเวอร์ปฏิเสธการเข้าถึงไฟล์หรือไดเรกทอรีคงที่บางอย่างเพื่อเหตุผลด้านความปลอดภัย
ตัวอย่าง: ผู้ใช้พยายามเข้าถึง .htaccess หรือไฟล์การตั้งค่าเซิร์ฟเวอร์
บัญชีถูกระงับหรือปิดการใช้งาน
บัญชีของไคลเอนต์ถูกปิดหรือถูกบล็อคเนื่องจากการละเมิดหรือการไม่ใช้งาน ตัวอย่าง: ผู้ใช้ที่มีบัญชีที่ถูกระงับพยายามเข้าสู่ระบบหรือเข้าถึงทรัพยากร
การกระทำที่ต้องการสิทธิ์ที่ยกระดับ
การกระทำที่ขอต้องการสิทธิพิเศษพิเศษ (เช่น 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)
สถานการณ์การเข้าสู่ระบบ: ผู้ใช้พยายามเข้าถึงหน้าเว็บที่ป้องกันโดยไม่เข้าสู่ระบบหรือให้ข้อมูลประจำตัวที่ถูกต้อง เซิร์ฟเวอร์ตอบและปล่อยข้อผิดพลาด 401 Unauthorized: “คุณต้องเข้าสู่ระบบหรือให้ข้อมูลประจำตัวที่ถูกต้องเพื่อเข้าถึงหน้านี้”
สถานการณ์การควบคุมการเข้าถึง: ผู้ใช้เดิมเข้าสู่ระบบสำเร็จแต่พยายามเข้าถึงหน้าเว็บที่เฉพาะผู้ดูแลระบบได้เท่านั้นโดยไม่มีบทบาทผู้ดูแลระบบ เซิร์ฟเวอร์ตอบและปล่อย 403 Forbidden: “คุณเข้าสู่ระบบแล้ว แต่คุณไม่มีสิทธิ์เข้าถึงหน้านี้”
สถานการณ์หลายสัญชาติ: ผู้ใช้เดิมเข้าสู่ระบบแล้วแต่เป็นของ Tenant A และพยายามเข้าถึงทรัพยากรใน Tenant B ซึ่งพวกเขาไม่มีการเข้าถึง เซิร์ฟเวอร์ตอบและปล่อย 403 Forbidden: “คุณได้รับการรับรองตัวตนแล้ว แต่คุณไม่มีสิทธิ์เข้าถึงทรัพยากรใน Tenant B”
สถานการณ์ 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 เพื่อตอบสนองความต้องการด้านการอนุญาตหลากหลาย