Untuk halaman web yang ada, tetapi yang pengguna tidak memiliki hak istimewa yang memadai (mereka tidak masuk atau tidak termasuk kelompok pengguna yang tepat), apa tanggapan HTTP yang tepat untuk dilayani?

401 Unauthorized?
403 Forbidden?
Sesuatu yang lain

Apa yang saya baca pada masing-masing sejauh ini tidak begitu jelas tentang perbedaan antara keduanya. Kasus penggunaan apa yang sesuai untuk setiap respons?

Penjelasan yang jelas dari Daniel Irvine :

Ada masalah dengan 401 Tidak Resmi , kode status HTTP untuk kesalahan otentikasi. Dan hanya itu: itu untuk otentikasi, bukan otorisasi. Menerima respons 401 adalah server memberi tahu Anda, "Anda tidak diautentikasi - baik tidak diautentikasi sama sekali atau diautentikasi secara tidak benar - tetapi harap diautentikasi ulang dan coba lagi." Untuk membantu Anda, itu akan selalu menyertakan header WWW-Otentikasi yang menjelaskan cara mengotentikasi.

Ini adalah respons yang umumnya dikembalikan oleh server web Anda, bukan aplikasi web Anda.

Itu juga sesuatu yang sangat sementara; server meminta Anda untuk mencoba lagi.

Jadi, untuk otorisasi saya menggunakan respons Terlarang 403 . Ini permanen, ini terkait dengan logika aplikasi saya, dan ini merupakan respons yang lebih konkret daripada 401.

Menerima respons 403 adalah server memberi tahu Anda, “Maaf. Saya tahu siapa Anda - saya percaya siapa yang Anda katakan - tetapi Anda tidak memiliki izin untuk mengakses sumber ini. Mungkin jika Anda bertanya kepada administrator sistem dengan baik, Anda akan mendapatkan izin. Tapi tolong jangan ganggu aku lagi sampai kesulitanmu berubah. ”

Singkatnya, respons 401 Tidak Sah harus digunakan untuk otentikasi yang hilang atau buruk, dan respons Terlarang 403 harus digunakan setelahnya, ketika pengguna diautentikasi tetapi tidak berwenang untuk melakukan operasi yang diminta pada sumber daya yang diberikan.

Format gambar bagus lainnya tentang bagaimana kode status http harus digunakan.

Lihat RFC2616 :

401 Tidak Resmi:

Jika permintaan sudah menyertakan kredensial Otorisasi, maka respons 401 menunjukkan bahwa otorisasi telah ditolak untuk kredensial tersebut.

403 Dilarang:

Server mengerti permintaan itu, tetapi menolak untuk memenuhinya.

Memperbarui

Dari kasus penggunaan Anda, tampaknya pengguna tidak diautentikasi. Saya akan kembali 401.

Sunting: RFC2616 sudah usang, lihat RFC7231 dan RFC7235 .

Sesuatu yang tidak dijawab oleh jawaban lain adalah harus dipahami bahwa Otentikasi dan Otorisasi dalam konteks RFC 2616 merujuk HANYA pada protokol HTTP Authentication dari RFC 2617. Otentikasi dengan skema di luar RFC2617 tidak didukung dalam kode status HTTP dan tidak dianggap sebagai kode saat memutuskan apakah akan menggunakan 401 atau 403.

Singkat dan Terse

Tidak sah menunjukkan bahwa klien tidak dikonfirmasi dengan RFC2617 dan server memulai proses otentikasi. Forbidden menunjukkan bahwa klien diautentikasi RFC2617 dan tidak memiliki otorisasi atau bahwa server tidak mendukung RFC2617 untuk sumber daya yang diminta.

Berarti jika Anda memiliki proses masuk roll-Anda-sendiri dan tidak pernah menggunakan Otentikasi HTTP, 403 selalu merupakan respons yang tepat dan 401 tidak boleh digunakan.

Detail dan Mendalam

Dari RFC2616

10.4.2 401 Tidak Resmi

Permintaan membutuhkan otentikasi pengguna. Respons HARUS menyertakan bidang tajuk WWW-Otentikasi (bagian 14.47) yang berisi tantangan yang berlaku untuk sumber daya yang diminta. Klien MUNGKIN mengulangi permintaan dengan bidang tajuk Otorisasi yang sesuai (bagian 14.8).

dan

10.4.4 403 Terlarang Server memahami permintaan tersebut tetapi menolak untuk memenuhinya. Otorisasi tidak akan membantu dan permintaan TIDAK HARUS diulang.

Hal pertama yang perlu diingat adalah bahwa "Otentikasi" dan "Otorisasi" dalam konteks dokumen ini merujuk secara khusus ke protokol Autentikasi HTTP dari RFC 2617. Mereka tidak merujuk ke protokol otentikasi roll-your-sendiri yang mungkin Anda buat menggunakan halaman login, dll. Saya akan menggunakan "login" untuk merujuk ke otentikasi dan otorisasi dengan metode selain RFC2617

Jadi perbedaan sebenarnya bukanlah apa masalahnya atau bahkan jika ada solusinya. Perbedaannya adalah apa yang server harapkan untuk dilakukan klien selanjutnya.

401 menunjukkan bahwa sumber daya tidak dapat disediakan, tetapi server MEMINTA bahwa klien login melalui Otentikasi HTTP dan telah mengirim header balasan untuk memulai proses. Mungkin ada otorisasi yang akan mengizinkan akses ke sumber daya, mungkin tidak ada, tapi mari kita coba dan lihat apa yang terjadi.

403 menunjukkan bahwa sumber daya tidak dapat disediakan dan ada, untuk pengguna saat ini, tidak ada cara untuk menyelesaikan ini melalui RFC2617 dan tidak ada gunanya mencoba. Ini mungkin karena diketahui bahwa tingkat otentikasi tidak memadai (misalnya karena daftar hitam IP), tetapi mungkin karena pengguna sudah diautentikasi dan tidak memiliki wewenang. Model RFC2617 adalah satu-pengguna, satu-kredensial sehingga kasus di mana pengguna mungkin memiliki set kedua kredensial yang dapat diotorisasi dapat diabaikan. Itu tidak menyarankan atau menyiratkan bahwa semacam halaman login atau protokol otentikasi non-RFC2617 lain mungkin atau mungkin tidak membantu - yang berada di luar standar dan definisi RFC2616.

Sunting: RFC2616 sudah usang, lihat RFC7231 dan RFC7235 .

  + -----------------------
  | ADA SUMBER DAYA? (jika pribadi sering diperiksa SETELAH pemeriksaan auth)
  + -----------------------
    | |
 TIDAK | v YA
    v + -----------------------
   404 | APAKAH SUDAH MASUK ? (dikonfirmasi, alias memiliki sesi atau cookie JWT)
   atau + -----------------------
   401 | |
   403 TIDAK | | IYA
   3xx vv
              401 + -----------------------
       (404 tidak terungkap) | BISAKAH AKSES SUMBERDAYA? (izin, resmi, ...)
              atau + -----------------------
             redirect | |
             untuk login NO | | IYA
                               | |
                               ay
                               403 OK 200, redirect, ...
                      (atau 404: tidak ada pengungkapan)
                      (atau 404: sumber daya tidak ada jika pribadi)
                      (atau 3xx: pengalihan)

Cek biasanya dilakukan dalam urutan ini:

• 404 jika sumber daya bersifat publik dan tidak ada atau pengalihan 3xx
• JIKA TIDAK:
• 401 jika tidak masuk atau sesi kedaluwarsa
• 403 jika pengguna tidak memiliki izin untuk mengakses sumber daya (file, json, ...)
• 404 jika sumber daya tidak ada atau tidak mau mengungkapkan apa pun, atau pengalihan 3xx

TIDAK DIKENAL : Kode status (401) yang menunjukkan bahwa permintaan memerlukan otentikasi , biasanya ini berarti pengguna harus masuk (sesi). Pengguna / agen tidak dikenal oleh server. Dapat diulangi dengan kredensial lain. CATATAN: Ini membingungkan karena ini seharusnya dinamai 'tidak terauthentikasi' alih-alih 'tidak sah'. Ini juga dapat terjadi setelah masuk jika sesi berakhir. Kasus khusus: Dapat digunakan sebagai ganti 404 untuk menghindari mengungkapkan ada atau tidak adanya sumber daya (kredit @gingerCodeNinja)

DILARANG : Kode status (403) yang mengindikasikan server memahami permintaan tersebut tetapi menolak untuk memenuhinya. Pengguna / agen yang dikenal oleh server tetapi tidak memiliki kredensial yang memadai . Permintaan berulang tidak akan berfungsi, kecuali kredensial berubah, yang sangat tidak mungkin dalam rentang waktu singkat. Kasus khusus: Dapat digunakan sebagai ganti 404 untuk menghindari mengungkapkan ada atau tidak adanya sumber daya (kredit @gingerCodeNinja)

TIDAK DITEMUKAN : Kode status (404) yang menunjukkan bahwa sumber daya yang diminta tidak tersedia. Pengguna / agen diketahui tetapi server tidak akan mengungkapkan apa pun tentang sumber daya, apakah seolah-olah tidak ada. Mengulang tidak akan berhasil. Ini adalah penggunaan khusus 404 (github melakukannya misalnya).

Seperti yang disebutkan oleh @ChrisH ada beberapa opsi untuk pengalihan 3xx (301, 302, 303, 307 atau tidak mengarahkan sama sekali dan menggunakan 401):

• Perbedaan antara kode pengalihan HTTP
• Berapa lama browser melakukan cache HTTP 301s?
• Apa kode status HTTP yang benar saat mengarahkan ke halaman login?
• Apa perbedaan antara pengalihan 302 dan 307?

Menurut RFC 2616 (HTTP / 1.1) 403 dikirim ketika:

Server mengerti permintaan itu, tetapi menolak untuk memenuhinya. Otorisasi tidak akan membantu dan permintaan TIDAK HARUS diulang. Jika metode permintaan itu bukan KEPALA dan server ingin mengumumkan kepada publik mengapa permintaan itu belum dipenuhi, itu HARUS menggambarkan alasan penolakan di entitas. Jika server tidak ingin membuat informasi ini tersedia untuk klien, kode status 404 (Tidak Ditemukan) dapat digunakan sebagai gantinya

Dengan kata lain, jika klien BISA mendapatkan akses ke sumber daya dengan mengotentikasi, 401 harus dikirim.

Dengan asumsi otentikasi HTTP ( WWW-Otentikasi dan header Otorisasi ) sedang digunakan , jika otentikasi sebagai pengguna lain akan memberikan akses ke sumber daya yang diminta, maka 401 Tidak Sah harus dikembalikan.

403 Forbidden digunakan ketika akses ke sumber daya dilarang untuk semua orang atau terbatas pada jaringan tertentu atau hanya diizinkan melalui SSL, apa pun asalkan tidak ada hubungannya dengan otentikasi HTTP.

Jika otentikasi HTTP tidak digunakan dan layanan skema otentikasi berbasis cookie seperti norma saat ini, maka 403 atau 404 harus dikembalikan.

Mengenai 401, ini dari RFC 7235 (Protokol Transfer Hiperteks (HTTP / 1.1): Otentikasi):

3.1. 401 Tidak Resmi

Kode status 401 (Tidak Resmi) menunjukkan bahwa permintaan belum diterapkan karena tidak memiliki kredensial otentikasi yang valid untuk sumber daya target. Server asal HARUS mengirim bidang header WWW-Otentikasi (Bagian 4.4) yang mengandung setidaknya satu tantangan yang berlaku untuk sumber daya target. Jika permintaan menyertakan kredensial autentikasi, maka respons 401 menunjukkan bahwa otorisasi telah ditolak untuk kredensial tersebut. Klien MUNGKIN mengulangi permintaan dengan bidang header Otorisasi baru atau yang diganti (Bagian 4.1). Jika respons 401 berisi tantangan yang sama dengan respons sebelumnya, dan agen pengguna telah mencoba otentikasi setidaknya satu kali, maka agen pengguna HARUS menyajikan representasi terlampir kepada pengguna, karena biasanya berisi informasi diagnostik yang relevan.

Semantik 403 (dan 404) telah berubah seiring waktu. Ini dari tahun 1999 (RFC 2616):

10.4.4 403 Dilarang

Server mengerti permintaan itu, tetapi menolak untuk memenuhinya.
Otorisasi tidak akan membantu dan permintaan TIDAK HARUS diulang.
Jika metode permintaan itu bukan KEPALA dan server ingin mengumumkan kepada
publik mengapa permintaan itu belum dipenuhi, itu HARUS menggambarkan alasan penolakan di entitas. Jika server tidak ingin membuat informasi ini tersedia untuk klien, kode status 404
(Tidak Ditemukan) dapat digunakan sebagai gantinya.

Pada 2014 RFC 7231 (Protokol Transfer Hiperteks (HTTP / 1.1): Semantik dan Konten) mengubah arti 403:

6.5.3. 403 Dilarang

Kode status 403 (Terlarang) menunjukkan bahwa server memahami permintaan tersebut tetapi menolak untuk mengesahkannya. Server yang ingin mengumumkan kepada publik mengapa permintaan itu dilarang dapat menggambarkan alasan itu dalam payload respons (jika ada).

Jika kredensial otentikasi diberikan dalam permintaan,
server menganggapnya tidak cukup untuk memberikan akses. Klien
TIDAK HARUS mengulangi permintaan dengan
kredensial yang sama . Klien MUNGKIN mengulangi permintaan dengan kredensial baru atau berbeda. Namun, permintaan mungkin dilarang karena alasan yang
tidak terkait dengan kredensial.

Server asal yang ingin "menyembunyikan" keberadaan saat ini dari
sumber daya target terlarang MUNGKIN merespons dengan kode status
404 (Tidak Ditemukan).

Jadi, 403 (atau 404) sekarang mungkin berarti tentang apa pun. Memberikan kredensial baru mungkin membantu ... atau mungkin juga tidak.

Saya percaya alasan mengapa hal ini berubah adalah RFC 2616 diasumsikan otentikasi HTTP akan digunakan ketika dalam praktiknya aplikasi Web saat ini membangun skema otentikasi khusus menggunakan misalnya formulir dan cookie.

Ini adalah pertanyaan yang lebih tua, tetapi satu opsi yang tidak pernah benar-benar diajukan adalah mengembalikan 404. Dari perspektif keamanan, jawaban dengan suara terbanyak menderita dari potensi kerentanan kebocoran informasi . Katakan, misalnya, bahwa halaman web aman yang dimaksud adalah halaman admin sistem, atau mungkin lebih umum, adalah catatan dalam sistem yang tidak dapat diakses oleh pengguna. Idealnya Anda tidak ingin pengguna jahat tahu bahwa ada halaman / catatan di sana, apalagi mereka tidak memiliki akses. Ketika saya sedang membangun sesuatu seperti ini, saya akan mencoba untuk mencatat permintaan yang tidak diautentikasi / tidak sah dalam log internal, tetapi mengembalikan 404.

OWASP memiliki beberapa informasi lebih lanjut tentang bagaimana penyerang dapat menggunakan informasi jenis ini sebagai bagian dari serangan.

• 401 Tidak Resmi : Saya tidak tahu siapa Anda. Ini kesalahan otentikasi.
• 403 Forbidden : Saya tahu siapa Anda, tetapi Anda tidak memiliki izin untuk mengakses sumber ini. Ini adalah kesalahan otorisasi.

Pertanyaan ini diajukan beberapa waktu yang lalu, tetapi pemikiran orang-orang terus berjalan.

Bagian 6.5.3 dalam konsep ini (ditulis oleh Fielding dan Reschke) memberikan kode status 403 arti yang sedikit berbeda dengan yang didokumentasikan dalam RFC 2616 .

Ini mencerminkan apa yang terjadi dalam skema otentikasi & otorisasi yang digunakan oleh sejumlah server dan kerangka kerja populer.

Saya telah menekankan sedikit yang menurut saya paling menonjol.

6.5.3. 403 Dilarang

Kode status 403 (Terlarang) menunjukkan bahwa server memahami permintaan tersebut tetapi menolak untuk mengesahkannya. Server yang ingin mengumumkan kepada publik mengapa permintaan itu dilarang dapat menggambarkan alasan itu dalam payload respons (jika ada).

Jika kredensial otentikasi diberikan dalam permintaan, server menganggapnya tidak cukup untuk memberikan akses. Klien TIDAK HARUS mengulangi permintaan dengan kredensial yang sama. Klien MUNGKIN mengulangi permintaan dengan kredensial baru atau berbeda. Namun, permintaan mungkin dilarang karena alasan yang tidak terkait dengan kredensial.

Server asal yang ingin "menyembunyikan" keberadaan saat ini dari sumber daya target terlarang MUNGKIN merespons dengan kode status 404 (Tidak Ditemukan).

Apa pun konvensi yang Anda gunakan, yang penting adalah memberikan keseragaman di seluruh situs / API Anda.

TL; DR

• 401: Penolakan yang berkaitan dengan otentikasi
• 403: Penolakan yang tidak ada hubungannya dengan otentikasi

Contoh Praktis

Jika apache memerlukan otentikasi (via .htaccess), dan Anda menekan Cancel, itu akan merespons dengan a401 Authorization Required

Jika nginx menemukan file, tetapi tidak memiliki hak akses (pengguna / grup) untuk membaca / mengaksesnya, ia akan merespons403 Forbidden

RFC (2616 Bagian 10)

401 Tidak Resmi (10.4.2)

Artinya 1: Perlu diautentikasi

Permintaan membutuhkan otentikasi pengguna. ...

Artinya 2: Otentikasi tidak cukup

... Jika permintaan sudah menyertakan kredensial Otorisasi, maka respons 401 menunjukkan bahwa otorisasi telah ditolak untuk kredensial tersebut. ...

403 Forbidden (10.4.4)

Artinya: Tidak terkait dengan otentikasi

... Otorisasi tidak akan membantu ...

Keterangan lebih lanjut:

• Server mengerti permintaan itu, tetapi menolak untuk memenuhinya.

• HARUS menjelaskan alasan penolakan dalam entitas

• Kode status 404 (Tidak Ditemukan) dapat digunakan sebagai gantinya

  (Jika server ingin menyimpan informasi ini dari klien)

mereka tidak masuk atau tidak termasuk kelompok pengguna yang tepat

Anda telah menyatakan dua kasus berbeda; setiap kasus harus memiliki respons yang berbeda:

1. Jika mereka tidak masuk sama sekali Anda harus mengembalikan 401 Tidak Sah
2. Jika mereka masuk tetapi bukan milik kelompok pengguna yang tepat, Anda harus mengembalikan 403 Forbidden

Catatan tentang RFC berdasarkan komentar yang diterima untuk jawaban ini:

Jika pengguna tidak login mereka tidak diautentikasi, HTTP setara yang 401 dan menyesatkan disebut Tidak Diotorisasi dalam RFC. Seperti bagian 10.4.2 menyatakan untuk 401 Tidak Sah :

"Permintaan tersebut membutuhkan otentikasi pengguna ."

Jika Anda tidak diauthentikasi, 401 adalah respons yang benar. Namun jika Anda tidak sah, dalam arti semantik yang benar, 403 adalah respons yang benar.

Inilah artinya:

401 : Pengguna tidak (dengan benar) diautentikasi, sumber / halaman ini memerlukan otentikasi

403 : Pengguna diautentikasi, tetapi peran atau izinnya tidak memungkinkan untuk mengakses sumber daya yang diminta, misalnya pengguna bukan administrator dan halaman yang diminta untuk administrator

Ini lebih sederhana di kepala saya daripada di mana pun di sini, jadi:

401: Anda perlu autentikasi dasar HTTP untuk melihatnya.

403: Anda tidak dapat melihat ini, dan autentikasi dasar HTTP tidak akan membantu.

Jika pengguna hanya perlu login menggunakan formulir login HTML standar situs Anda, 401 tidak akan sesuai karena khusus untuk autentikasi dasar HTTP.

Saya tidak merekomendasikan menggunakan 403 untuk menolak akses ke hal-hal seperti /includes, karena sejauh menyangkut web, sumber daya itu tidak ada sama sekali dan karenanya harus 404.

Ini meninggalkan 403 sebagai "Anda harus masuk".

Dengan kata lain, 403 berarti "sumber daya ini membutuhkan beberapa bentuk auth selain HTTP basic auth".

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2

Saya pikir penting untuk mempertimbangkan bahwa, untuk browser, 401 memulai dialog otentikasi bagi pengguna untuk memasukkan kredensial baru, sedangkan 403 tidak. Peramban berpikir bahwa, jika 401 dikembalikan, maka pengguna harus mengautentikasi ulang. Jadi 401 adalah singkatan dari otentikasi tidak valid sementara 403 adalah singkatan dari kurangnya izin.

Berikut adalah beberapa kasus di bawah logika di mana kesalahan akan dikembalikan dari otentikasi atau otorisasi, dengan frasa penting yang dicetak tebal.

• Sumber daya membutuhkan otentikasi tetapi tidak ada kredensial yang ditentukan .

401 : Klien harus menentukan kredensial.

• Kredensial yang ditentukan dalam format yang tidak valid .

400 : Itu bukan 401 atau 403, karena kesalahan sintaks harus selalu menghasilkan 400.

• Kredensial yang ditentukan merujuk pengguna yang tidak ada .

401 : Klien harus menentukan kredensial yang valid.

• Kredensial yang ditentukan tidak valid tetapi tentukan pengguna yang valid (atau jangan tentukan pengguna jika pengguna yang ditentukan tidak diperlukan).

401 : Sekali lagi, klien harus menentukan kredensial yang valid.

• Kredensial yang ditentukan telah kedaluwarsa .

401 : Ini secara praktis sama dengan memiliki kredensial tidak valid secara umum, sehingga klien harus menentukan kredensial yang valid.

• Kredensial yang ditentukan benar-benar valid tetapi tidak mencukupi sumber daya tertentu , meskipun mungkin kredensial dengan lebih banyak izin bisa.

403 : Menentukan kredensial yang valid tidak akan memberikan akses ke sumber daya, karena kredensial saat ini sudah valid tetapi hanya tidak memiliki izin.

• Sumber daya tertentu tidak dapat diakses terlepas dari kredensial.

403 : Ini terlepas dari kredensial, jadi menentukan kredensial yang valid tidak dapat membantu.

• Kredensial yang ditetapkan benar-benar valid tetapi tertentu klien yang diblokir dari menggunakan mereka.

403 : Jika klien diblokir, menentukan kredensial baru tidak akan melakukan apa-apa.

Dalam Bahasa Inggris:

401

Anda berpotensi diizinkan mengakses tetapi karena suatu alasan permintaan ini Anda ditolak. Seperti kata sandi yang buruk? Coba lagi, dengan permintaan yang benar, Anda akan mendapatkan respons yang sukses.

403

Anda tidak pernah diizinkan. Nama Anda tidak ada dalam daftar, Anda tidak akan pernah masuk, pergi, jangan mengirim permintaan coba ulang, itu akan selalu ditolak. Pergi.

Mengingat RFC terbaru tentang masalah ini ( 7231 dan 7235 ) kasus penggunaan tampak cukup jelas (cetak miring ditambahkan):

• 401 adalah untuk tidak diautentikasi ("tidak memiliki otentikasi yang valid"); yaitu 'Saya tidak tahu siapa Anda, atau saya tidak percaya Anda adalah siapa yang Anda katakan.'

401 Tidak Resmi

Kode status 401 (Tidak Resmi) menunjukkan bahwa permintaan belum diterapkan karena tidak memiliki kredensial otentikasi yang valid untuk sumber daya target. Server yang menghasilkan respons 401 HARUS mengirim bidang header WWW-Otentikasi (Bagian 4.1) yang berisi setidaknya satu tantangan yang berlaku untuk sumber daya target.

Jika permintaan menyertakan kredensial autentikasi, maka respons 401 menunjukkan bahwa otorisasi telah ditolak untuk kredensial tersebut. Agen pengguna DAPAT mengulangi permintaan dengan bidang tajuk Otorisasi baru atau yang diganti (Bagian 4.2). Jika respons 401 berisi tantangan yang sama dengan respons sebelumnya, dan agen pengguna telah mencoba otentikasi setidaknya satu kali, maka agen pengguna HARUS menyajikan representasi terlampir kepada pengguna, karena biasanya berisi informasi diagnostik yang relevan.

• 403 adalah untuk yang tidak berwenang ("menolak untuk mengotorisasi"); yaitu 'Saya tahu siapa Anda, tetapi Anda tidak memiliki izin untuk mengakses sumber ini.'

403 Dilarang

Kode status 403 (Terlarang) menunjukkan bahwa server memahami permintaan tersebut tetapi menolak untuk mengesahkannya . Server yang ingin mengumumkan kepada publik mengapa permintaan itu dilarang dapat menggambarkan alasan itu dalam payload respons (jika ada).

Jika kredensial otentikasi diberikan dalam permintaan, server menganggapnya tidak cukup untuk memberikan akses. Klien TIDAK HARUS mengulangi permintaan dengan kredensial yang sama. Klien MUNGKIN mengulangi permintaan dengan kredensial baru atau berbeda. Namun, permintaan mungkin dilarang karena alasan yang tidak terkait dengan kredensial.

Server asal yang ingin "menyembunyikan" keberadaan saat ini dari sumber daya target terlarang MUNGKIN merespons dengan kode status 404 (Tidak Ditemukan).

Dalam kasus 401 vs 403, ini telah dijawab berkali-kali. Ini pada dasarnya adalah debat 'Lingkungan permintaan HTTP', bukan debat 'aplikasi'.

Tampaknya ada pertanyaan tentang masalah roll-your-own-login Anda (aplikasi).

Dalam hal ini, tidak login saja tidak cukup untuk mengirim 401 atau 403, kecuali jika Anda menggunakan HTTP Auth vs halaman login (tidak terikat dengan pengaturan HTTP Auth). Sepertinya Anda mungkin mencari "201 Created", dengan layar roll-your-own-login Anda (bukan sumber daya yang diminta) untuk akses tingkat aplikasi ke file. Ini mengatakan:

"Aku mendengarmu, ada di sini, tapi coba ini sebagai gantinya (kamu tidak diizinkan melihatnya)"