Authorization

Penggunaan

Header permintaan Authorization digunakan untuk memperoleh akses ke sumber daya yang dilindungi dan biasanya dikirim setelah klien diberi tahu bahwa akses dibatasi. Misalnya, setelah menerima respons HTTP 401 Unauthorized dari server yang menyertakan header WWW-Authenticate, klien mengirimkan kredensial dengan cara ini.

Catatan

Browser menghapus header Authorization ketika sebuah permintaan dialihkan ke origin yang berbeda. Hal ini mencegah kebocoran kredensial ketika redirect mengarah ke server pihak ketiga. Perilaku ini didefinisikan dalam WHATWG Fetch Standard dan didukung di semua browser modern. Aplikasi yang mengandalkan header Authorization melintasi redirect lintas origin perlu menangani autentikasi ulang di tujuan akhir. Alat seperti curl, Python Requests, dan klien HTTP milik Go mengikuti konvensi yang sama.

authentication-scheme

authentication-scheme adalah direktif wajib, disertai parameter opsional yang spesifik untuk tiap skema. Skema menentukan metode pengodean kredensial. Pendekatan yang umum mencakup Basic, Bearer, Digest, dan Negotiate.

Contoh

Pada contoh ini, klien menggunakan skema autentikasi Basic. Sebagai parameter wajib, kredensialnya adalah pasangan username:password yang dikodekan dengan base64.

Authorization: Basic RXhhbXBsZTphaQ==

Token Bearer umum dipakai pada API OAuth 2.0. Token tersebut berupa string opak atau JWT bertanda tangan yang diterbitkan oleh server otorisasi.

Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

Pemecahan masalah

Kegagalan autentikasi sering muncul sebagai respons 401 yang tidak terduga atau kredensial yang dibuang tanpa pemberitahuan.

Kredensial dihapus pada redirect lintas origin. Browser dan klien HTTP menghapus header Authorization ketika sebuah permintaan dialihkan ke origin yang berbeda. Perbaikannya adalah mengirim kredensial langsung ke tujuan akhir atau melakukan autentikasi ulang setelah redirect selesai. Periksa rantai redirect dengan curl -L -v untuk memastikan di titik mana header tersebut menghilang.

Kesalahan pengodean Base64 pada autentikasi Basic. String hasil pengodean harus memuat tepat satu titik dua yang memisahkan username dan password. Titik dua yang hilang atau nilai yang terkode ganda menghasilkan token kacau yang akan ditolak server. Verifikasi nilai mentahnya dengan echo -n “user:pass” | base64 dan bandingkan dengan nilai header yang dikirim dalam permintaan.

Token Bearer kedaluwarsa atau salah format. Token membawa klaim kedaluwarsa, dan server menolak token kedaluwarsa dengan 401. Dekode JWT di jwt.io atau dengan echo "" | base64 -d untuk memeriksa field exp. Logika refresh token harus berjalan sebelum token kedaluwarsa, bukan setelah server menolak permintaan.

Loop 401 ketika server menghilangkan WWW-Authenticate. Server mengembalikan 401 tetapi tidak menyertakan header WWW-Authenticate, sehingga klien tidak memperoleh petunjuk tentang skema yang diharapkan. Periksa header respons dengan curl -I https://example.re/resource dan pastikan konfigurasi server menyertakan header tersebut. Pada nginx, direktif auth_basic menambahkan header itu secara otomatis. Backend kustom perlu menyetel header tersebut secara eksplisit.

Preflight CORS memblokir header Authorization. Permintaan lintas origin yang membawa Authorization memicu permintaan preflight OPTIONS. Server harus merespons preflight tersebut dengan Access-Control-Allow-Headers: Authorization. Nilai yang hilang atau keliru menyebabkan browser memblokir permintaan sebelum kredensial terkirim. Tab Network pada DevTools menampilkan preflight itu sebagai entri OPTIONS tersendiri.

curl mengirim kredensial ke endpoint yang salah. Menjalankan curl -H “Authorization: Bearer …” dengan -L akan mengikuti redirect, tetapi menghapus header pada lompatan lintas origin. Gunakan curl -v tanpa -L untuk mengirim header ke endpoint yang tepat, atau tambahkan —location-trusted untuk memaksa penerusan kredensial melintasi redirect (gunakan dengan hati-hati, hanya pada domain tepercaya).

Basic vs Bearer

Basic dan Bearer adalah dua skema autentikasi yang paling umum, melayani kasus penggunaan yang berbeda.

Basic mengirim pasangan username:password yang dikodekan dengan Base64 pada setiap permintaan. Pengodean tersebut sangat mudah dibalik, sehingga HTTPS menjadi wajib. Kredensialnya statis dan terikat pada akun pengguna, jadi password yang bocor mengharuskan penggantian password itu sendiri. Basic bekerja dengan baik untuk perkakas internal dan integrasi sederhana, di mana pengelolaan token justru menambah kerumitan yang tidak perlu.

Bearer menggunakan token opak (sering berupa JWT) yang diterbitkan oleh server otorisasi. Token memiliki masa berlaku, membawa izin dengan cakupan tertentu, dan dapat dicabut tanpa mengubah password yang mendasarinya. Bearer adalah mekanisme standar untuk API dan alur OAuth 2.0. Token yang dicuri memiliki masa hidup terbatas dan cakupan terbatas, sehingga memperkecil dampak dibandingkan password yang bocor.

Kedua skema mengirimkan kredensial dalam bentuk teks biasa di dalam nilai header. Tidak satu pun dari keduanya menyediakan enkripsi dengan sendirinya. HTTPS tetap diperlukan apa pun skema yang dipilih.

Sebuah permintaan API lintas origin dengan token Bearer menggunakan Fetch API.

fetch('https://api.example.re/data', {
  headers: {
    'Authorization': 'Bearer eyJhbGci...'
  }
})