Bedah Header Authorization: Bearer, Basic, ApiKey

Lencana dengan warna berbeda

Di konferensi, lencana peserta punya warna: biru untuk peserta, merah untuk panitia, kuning untuk VIP. Satu leher, banyak arti tergantung warnanya. Header Authorization bekerja sama: satu header, banyak skema (Basic, Bearer, ApiKey, Digest), dan server membaca skema untuk tahu cara memverifikasi.

Kenapa satu header banyak skema

HTTP dirancang netral: ia tidak memaksakan satu cara auth untuk semua kebutuhan. API internal cukup Basic, aplikasi modern pakai Bearer JWT, integrasi server pakai ApiKey. Satu header standar membuat semua klien (browser, curl, Postman, library) tahu ke mana menaruh kredensial, apa pun metodenya.

Contoh 1: tiga skema populer

Authorization: Basic YWRtaW46cmFoYXNpYTEyMw==
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJpZCI6NDJ9.c2ln
Authorization: ApiKey abc123xyz

Format universal: Skema + spasi + kredensial. Server membaca kata pertama untuk memilih cara verifikasi. Case skema tidak sensitif (bearer sama dengan Bearer), tapi tulis kapitalisasi standar.

Contoh 2: membangun header di kode

function headerAuth(skema, kredensial) {
  return { "Authorization": skema + " " + kredensial };
}

// Bearer JWT
await fetch("/api/profil", {
  headers: headerAuth("Bearer", token)
});

// API Key
await fetch("/api/cuaca", {
  headers: headerAuth("ApiKey", "abc123xyz")
});

Satu helper untuk semua skema. Perhatikan spasi antara skema dan kredensial: lupa spasi adalah bug klasik yang menghasilkan 401 misterius.

Kesalahan umum

Salah: typo nama skema. Bearar atau bearer dengan dua spasi membuat server tidak mengenali skema. Yang benar: periksa ejaan dan satu spasi.

Salah: menaruh token di URL padahal header tersedia. Query tersimpan di log dan history. Yang benar: selalu pakai header Authorization.

Salah: mengirim Authorization ke domain lain. Redirect lintas domain bisa membawa header auth ke server asing. Yang benar: fetch tidak meneruskan Authorization saat redirect lintas origin secara default; waspadai konfigurasi custom.

Salah: tidak menangani 401 dari skema kedaluwarsa. Token Bearer kedaluwarsa harus memicu refresh, bukan error permanen. Yang benar: gabungkan dengan pola interceptor dari modul sebelumnya.

Debugging 401 langkah demi langkah

Saat menerima 401 misterius, periksa berurutan:

1. Apakah header terkirim? Lihat tab Network > Request Headers. Tidak ada? Kode lupa memasang.
2. Format benar? Harus Skema(spasi)kredensial. Typo skema adalah penyebab #1.
3. Token valid? Paste JWT ke jwt.io untuk cek expiry. Token kedaluwarsa = 401 wajar.
4. Skema didukung? Server mungkin hanya terima Bearer, kamu kirim ApiKey.
5. CORS preflight? Untuk cross-origin, pastikan Authorization ada di allowedHeaders server.

Lima langkah ini menyelesaikan hampir semua 401 dalam lima menit tanpa menebak-nebak.

Satu jebakan terakhir: beberapa server mengharuskan skema ditulis persis Bearer dengan huruf B kapital, meski standar bilang case-insensitive. Kalau 401 misterius padahal token benar, coba ubah kapitalisasi skema sebelum debugging yang lain.

Catatan teknis: Ada juga skema Digest (challenge-response, jarang dipakai modern) dan HOBA. Untuk hampir semua kasus modern, cukup kuasai Basic, Bearer, dan ApiKey.