401 Unauthorized Artinya Apa? Penyebab dan Cara Mengatasinya

Apa Itu Error 401 Unauthorized?

Error 401 Unauthorized berarti server meminta Anda membuktikan siapa Anda, dan permintaan Anda tidak melakukannya, atau kredensial yang dibawanya ditolak. Tanpa password, password salah, token kedaluwarsa, atau API key yang hilang: semuanya berakhir sama.

Standar HTTP mendefinisikannya sebagai permintaan yang "tidak memiliki kredensial autentikasi yang valid untuk resource target", dan server yang mengirim 401 WAJIB menyertakan header WWW-Authenticate yang menyebutkan skema login yang diterimanya (RFC 9110 §15.5.2).

Sederhananya, server bertanya "siapa Anda?" sebelum mengizinkan Anda masuk.

Tampilan Error 401

Halaman yang Anda lihat bergantung pada server dan aplikasinya:

• 401 Unauthorized — baris status standar, sekaligus kata-kata yang dipakai sebagian besar aplikasi
• 401 Authorization Required — judul halaman 401 bawaan nginx, dengan tulisan "nginx" (biasanya beserta versinya) di bawahnya (kode sumber nginx); server Apache 2.2 lama memakai kata-kata yang sama
• Unauthorized · This server could not verify that you are authorized to access the document requested — halaman bawaan Apache
• 401 - Unauthorized: Access is denied due to invalid credentials — IIS; halaman detailnya (hanya tampil di server itu sendiri) dan log IIS menyebut alasannya sebagai 401.1, 401.2, atau 401.3: login gagal, konfigurasi server, atau izin file
• Kotak login di browser — saat server meminta autentikasi HTTP Basic atau Digest, atau (di IIS dan intranet perusahaan) NTLM atau Negotiate
• Halaman ini tidak berfungsi · HTTP ERROR 401 — Chrome berbahasa Indonesia (dalam bahasa Inggris: "This page isn't working"), saat respons 401 tidak membawa halamannya sendiri; di bawahnya tertulis "Jika masalah berlanjut, hubungi pemilik situs."
• JSON dari API, misalnya {"error":{"message":"Missing Authentication header","code":401}}

Browser menampilkan kotak login hanya untuk skema login tersebut. API berbasis token ("Bearer") tidak pernah memunculkannya; 401-nya kembali sebagai JSON untuk ditangani aplikasi. Situs web dengan formulir login biasanya mengarahkan pengunjung yang belum login ke halaman login dengan redirect 302, bukan dengan 401.

"401 Authorization Required" di nginx

Judul itu berasal dari halaman 401 bawaan nginx. Anda mendapatkannya ketika sebuah location dilindungi dengan auth_basic dan permintaan tidak membawa username dan password, atau membawa yang salah; membatalkan kotak login browser juga memunculkan halaman ini.

Sebagai pengunjung, muat ulang halaman dan masukkan username dan password yang diberikan pemilik situs. Keduanya terpisah dari akun apa pun di situs itu: autentikasi Basic memeriksa file password di server.

Sebagai pemilik situs, beginilah proteksi itu dipasang, dan cara membiarkan satu path tetap publik:

# Create the password file (htpasswd comes with apache2-utils or httpd-tools)
#   sudo htpasswd -c /etc/nginx/.htpasswd alice   # -c creates the file: leave it out when adding users

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

# Inside a protected server block, open one path to everyone
location /public/ {
    auth_basic off;
}

# Test, then reload
#   curl -I -u alice:PASSWORD https://example.com/admin/
#   sudo nginx -t && sudo systemctl reload nginx

Masih 401 padahal password-nya benar? Pastikan user itu ada di file (htpasswd -c menimpa file sehingga user sebelumnya ikut terhapus), dan bahwa aplikasi di belakang nginx tidak juga membutuhkan header Authorization: login Basic nginx dan Bearer token aplikasi sama-sama memakainya, sehingga aplikasi menerima kredensial nginx lalu menolaknya.

401 vs 403: Apa Perbedaannya?

Kode 401 dan 403 sering tertukar. Versi singkatnya: 401 berarti "Saya tidak tahu siapa Anda", sedangkan 403 berarti "Saya tidak akan mengizinkan Anda masuk", entah identitas Anda masalahnya atau bukan.

Aturan praktisnya: jika memberikan username dan password (atau API key) yang benar dapat memperbaikinya, server seharusnya mengembalikan 401. Jika pengguna sudah terautentikasi tetapi memang tidak punya akses ke resource itu, server seharusnya mengembalikan 403 Forbidden.

Penyebab Umum Error 401

Penyebabnya, dari sisi pengunjung sampai sisi server:

• Username atau password salah — penyebab paling dasar, terutama setelah reset password
• Token autentikasi kedaluwarsa — token JWT, token akses OAuth, dan cookie sesi semuanya punya waktu kedaluwarsa
• Header Authorization tidak ada — permintaan sama sekali tidak menyertakan kredensial
• API key tidak valid — key telah dicabut, dirotasi, atau salah disalin
• Skema auth salah — server mengharapkan Bearer token tetapi menerima Basic auth, atau sebaliknya
• Selisih jam (clock skew) — server yang memeriksa JWT dan server yang menerbitkannya (atau mesin Anda, jika Anda yang menandatangani JWT) tidak sepakat soal waktu; banyak library tidak memberi toleransi sama sekali
• CORS preflight — pemeriksaan OPTIONS dari browser tidak pernah membawa kredensial, sehingga server yang menuntut kredensial menjawab 401 dan permintaan sebenarnya tidak pernah terkirim
• Sesi usang — browser mengirim cookie sesi yang sudah diakhiri server
• Sesuatu di tengah jalan membuang header — Apache menyembunyikan Authorization dari PHP-FPM dan skrip CGI kecuali diatur lain, CloudFront secara default menghapusnya dari permintaan GET dan HEAD, dan Basic auth nginx di depan aplikasi mengambil alih header itu
• Kredensial dikunci atau dicabut — terlalu banyak percobaan gagal bisa mengunci akun (sebagian API menjawabnya dengan 429 Too Many Requests)

Cara Mengatasi 401 sebagai Pengunjung

Jika Anda menemui error 401 di situs web yang ingin Anda buka, masalahnya hampir selalu berkaitan dengan kredensial login Anda. Ikuti langkah-langkah berikut secara berurutan.

1. Periksa Kredensial Login Anda

Penyebab paling umum error 401 adalah kredensial yang salah. Jika situs menampilkan popup atau formulir login, periksa kembali username dan password Anda.

Kesalahan umum: Caps Lock aktif, Anda memakai password lama (terutama setelah reset baru-baru ini), atau Anda login ke akun yang salah. Jika Anda memakai password manager, biarkan fitur isi otomatisnya mengisi kredensial agar tidak salah ketik.

2. Hapus Cache dan Cookie Browser

Browser Anda mungkin mengirim cookie sesi yang sudah kedaluwarsa. Menghapus cookie situs itu membuat situs meminta login baru.

Di Chrome berbahasa Indonesia: tekan Ctrl+Shift+Delete untuk membuka "Hapus data penjelajahan", ubah "Rentang waktu" menjadi "Semua" (bawaannya "Sejam terakhir"), centang "Cookie dan data situs lainnya" serta "Gambar dan file dalam cache", lalu pilih "Hapus data". Cara ini membuat Anda logout dari semua situs. Untuk satu situs saja: klik ikon di kiri alamat ("Lihat informasi situs") → "Setelan situs" → "Hapus data". Langkah untuk browser lain (label versi bahasa Inggris):

Chrome, Edge, Firefox: Ctrl+Shift+Delete (Cmd+Shift+Delete on a Mac)
  → Time range: All time → Cookies and site data + Cached files → Delete / Clear
  (this signs you out of every site; the per-site option below doesn't)
Safari: Settings → Privacy → Manage Website Data → the site → Remove
One site in Chrome: the icon left of the address → Site settings → Delete data

Setelah menghapus, tutup browser sepenuhnya (bukan hanya tab-nya), buka lagi, lalu buka halaman itu kembali. Anda akan melihat permintaan login yang baru.

3. Coba Mode Samaran atau Mode Pribadi

Buka URL di jendela Samaran (Incognito) Chrome, "Jendela Mode Pribadi Baru" di Firefox, atau Penelusuran Pribadi di Safari. Cara ini melewati semua cookie tersimpan, ekstensi, dan kredensial yang tersimpan.

Jika halaman berfungsi di mode Samaran tetapi tidak di jendela biasa, masalahnya adalah cookie tersimpan atau ekstensi browser yang mengganggu autentikasi. Nonaktifkan ekstensi satu per satu untuk menemukan penyebabnya.

4. Verifikasi URL

Pastikan Anda membuka URL yang benar. Sebagian server mengembalikan 401 untuk path yang memerlukan autentikasi, meskipun path-nya sendiri salah. Bisa jadi Anda sedang mencoba membuka area terbatas yang memang bukan untuk Anda.

Periksa apakah ada versi publik halaman itu di URL lain. Misalnya, example.com/admin/ mungkin mengembalikan 401 sementara example.com/ bisa diakses publik.

Tidak yakin situsnya berfungsi sama sekali? Cek Website Down membuka situs itu dari 11 lokasi, sehingga Anda bisa membedakan masalah login dari situs yang sedang down.

Cara Mengatasi 401 sebagai Developer

Bagi developer yang bekerja dengan API, error 401 biasanya berkaitan dengan header Authorization, format token, atau siklus hidup kredensial. Berikut perbaikan yang paling umum.

5. Verifikasi Header Authorization

Kesalahan developer yang paling umum adalah header Authorization yang salah format. Jika server mengirim header WWW-Authenticate, header itu menyebutkan skema yang diharapkan; banyak API JSON (misalnya API GitHub dan OpenRouter) tidak mengirimnya dan menjelaskan masalahnya di body respons.

Pastikan header Anda sesuai dengan format yang diminta. Skema yang paling umum adalah Bearer (untuk token) dan Basic (untuk username:password yang di-encode dalam Base64).

# Bearer token authentication (most APIs)
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIs..." https://api.example.com/data

# Basic authentication (username:password in Base64)
curl -u "username:password" https://api.example.com/data
# Equivalent to:
curl -H "Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=" https://api.example.com/data

# Common mistakes that cause 401:
# Missing "Bearer " prefix:  Authorization: eyJhbGci...  ← WRONG
# Extra space:               Authorization: Bearer  eyJ... ← many servers reject it
# Wrong scheme:              Authorization: Basic eyJhbGci... ← WRONG

Lalu baca header WWW-Authenticate di respons 401: header itu menyebutkan skema yang diharapkan server. Cek HTTP Header dari DNS Robot menampilkan respons lengkapnya.

6. Periksa Validitas API Key

API key berhenti berfungsi ketika key dirotasi atau dicabut, akunnya ditangguhkan atau paketnya diturunkan, atau key uji dipakai di production. (Batas rate limit dijawab dengan 429, dan key yang tidak punya akses ke sebuah endpoint biasanya mendapat 403.)

Pastikan key masih aktif di dashboard provider, lalu uji langsung:

# Test a key: print only the status code (a real GET; some APIs reject HEAD)
curl -s -o /dev/null -w "%{http_code}\n" -H "Authorization: Bearer YOUR_API_KEY" https://api.example.com/me
# 200 = the key works
# 401 = the key is missing, wrong, revoked or expired
# 403 = the key works but isn't allowed to use this endpoint

# Common slips:
# 1. A space or newline after the key in .env:   API_KEY="abc123 "
# 2. The test key in production, or the reverse
# 3. An empty variable, so the header is just "Authorization: Bearer"

7. Tangani Kedaluwarsa dan Refresh Token

Token JWT dan token akses OAuth punya masa berlaku terbatas, biasanya 15 menit sampai 24 jam. Setelah kedaluwarsa, setiap panggilan API mengembalikan 401 sampai Anda mendapatkan token baru.

Jika Anda punya refresh token (OAuth 2.0 dan sebagian besar setup JWT), tukarkan dengan token akses baru; jika tidak, login lagi.

# Read a JWT's payload (tokens use base64url, so plain base64 -d often fails)
python3 -c 'import sys,base64,json; p=sys.argv[1].split(".")[1]; print(json.dumps(json.loads(base64.urlsafe_b64decode(p+"==")),indent=2))' "$TOKEN"
# "exp" is a Unix timestamp; compare it with: date +%s

# OAuth 2.0: get a new access token with the refresh token
curl -X POST https://auth.example.com/token \
  -d "grant_type=refresh_token" \
  -d "refresh_token=YOUR_REFRESH_TOKEN" \
  -d "client_id=YOUR_CLIENT_ID"

8. Perbaiki Masalah CORS Preflight

Ketika halaman web memanggil API di domain lain dengan header Authorization, browser lebih dulu mengirim permintaan preflight OPTIONS, dan preflight tidak pernah membawa kredensial. Jika server menuntut autentikasi pada OPTIONS, server menjawab 401, preflight gagal, dan browser melaporkan error CORS: permintaan sebenarnya tidak pernah terkirim.

Perbaikannya: izinkan permintaan OPTIONS lewat tanpa autentikasi pada endpoint yang mengaktifkan CORS.

# Nginx — allow OPTIONS requests without auth
location /api/ {
    if ($request_method = OPTIONS) {
        add_header Access-Control-Allow-Origin https://app.example.com;
        add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS";
        add_header Access-Control-Allow-Headers "Authorization, Content-Type";
        add_header Access-Control-Max-Age 86400;
        return 204;
    }

    # CORS header on every other answer, the 401 included, or the browser reports a CORS error
    add_header Access-Control-Allow-Origin https://app.example.com always;

    # Normal auth for other methods
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

Cara Mengatasi 401 sebagai Pemilik Situs

Jika pengunjung atau pengguna Anda melaporkan error 401, masalahnya ada pada konfigurasi autentikasi server Anda. Lakukan pemeriksaan berikut.

9. Tinjau Konfigurasi Autentikasi Server

Pastikan autentikasi hanya diaktifkan pada rute yang memerlukannya. Kesalahan umum adalah memproteksi seluruh direktori atau situs padahal hanya path tertentu yang perlu login.

Di nginx, periksa direktif auth_basic; di Apache, AuthType dan Require. Di Node.js/Express, periksa urutan middleware: app.use(auth) yang didaftarkan sebelum rute publik ikut memproteksi rute itu, jadi daftarkan rute publik lebih dulu atau pasang auth hanya pada router yang dilindungi.

# Nginx — WRONG: protects everything, including public pages
server {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    # All pages now require login — including your homepage!
}

# Nginx — CORRECT: only protect admin routes
server {
    location / {
        # Public — no auth required
    }
    location /admin/ {
        auth_basic "Admin Area";
        auth_basic_user_file /etc/nginx/.htpasswd;
    }
}

10. Periksa Aturan Autentikasi .htaccess

Di Apache, file .htaccess bisa mengaktifkan autentikasi Basic atau Digest untuk sebuah direktori. Jika direktori publik punya .htaccess dengan direktif AuthType dan Require, setiap pengunjung mendapat prompt login 401.

Periksa file .htaccess di direktori yang terdampak dan semua direktori induknya: Apache menerapkan aturan dari setiap .htaccess di sepanjang path.

# Find all .htaccess files with auth rules
find /var/www/html -name '.htaccess' -exec grep -l 'AuthType\|AuthUserFile\|Require valid-user' {} \;

# Example .htaccess that causes 401 for everyone:
# AuthType Basic
# AuthName "Restricted Area"
# AuthUserFile /etc/apache2/.htpasswd
# Require valid-user

# Fix: remove auth lines from public directories,
# or move them to the specific /admin/.htaccess only

11. Pastikan Header Authorization Sampai ke Aplikasi Anda

Klien mengirim kredensial yang benar, tetapi aplikasi tidak pernah melihatnya. Di sinilah header itu bisa hilang:

nginx meneruskan Authorization ke backend secara default, jadi Anda tidak perlu baris tambahan; tetapi jika location yang sama memakai auth_basic, login nginx mengambil alih header itu (lihat bagian nginx di atas). Apache menyembunyikan Authorization dari PHP-FPM dan skrip CGI kecuali Anda menyalakan CGIPassAuth (Apache 2.4.13+), penyebab klasik 401 di API WordPress dan Laravel yang berjalan di belakang Apache.

# Apache 2.4.13+ (inside a <Directory> block, or .htaccess): pass Authorization to PHP-FPM and CGI
CGIPassAuth On

# Older Apache: copy it into an environment variable instead
SetEnvIf Authorization "(.+)" HTTP_AUTHORIZATION=$1

Debugging Error 401 dengan Header HTTP

Cara tercepat mendiagnosis 401 adalah membaca responsnya: header WWW-Authenticate, jika dikirim server, menyebutkan login yang diminta, dan API JSON biasanya menjelaskan error-nya di body.

Gunakan Cek HTTP Header dari DNS Robot (jika 401 baru muncul setelah redirect, Cek Redirect menunjukkan hop mana yang menjawabnya), atau curl dari terminal:

# Print the response headers of a real GET
curl -sS -D - -o /dev/null https://api.example.com/protected-endpoint

# A 401 often carries one of:
# WWW-Authenticate: Bearer realm="api", error="invalid_token"
# WWW-Authenticate: Basic realm="Admin Area"

# It tells you:
# - the scheme (Bearer, Basic, Digest, Negotiate)
# - the realm (which area is protected)
# - for Bearer tokens, the error: invalid_request, invalid_token or insufficient_scope

Jika WWW-Authenticate menyebut Bearer, Anda memerlukan token; jika Basic, username dan password. error="invalid_token" berarti token kedaluwarsa, dicabut, salah format, atau tidak valid karena alasan lain. Tidak ada header sama sekali? Baca body respons: banyak API menaruh alasannya di sana.

Apakah Error 401 Memengaruhi SEO?

401 pada halaman publik mengeluarkan halaman itu dari Google. Google memperlakukan semua kode 4xx kecuali 429 dengan cara yang sama: crawler melaporkan bahwa kontennya tidak ada, dan URL yang sudah terindeks dihapus (dokumentasi crawler Google).

401 pada halaman yang memang seharusnya memerlukan login (panel admin, dashboard, API) itu normal: Google tidak menghukum situs karenanya. Hanya saja, jangan memakai 401 atau 403 untuk memperlambat Googlebot; Google menyatakan keduanya tidak berpengaruh pada kecepatan crawling.

Masalahnya adalah 401 pada halaman yang seharusnya publik, biasanya karena autentikasi diterapkan ke seluruh situs, atau aturan CDN maupun proxy meminta kredensial pada path publik.

Cara Mencegah Error 401

Pencegahan menghemat waktu debugging di kemudian hari. Ikuti praktik berikut untuk meminimalkan error 401 di aplikasi dan situs web Anda.

• Terapkan auto-refresh token — gunakan refresh token untuk mendapatkan token akses baru secara otomatis sebelum kedaluwarsa
• Atur cakupan auth dengan tepat — lindungi hanya rute yang benar-benar memerlukan autentikasi, biarkan halaman publik tetap terbuka
• Gunakan pesan error yang jelas — kembalikan body error JSON yang informatif bersama 401, bukan hanya kode status
• Pantau kegagalan auth — pasang peringatan untuk lonjakan respons 401, yang bisa menandakan masalah kredensial atau serangan
• Sinkronkan jam server — gunakan NTP agar semua server berselisih paling banyak beberapa detik dari UTC, sehingga JWT tidak ditolak karena clock skew
• Uji dengan Cek HTTP Header — pastikan secara rutin halaman publik mengembalikan 200 dan halaman yang dilindungi mengembalikan 401 sesuai harapan
• Dokumentasikan skema auth Anda — jelaskan format header Authorization yang diharapkan dalam dokumentasi API
• Tangani CORS preflight — selalu izinkan permintaan OPTIONS tanpa autentikasi pada endpoint API