Autentikasi Dasar vs Token Bearer Metode Autentikasi API yang Harus Digunakan

Setiap permintaan API harus membuktikan siapa yang membuatnya. Metode yang Anda pilih akan menentukan posisi keamanan, pengalaman pengembang, dan beban operasional selama bertahun-tahun. Autentikasi Dasar, kunci API, token Bearer, dan OAuth masing-masing menyelesaikan masalah yang berbeda — dan menggunakan yang salah akan menciptakan utang yang sulit diperbaiki nanti. Berikut adalah penjelasan jelas dari masing-masing metode, dengan kode yang dapat disalin dan tabel keputusan agar Anda dapat memilih solusi yang tepat untuk kebutuhan Anda.

Autentikasi HTTP Dasar

Autentikasi Dasar mengirimkan kredensial setiap kali permintaan dilakukan. Klien menggabungkan nama pengguna dan kata sandi sebagai username:password, melakukan enkripsi Base64 pada string tersebut, dan menempatkannya di header Authorization :

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

String Base64 tersebut adalah tidak dienkripsi. Siapa pun yang mengintersepsi permintaan dapat mendekodekannya dalam beberapa detik. Autentikasi Dasar hanya aman saat digunakan melalui HTTPS, dan bahkan dalam kasus tersebut, kredensial tetap dikirim dalam setiap permintaan dan tercatat di log server kecuali Anda secara aktif menghapusnya.

Untuk menghasilkan nilai header yang benar tanpa mengenkripsi kredensial secara manual, gunakan generator Autentikasi Dasar IO Tools Generator Autentikasi Dasar IO Tools.

# curl with Basic Auth
curl -u username:password https://api.example.com/data

# Or with the explicit header
curl -H "Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=" https://api.example.com/data

// fetch with Basic Auth
const credentials = btoa('username:password');
fetch('https://api.example.com/data', {
  headers: { Authorization: `Basic ${credentials}` }
});

Kapan dapat digunakan: Alat internal, lingkungan pengembangan, dan integrasi antar server sederhana di mana Anda mengontrol kedua ujungnya. Jangan gunakan untuk API yang dihadapkan secara publik atau untuk autentikasi pengguna.

Kunci API

Kunci API adalah token statis — sebuah string acak panjang yang dikaitkan dengan aplikasi atau pemanggil tertentu. Klien mengirimkannya dalam header, biasanya di X-API-Key atau melalui header Authorization dengan skema khusus:

# curl with API key
curl -H "X-API-Key: sk_live_abc123xyz" https://api.example.com/data

# Or with Authorization header
curl -H "Authorization: ApiKey sk_live_abc123xyz" https://api.example.com/data

// fetch with API key
fetch('https://api.example.com/data', {
  headers: { 'X-API-Key': 'sk_live_abc123xyz' }
});

Kunci API mudah diimplementasikan dan dapat segera dicabut saat terkompromi. Kelemahannya: kunci ini tidak memiliki keadaan (stateless) dan tidak memiliki batas waktu bawaan. Jika kunci terbocor, ia tetap valid sampai Anda secara manual mencabutnya. Tidak ada tanda tangan untuk memverifikasi dan tidak ada cakupan bawaan — hanya sebuah string yang harus dicari di dalam database.

Kapan digunakan: Integrasi pihak ketiga, produk API untuk pengembang, dan akses API publik di mana Anda ingin batas kecepatan per-klien dan pencabutan segera tanpa beban dari OAuth.

Token Bearer (JWT)

Token Bearer — paling umum JWT (JSON Web Token) — dikeluarkan oleh server autentikasi dan dikirimkan dalam header Authorization dengan skema Bearer :

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

JWT mengandung payload yang ditandatangani yang berisi klaim: siapa pengguna, apa izin yang dimilikinya, dan kapan token tersebut kedaluwarsa. Server memverifikasi token dengan memeriksa tanda tangan terhadap rahasia bersama atau kunci publik — tidak perlu pencarian di database. Keuntungan ini yang tidak berkeadaan menjadi keunggulan utama dalam sistem terdistribusi dan arsitektur mikroservis.

Kompromi-kompromi ini nyata: JWT besar (beberapa ratus byte per permintaan), dan tidak dapat dicabut sebelum kedaluwarsa tanpa infrastruktur tambahan seperti daftar token yang diblokir. Kesalahan implementasi — rahasia penandatanganan yang lemah, kekurangan pengecekan kedaluwarsa, serangan akibat kebingungan algoritma — telah menyebabkan kebocoran serius dalam sistem produksi.

# curl with Bearer token
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \
  https://api.example.com/data

// fetch with Bearer token
fetch('https://api.example.com/data', {
  headers: { Authorization: `Bearer ${token}` }
});

Kapan digunakan: API yang dihadapkan kepada pengguna, mikroservis yang perlu mengalirkan identitas ke bawah, dan skenario mana pun yang membutuhkan kredensial singkat dengan klaim terintegrasi untuk mengurangi kebutuhan akan keadaan sesi di server sisi.

OAuth 2.0: Token Akses dan Token Refresh

OAuth 2.0 bukan format token — ini adalah protokol delegasi. Ketika aplikasi Anda perlu bertindak atas nama pengguna dan mengakses sumber daya di layanan lain, OAuth 2.0 mengelola persetujuan dan pertukaran token.

Alur singkatnya: pengguna memberikan persetujuan akses, server autentikasi mengeluarkan token akses yang singkat token akses dan token refresh yang panjang token refresh, aplikasi Anda menggunakan token akses untuk permintaan API, dan ketika token akses kedaluwarsa, token refresh menukar ke satu baru tanpa meminta pengguna kembali.

# Step 1: Exchange credentials for a token (client credentials flow)
curl -X POST https://auth.example.com/token \
  -d "grant_type=client_credentials" \
  -d "client_id=myapp" \
  -d "client_secret=mysecret"

# Step 2: Use the access token
curl -H "Authorization: Bearer ACCESS_TOKEN" https://api.example.com/data

# Step 3: Refresh when expired
curl -X POST https://auth.example.com/token \
  -d "grant_type=refresh_token" \
  -d "refresh_token=REFRESH_TOKEN" \
  -d "client_id=myapp"

Token akses biasanya berupa JWT. Token refresh adalah string yang tidak transparan yang disimpan di sisi server — jangan pernah ekspor ke kode di sisi browser.

Kapan diperlukan: Login sosial, akses data pihak ketiga, integrasi "Login dengan X", atau skenario mana pun di mana pengguna manusia harus memberikan persetujuan terhadap apa yang diizinkan aplikasi Anda lakukan atas nama mereka.

Aturan Keamanan yang Berlaku untuk Semua Metode

Tidak peduli metode autentikasi mana yang Anda pilih, aturan-aturan berikut berlaku tanpa pengecualian.

• HTTPS di mana saja. Kredensial atau token yang dikirimkan melalui HTTP biasa terkompromi seketika seseorang dapat memeriksa paketnya. Tidak ada pengecualian.
• Jangan simpan rahasia di kode. Gunakan variabel lingkungan atau manajer rahasia. Tidak ada kredensial di file yang dikendalikan versi — termasuk file yang dikecualikan oleh .gitignore, karena kecualiannya tidak dapat diandalkan dalam praktik.
• Rotasi sesuai jadwal dan saat diperlukan. Kunci API harus dapat dirotasi tanpa gangguan. Rahasia penandatanganan JWT harus mendukung versi agar Anda dapat mengganti tanpa membatalkan semua sesi aktif secara bersamaan.
• Waktu berlaku terpendek yang bekerja. Token akses: menit hingga beberapa jam. Kunci API: rotasi saat ada perubahan staf. Kredensial autentikasi dasar: anggap sebagai hak istimewa dan rotasi secara proaktif.
• Audit siapa yang memiliki apa. Pertahankan daftar kredensial yang dikeluarkan. Ketika sesuatu salah, Anda perlu tahu secara tepat apa yang dikeluarkan, kepada siapa, dan kapan.

Panduan Keputusan: Metode yang Tepat untuk Kebutuhan

Metode	Tidak memiliki keadaan	Dapat dicabut	Kompleksitas	Cocok untuk
Auth Dasar	Ya	Hanya dengan mengubah kredensial	Sangat rendah	Alat internal, lingkungan pengembangan
Kunci API	Ya	Ya, segera	Rendah	Integrasi pihak ketiga, API untuk pengembang
Bearer (JWT)	Ya	Hanya dengan daftar token yang diblokir	Sedang	API yang dihadapkan kepada pengguna, mikroservis
OAuth 2.0	Beragam	Ya	Tinggi	Delegasi pengguna, autentikasi pihak ketiga

API internal, integrasi antar server, tanpa pengguna: Kunci API. Mudah diimplementasikan, dapat dicabut segera, mudah diaudit. Jika Anda sudah menjalankan mikroservis dengan JWT, gunakan token akun layanan dengan masa berlaku singkat sebagai gantinya.

API publik dengan konsumen pengembang eksternal: Kunci API dengan batas kecepatan per-kunci dan portal manajemen berbasis sendiri. Tambahkan cakupan OAuth jika konsumen Anda membutuhkan akses ke sumber daya tertentu atas nama pengguna mereka sendiri.

Autentikasi pengguna dalam produk Anda sendiri: Token Bearer (JWT) dengan masa berlaku singkat dan rotasi token refresh. Keluarkan token setelah verifikasi kredensial, jaga masa berlakunya pendek, dan hindari menyimpannya di localStorage jika ada risiko XSS dalam aplikasi Anda.

Mengakses layanan pihak ketiga atas nama salah satu pengguna Anda: Alur oAuth 2.0 dengan kode persetujuan. Jangan singkatkan ini. Model delegasi pengguna ada karena merupakan cara paling aman untuk menangani persetujuan pihak ketiga pada skala besar.

Pilihan yang tepat biasanya ditentukan oleh dua pertanyaan: siapa yang memanggil, dan apakah pengguna manusia perlu memberikan persetujuan terhadap apa yang dilakukan oleh pemanggil tersebut? Jika pemanggilnya adalah mesin dan tidak ada delegasi pengguna, kunci API dapat menangani kebanyakan kasus secara bersih. Tambahkan JWT saat Anda membutuhkan klaim terintegrasi atau identitas tanpa keadaan antar layanan. Gunakan OAuth hanya ketika persetujuan pengguna merupakan bagian dari alur.

Anda mungkin juga menyukai