Belajar Curl - Authentication, Cookies & Session
Pada episode ini kita akan menangani berbagai skema autentikasi seperti Basic, Digest, NTLM, dan Bearer token, serta mengelola cookie dan alur login sesi dengan cookie jar.
#Pendahuluan
Di episode 9 kalian sudah mengendalikan jaringan — proxy, DNS, dan koneksi. Sekarang kita masuk ke lapisan berikutnya: siapa kalian. Banyak endpoint tidak akan menjawab sebelum membuktikan identitas. Pada episode ini kita akan membedah skema autentikasi yang paling sering dipakai di dunia nyata — dari yang sederhana seperti Basic hingga token modern — lalu menutup dengan pengelolaan cookie untuk membangun sesi login yang utuh.
Pemahaman penting sejak awal: autentikasi menjawab pertanyaan "siapa kamu?", sedangkan otorisasi menjawab "apa yang boleh kamu lakukan?". curl membantu yang pertama; server yang memutuskan yang kedua. Kebingungan antara keduanya adalah sumber error 401 (tidak terautentikasi) versus 403 (tidak diizinkan) yang sering tertukar.
#Autentikasi Basic: -u
Skema Basic adalah yang paling tua dan paling sederhana. Kredensial dikirim sebagai header Authorization dengan nilai berformat Basic <hasil-base64> — dalam praktiknya, kalian tidak perlu menghitung base64 manual karena -u mengurusnya:
curl -u budi:rahasia https://api.example.com/private/data-u budi:rahasia mengirim nama pengguna dan sandi sekaligus. Karena pengkodean base64 hanyalah encoding, bukan enkripsi — siapapun yang mengintip lalu lintas bisa memecahkannya — Basic auth wajib dipakai bersama HTTPS. Tanpa TLS, kredensial kalian terkirim hampir telanjang di jaringan.
Tip
Jika kalian menulis -u budi tanpa titik dua dan sandi, curl akan meminta sandi secara interaktif dengan prompt tersembunyi. Pola ini menjaga sandi tetap jauh dari command history dan log shell — kebiasaan yang baik untuk sesi manual di mesin bersama.
#Digest: --digest
Digest dibuat untuk memperbaiki kelemahan Basic. Alih-alih mengirim kredensial, client menghitung hash dari kombinasi kredensial, nonce, dan parameter lain dari server:
curl --digest -u budi:rahasia https://api.example.com/private/dataKarena yang dikirim adalah hash, bukan kredensial mentah, Digest lebih aman dari Basic terhadap pembacaan pasif — meskipun keduanya tetap sebaiknya lewat HTTPS. Beberapa server (terutama yang lama) hanya menerima Digest, jadi tahu kapan memakai --digest menghindarkan kalian dari error berulang.
#NTLM dan Negotiate
Di lingkungan Windows dan infrastruktur perusahaan, dua skema lain muncul: NTLM dan Negotiate (kerberos). NTLM adalah protokol berbasis challenge-response yang khas Windows; Negotiate memilih skema terbaik secara otomatis, biasanya Kerberos di jaringan domain.
curl --ntlm -u domain\\budi:rahasia https://intranet.example.com/datacurl --negotiate -u : https://intranet.example.com/dataPerhatikan dua detail: pada NTLM, nama pengguna sering menyertakan domain dengan garis miring ganda (domain\budi — di shell perlu di-escape). Pada --negotiate, kalian bisa membiarkan -u : untuk memakai kredensial yang sudah ada di environment. Skema ini hampir tidak dipakai di API publik, tapi wajib dikenal saat bekerja dengan sistem internal perusahaan.
#Bearer Token: -H dan --oauth2-bearer
Era modern API berbasis token: client meminta token dari server auth, lalu mengirimkannya di setiap request. Format paling umum adalah Bearer token di header Authorization:
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9..." \
https://api.example.com/meMenulis header manual itu mudah, tapi ada opsi yang lebih ringkas: --oauth2-bearer menerima token tanpa perlu menulis string Authorization: Bearer setiap kali:
curl --oauth2-bearer "eyJhbGciOiJIUzI1NiJ9..." \
https://api.example.com/meWarning
Jangan pernah menempel token di command line pada mesin yang dipakai bersama — token akan tersimpan di command history dan bisa dibaca process lain. Simpan token di environment variable atau file kredensial, lalu baca lewat shell expansion di dalam script.
#Cookie dan Sesi
Tidak semua aplikasi memakai token; banyak web app masih mengandalkan cookie untuk melacak sesi. Setelah login, server mengirim cookie Set-Cookie, dan browser (atau curl) harus mengirimkannya kembali di setiap request berikutnya. curl menangani ini dengan dua opsi sederhana: -c untuk menyimpan cookie ke file, -b untuk membaca cookie dari file.
#Cookie Jar: -c dan -b
curl -c cookies.txt --json '{"user":"budi","pass":"rahasia"}' \
https://app.example.com/api/loginSetelah login di atas, semua cookie Set-Cookie dari respons tersimpan di file cookies.txt (cookie jar). Request berikutnya tinggal membaca file yang sama:
curl -b cookies.txt https://app.example.com/api/profileKarena curl tidak menyimpan cookie antar perintah secara otomatis — tidak seperti browser — cookie jar adalah cara untuk mempertahankan sesi lintas command. Ini adalah dasar dari alur "login sekali, akses berkali-kali" di script.
#Set Cookie Manual: -b "name=value"
Untuk mengirim cookie yang sudah diketahui tanpa file, -b juga menerima pasangan nama-nilai langsung:
curl -b "session=abc123; theme=dark" https://app.example.com/dashboardBeberapa cookie dipisahkan titik koma dalam satu string. Pola ini cepat untuk pengujian ringan, tapi untuk sesi yang kompleks, cookie jar tetap pilihan utama karena menyimpan atribut seperti expiry dan domain.
#Workflow Login Session
Mari rangkai semuanya menjadi alur nyata: login, simpan cookie, lalu akses resource yang dilindungi.
curl -c cookies.txt --json '{"user":"budi","pass":"rahasia"}' \
https://app.example.com/api/logincurl -b cookies.txt https://app.example.com/api/profile | jqcurl -b cookies.txt -X POST https://app.example.com/api/logoutAlur di atas adalah prototipe persis dari apa yang dilakukan browser saat kalian login: request pertama membuktikan identitas, respons menyediakan cookie, dan request berikutnya membawa cookie sebagai bukti. Dengan memahami urutan ini, kalian bisa mengotomatiskan apa pun yang berbasis sesi web — dari mengunduh laporan berbayar hingga mengecek dashboard internal.
#Penutup
Episode 10 melengkapi kalian dengan identitas digital di curl: Basic auth lewat -u user:pass atau prompt interaktif, Digest dengan --digest, NTLM dan Negotiate untuk lingkungan perusahaan, Bearer token lewat -H "Authorization: Bearer ..." atau --oauth2-bearer, serta pengelolaan sesi dengan cookie jar -c dan -b.
Inti yang perlu diingat: autentikasi adalah bukti identitas, cookie adalah kartu masuk yang menemanimu — dan HTTPS adalah syarat mutlak untuk hampir semua skema di atas. Semakin paham kalian memilih skema, semakin sedikit drama 401 di masa depan.
Di episode 11 berikutnya kita akan membahas timeout, retry, dan rate limiting — bagaimana membuat curl tidak menggantung selamanya, bagaimana menahan kegagalan sementara, dan bagaimana membatasi kecepatan transfer. Sampai jumpa!