Maksud Unauthenticated dan bezanya dengan Unauthorized

Maksud Unauthenticated: server tidak tahu siapa anda

Maksud "Unauthenticated" ialah server tidak tahu siapa anda. Permintaan anda sampai tanpa bukti identiti yang sah. Biasanya ada empat sebab: anda belum log masuk, sesi anda sudah tamat, token tidak dihantar langsung, atau token itu sudah luput.

"Unauthorized" atau "Forbidden" ialah masalah lain. Dalam kes itu server sudah kenal anda, tetapi masih menolak permintaan anda.

Dalam bahasa Melayu, soalan pertama ialah pengesahan atau autentikasi (authentication): siapa anda? Soalan kedua ialah kebenaran atau kawalan akses (authorization): apa yang anda boleh buat? Mesej ralat di server hampir selalu kekal dalam bahasa Inggeris. Oleh itu panduan ini menulis istilah Inggeris dalam kurungan, supaya anda boleh padankan dengan apa yang tertera di skrin.

Ada satu perkara tentang istilah yang perlu diingat. Dalam bahasa Melayu, perkataan "kebenaran" juga digunakan untuk file permission (kebenaran fail). Kebenaran fail tiada kaitan dengan log masuk. Untuk mengelakkan kekeliruan, guna "kawalan akses" untuk authorization dan "kebenaran fail" untuk mod fail.

Apa yang perlu dicuba dahulu bila nampak "Unauthenticated"

1. Log keluar, kemudian log masuk semula. Sesi baharu akan menggantikan sesi yang sudah tamat.
2. Jika anda memanggil API, pastikan header Authorization memang dihantar dan token di dalamnya belum luput.
3. Lihat kod status sebenar dengan curl -i, bukan mesej di skrin sahaja.
4. Semak jam server. Jika jam lari, token yang baru dikeluarkan boleh kelihatan seperti sudah luput.

Mulakan dengan langkah 3. Jalankan arahan ini pada URL anda sendiri:

curl -i https://example.com/api/user

Pilihan -i mencetak header respons bersama badannya. Baris pertama ialah kod status, contohnya HTTP/1.1 401 Unauthorized atau HTTP/2 401. Kod 401 bermakna pengesahan gagal. Kod 403 bermakna server faham permintaan anda tetapi menolaknya. Jika anda nampak 401, cari header WWW-Authenticate dalam output. Header itu memberitahu cara pengesahan yang diminta oleh server.

Dari mana datangnya perkataan "Unauthenticated."?

Perkataan ini bukan nama kod status HTTP. Ia teks yang ditulis oleh aplikasi. Contoh yang paling kerap ialah Laravel.

Dalam kod sumber Laravel cabang 12.x, kelas AuthenticationException menggunakan mesej lalai 'Unauthenticated.', lengkap dengan noktah di hujungnya. Pengendali ralat Laravel kemudian memilih satu daripada dua jalan. Jika permintaan itu mengharapkan JSON, ia membalas JSON dengan status 401. Jika tidak, ia melencongkan (redirect) pengguna ke laluan bernama login. Berdasarkan dua baris kod itu, permintaan API tanpa sesi atau token yang sah akan menerima status 401 dengan badan {"message":"Unauthenticated."}.

Anda boleh melihat perbezaannya sendiri:

curl -i -H "Accept: application/json" https://example.com/api/user
curl -i https://example.com/dashboard

Arahan pertama meminta JSON, jadi anda patut nampak 401 dan mesej Unauthenticated.. Arahan kedua bertindak seperti pelayar biasa, jadi anda patut nampak respons lencongan dengan header Location yang menghala ke halaman log masuk. Puncanya sama: server tidak kenal anda.

Kenapa HTTP 401 bernama "Unauthorized" sedangkan maksudnya belum disahkan?

Nama ini mengelirukan, dan ia nama lama. Lihat standard HTTP semasa, iaitu RFC 9110. Seksyen 15.5.2 mentakrifkan 401 begini: permintaan tidak dilaksanakan kerana ia "lacks valid authentication credentials for the target resource". Maksudnya, permintaan itu tidak membawa bukti identiti yang sah. Itu masalah pengesahan, walaupun frasa sebabnya (reason phrase) berbunyi "Unauthorized".

Seksyen yang sama juga menetapkan satu kewajipan. Server yang menghantar 401 "MUST send a WWW-Authenticate header field", dan header itu mesti mengandungi sekurang-kurangnya satu cabaran (challenge) untuk sumber tersebut. Jika permintaan anda sudah membawa bukti identiti, 401 bermakna bukti itu ditolak. Klien boleh cuba semula dengan header Authorization yang baharu.

Seksyen 15.5.4 mentakrifkan 403 (Forbidden): server "understood the request but refuses to fulfill it". Jika bukti identiti dihantar, server menganggapnya tidak cukup untuk memberi akses. Klien tidak patut mengulang permintaan yang sama secara automatik dengan bukti yang sama. RFC itu juga menyatakan bahawa permintaan "might be forbidden for reasons unrelated to the credentials". Server yang mahu menyembunyikan kewujudan sesuatu sumber boleh menjawab 404 sebagai ganti.

Jadi peraturan mudahnya begini. 401 bertanya "siapa anda?". 403 berkata "saya faham, tetapi tidak".

SSH menolak kunci anda: itu pengesahan

Contoh yang paling dekat ialah server anda sendiri. Apabila SSH menolak kunci anda, anda belum masuk ke server langsung. Itu kegagalan pengesahan.

Klien OpenSSH menamatkan sambungan dengan mesej berbentuk pengguna@hos: Permission denied (publickey).. Senarai dalam kurungan itu datang daripada server, jadi isinya bergantung pada konfigurasi server anda. Perhatikan perkataan "Permission" di situ. Bunyinya seperti masalah kawalan akses, tetapi sebenarnya server belum menerima bukti identiti anda.

Jalankan arahan ini dari komputer anda, dengan nama pengguna dan alamat server anda sendiri:

ssh -v ali@203.0.113.10

Output -v menunjukkan kunci yang dicuba oleh klien dan cara pengesahan yang diterima oleh server. Kemudian baca log di sisi server melalui konsol pembekal VPS anda. Di Ubuntu, unit systemd untuk SSH bernama ssh:

sudo journalctl -u ssh -n 50
sudo sshd -T | grep -Ei 'pubkeyauthentication|passwordauthentication|authorizedkeysfile'

Arahan sshd -T mencetak nilai yang benar-benar digunakan selepas semua fail konfigurasi dibaca. Nilai lalai OpenSSH huluan ialah PubkeyAuthentication yes, PasswordAuthentication yes dan AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2. Fail konfigurasi pakej Ubuntu boleh mengubah nilai ini, jadi percayalah output sshd -T, bukan ingatan anda.

Jika log mengandungi bad owner or modes, sshd menolak kunci kerana pemilik atau mod ~/.ssh salah. Betulkan sebagai pengguna itu:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Untuk punca lain, ikut panduan membaiki ralat SSH Permission denied (publickey). Jika anda keliru antara 700 dan 600, penerangan mod chmod dalam bentuk nombor dan simbol menghuraikannya bit demi bit.

Boleh log masuk tetapi tidak boleh sudo: itu kawalan akses

Katakan pengguna ali sudah berjaya masuk melalui SSH. Server kenal dia. Kemudian dia menaip sudo apt update dan ditolak. Itu masalah kawalan akses.

Perintah sudo sebenarnya bertanya dua soalan, satu demi satu. Pertama, ia meminta kata laluan anda. Itu pengesahan. Kedua, ia menyemak fail sudoers untuk melihat sama ada anda dibenarkan menjalankan perintah itu. Itu kawalan akses. Mesej yang anda nampak memberitahu soalan mana yang gagal.

Pada sudo asal (projek sudo.ws), kata laluan yang salah memaparkan mesej lalai Sorry, try again.. Secara lalai anda mendapat 3 cubaan. Pengguna yang tiada dalam sudoers pula mendapat mesej yang berakhir dengan is not in the sudoers file.. Mesej pertama ialah kegagalan pengesahan. Mesej kedua ialah kegagalan kawalan akses.

Ubuntu 26.04 LTS dikeluarkan pada 23 April 2026, dan ia mengubah perkara ini. Dalam versi ini sudo-rs menjadi pembekal sudo lalai, dan sudo asal dinamakan semula sudo.ws. Prompt kata laluannya juga berbeza. Menurut dokumentasi Ubuntu Server, sudo.ws memaparkan [sudo] password for <USERNAME>. sudo-rs pula memaparkan [sudo: authenticate] <METHOD>: dan mencetak apa sahaja prompt yang diberi oleh PAM, seperti Password:. Mesej penolakannya juga tidak sama dengan sudo.ws. Jadi jika anda menggunakan 26.04, jangan cari rentetan sudo.ws yang tepat di Google. Semak puncanya terus:

groups

Di Ubuntu, ahli kumpulan sudo dibenarkan menggunakan sudo. Jika sudo tiada dalam senarai, pentadbir perlu menambah pengguna itu ke dalam kumpulan tersebut. Selepas itu pengguna perlu log keluar dan log masuk semula sebelum keahlian baharu berkuat kuasa:

sudo usermod -aG sudo ali

Sebelum memberi sudo penuh kepada sesiapa, baca cara menyediakan pengguna dengan hak paling minimum di VPS. Selalunya pengguna itu hanya perlukan satu atau dua perintah, bukan semuanya.

nginx: auth_basic memberi 401, deny memberi 403

nginx memberi contoh yang paling jelas, kerana dua modul yang berbeza menghasilkan dua kod yang berbeza. Pasang alat htpasswd, cipta seorang pengguna, kemudian tambah dua blok location di dalam blok server anda:

sudo apt install -y apache2-utils
sudo htpasswd -c /etc/nginx/.htpasswd ali

location /admin/ {
    auth_basic "Kawasan admin";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

location /dalaman/ {
    allow 203.0.113.0/24;
    deny all;
}

sudo nginx -t && sudo systemctl reload nginx
curl -i https://example.com/admin/
curl -i https://example.com/dalaman/

Permintaan ke /admin/ tanpa nama pengguna patut mendapat 401. Dalam kod sumber nginx, modul auth_basic memulangkan NGX_HTTP_UNAUTHORIZED. Ia juga membina header WWW-Authenticate: Basic realm="..." daripada teks yang anda beri kepada auth_basic. Log ralat mencatat no user/password was provided for basic authentication. Cuba semula dengan curl -i -u ali https://example.com/admin/ dan masukkan kata laluan. Status itu patut bertukar kepada 200.

Permintaan ke /dalaman/ dari alamat di luar julat yang dibenarkan patut mendapat 403. Modul akses nginx memulangkan NGX_HTTP_FORBIDDEN apabila peraturan deny sepadan. Peraturan disemak mengikut urutan sehingga padanan pertama ditemui. Dengan tetapan lalai satisfy all, log ralat mencatat access forbidden by rule. Nama pengguna dan kata laluan tidak membantu di sini, kerana nginx tidak pernah bertanya siapa anda. Ia hanya melihat alamat IP anda.

Jika satu location menggunakan auth_basic dan juga allow/deny, arahan satisfy menentukan hasilnya. Dengan satisfy all (nilai lalai), kedua-dua semakan mesti lulus. Dengan satisfy any, cukup jika satu semakan lulus.

403 yang tiada kaitan dengan log masuk: kebenaran fail

Inilah punca 403 yang paling kerap mengelirukan orang. Anda tidak memasang sebarang pengesahan, tetapi nginx masih memulangkan 403. Biasanya puncanya ialah kebenaran fail (file permission), bukan kawalan akses.

Dalam kod sumber nginx, modul fail statik cuba membuka fail. Jika sistem operasi menjawab EACCES (permission denied), nginx menukarnya kepada 403 dan mencatatnya pada tahap error. Modul indeks melakukan perkara yang sama semasa mencari fail indeks. Maksudnya, proses nginx tidak dapat membaca fail itu, atau tidak dapat melalui salah satu direktori di atasnya.

Baca log ralat anda sendiri dan salin mesej sebenarnya. Kemudian semak setiap direktori dalam laluan itu:

sudo tail -n 20 /var/log/nginx/error.log
grep -E '^\s*user' /etc/nginx/nginx.conf
namei -l /srv/laman/index.html

Arahan grep menunjukkan pengguna yang menjalankan proses pekerja nginx. Arahan namei -l menyenaraikan pemilik dan mod bagi setiap direktori, dari / hingga ke fail itu. Pengguna nginx mesti mempunyai bit x pada setiap direktori dan bit r pada fail itu. Satu direktori yang tertutup sudah cukup untuk menghasilkan 403 ini.

SSO di depan aplikasi: oauth2-proxy dan authentik mengesahkan, aplikasi memberi kebenaran

Ramai orang meletakkan lapisan SSO (single sign-on) di depan aplikasi yang mereka hos sendiri. Anda perlu tahu soalan mana yang dijawab oleh lapisan itu.

Modul auth_request nginx menghantar subpermintaan ke perkhidmatan pengesahan sebelum melepaskan setiap permintaan. Jika subpermintaan itu memulangkan kod 2xx, akses dibenarkan. Jika ia memulangkan 401 atau 403, klien menerima kod yang sama. Kod lain dianggap ralat.

oauth2-proxy menggunakan mekanisme ini. Titik akhir /oauth2/auth miliknya hanya memulangkan dua jawapan: 202 Accepted atau 401 Unauthorized. Jadi oauth2-proxy hanya menjawab satu soalan: sudahkah pengguna ini log masuk? Ia tidak tahu sama ada pengguna itu pentadbir atau hanya pembaca dalam aplikasi anda. Soalan itu dijawab oleh peranan (roles) di dalam aplikasi. Persediaan penuhnya ada dalam panduan melindungi aplikasi dengan oauth2-proxy.

authentik berfungsi dengan cara yang serupa. Penyedia proksinya melindungi aplikasi yang tidak menyokong log masuk melalui OIDC, SAML atau LDAP. Dalam mod forward auth, reverse proxy bertanya kepada outpost authentik sebelum melepaskan permintaan. Dokumentasi authentik sendiri menyatakan bahawa forward auth peringkat domain tidak dapat menguatkuasakan peraturan kawalan akses yang berbeza bagi setiap aplikasi. Jika setiap aplikasi perlukan peraturan sendiri, sediakan peraturan itu bagi setiap aplikasi. Panduan authentik sebagai SSO yang dihos sendiri menunjukkan caranya.

Kunci API tidak sah lawan kunci sah tanpa kebenaran

API mengikut corak yang sama. Claude API dari Anthropic memberi contoh yang jelas, kerana dokumentasinya memisahkan dua kes ini dengan nama yang berbeza.

Status 401 dengan jenis authentication_error bermakna ada masalah pada kunci API itu sendiri. Dokumentasi memberi contoh kunci yang rosak formatnya, sudah dibatalkan atau sudah luput. Status 403 dengan jenis permission_error bermakna kunci itu sah, tetapi tiada kebenaran untuk sumber yang diminta. Dokumentasi menyuruh anda menyemak akses organisasi dan tetapan workspace dalam Claude Console.

Ralat sentiasa dihantar dalam bentuk JSON. Ia mengandungi objek error dengan medan type dan message, serta medan request_id untuk penjejakan. Jangan teka teks mesejnya. Salin badan sebenar daripada respons anda sendiri, dan simpan request_id jika anda perlu menghubungi sokongan.

Pengajaran ini terpakai untuk semua API. Untuk 401, betulkan kunci: salin semula, atau keluarkan kunci baharu. Untuk 403, kunci baharu dengan hak yang sama tidak akan membantu. Anda perlu menukar hak itu. Butiran tentang header Authorization: Bearer dan x-api-key ada dalam penerangan pengesahan Claude API.

Senarai semak: kenapa "Unauthenticated" tiba-tiba muncul di server sendiri

Semalam semuanya berfungsi. Hari ini aplikasi anda memaparkan "Unauthenticated". Semak punca biasa ini mengikut urutan.

• Token atau sesi sudah luput. Setiap sistem ada tempohnya sendiri. Contohnya, oauth2-proxy menetapkan cookie_expire kepada 168h0m0s secara lalai, iaitu tujuh hari. Jika masalah muncul seminggu selepas log masuk, mulakan di sini.
• Reverse proxy tidak menghantar header Authorization atau kuki. Secara lalai nginx menghantar header permintaan ke belakang (proxy_pass_request_headers on), jadi proxy_pass biasa jarang menjadi puncanya. Perangkap sebenar ialah pewarisan. Arahan proxy_set_header hanya diwarisi dari tahap atas jika tiada proxy_set_header langsung pada tahap semasa. Jadi satu proxy_set_header baharu di dalam location boleh menghilangkan semua yang anda tetapkan di dalam server. Selain itu, nginx mengabaikan header tersuai yang namanya mengandungi garis bawah, seperti X_Api_Key, secara lalai. Untuk proksi lain dan CDN, semak dokumentasi masing-masing.
• Kuki Secure dihantar melalui HTTP biasa. Pelayar hanya menghantar kuki bertanda Secure melalui https: (kecuali di localhost), dan laman http: tidak boleh menetapkannya. oauth2-proxy menetapkan cookie_secure kepada true secara lalai. Jadi di belakang HTTP biasa, kuki log masuk tidak pernah disimpan, dan setiap permintaan tiba tanpa kuki. Hidangkan laman itu melalui HTTPS. Panduan Certbot dengan nginx di Ubuntu 24.04 menunjukkan caranya.
• Jam server lari. RFC 7519 menyatakan bahawa JWT tidak boleh diterima pada atau selepas masa exp. Pelaksana boleh memberi sedikit kelonggaran, biasanya tidak lebih daripada beberapa minit, tetapi kelonggaran itu tidak wajib. TOTP (RFC 6238) menggunakan langkah masa lalai 30 saat, dan setiap aplikasi memilih tetingkap toleransinya sendiri. Jika jam lari beberapa minit, kedua-duanya boleh gagal.

Untuk punca proksi, bandingkan permintaan terus ke aplikasi dengan permintaan melalui proksi. Jalankan kedua-duanya di server itu, dengan port aplikasi anda sendiri:

curl -i -H "Authorization: Bearer $TOKEN" http://127.0.0.1:8000/api/user
curl -i -H "Authorization: Bearer $TOKEN" https://example.com/api/user

Jika yang pertama berjaya tetapi yang kedua mendapat 401, header itu hilang di dalam proksi. Untuk punca jam, jalankan:

timedatectl

Baris System clock synchronized: yes bermakna jam anda disegerakkan. Jika nilainya no, ikut panduan membaiki jam VPS yang lari dan penyegerakan masa sebelum anda menyiasat token.

FAQ

Apakah maksud "Unauthenticated" dalam aplikasi atau API?

Ia bermaksud server tidak tahu siapa anda. Permintaan anda tiba tanpa bukti identiti yang sah. Mungkin anda belum log masuk, sesi sudah tamat, token tidak dihantar, atau token sudah luput. Log masuk semula, kemudian semak header Authorization dengan curl -i. Dalam Laravel, mesej Unauthenticated. datang bersama status HTTP 401.

Apakah beza HTTP 401 dan 403?

401 bermakna pengesahan (authentication) gagal: permintaan tidak membawa bukti identiti yang sah, dan RFC 9110 mewajibkan server menghantar header WWW-Authenticate bersamanya. 403 bermakna server faham permintaan itu tetapi enggan melaksanakannya. Biasanya ia masalah kawalan akses (authorization). Namun RFC 9110 juga menyatakan bahawa permintaan boleh ditolak atas sebab yang tiada kaitan dengan bukti identiti.

Kenapa nginx memberi 403 sedangkan saya tidak memasang sebarang log masuk?

Biasanya puncanya ialah kebenaran fail. Jika proses nginx tidak dapat membuka fail kerana sistem operasi menjawab EACCES, nginx memulangkan 403. Baca /var/log/nginx/error.log, kemudian jalankan namei -l pada laluan fail itu. Pengguna nginx perlukan bit x pada setiap direktori dan bit r pada fail itu.

Kenapa SSH berkata "Permission denied" sedangkan masalahnya kunci saya?

Mesej Permission denied (publickey). ialah kegagalan pengesahan, walaupun perkataan "Permission" berbunyi seperti kawalan akses. Server belum menerima mana-mana kunci yang anda tawarkan. Jalankan ssh -v untuk melihat kunci yang dicuba, dan baca sudo journalctl -u ssh di server. Mesej bad owner or modes bermakna mod ~/.ssh atau authorized_keys salah.

Kenapa "Unauthenticated" muncul selepas saya menambah reverse proxy?

Header Authorization atau kuki tidak sampai ke aplikasi. Bandingkan curl -i terus ke port aplikasi dengan curl -i melalui proksi. Dalam nginx, semak sama ada proxy_set_header di dalam location telah memutuskan pewarisan dari server. Jika log masuk menggunakan kuki Secure, pastikan laman itu dihidangkan melalui HTTPS.