Access Key and Secret Key

Secara singkat, Access Key adalah "nama pengguna" untuk sebuah aplikasi, dan Secret Key adalah "kata sandinya". Keduanya digunakan bersamaan untuk membuktikan identitas sebuah aplikasi saat ingin mengakses layanan lain secara terprogram (tanpa campur tangan manusia).


Kenapa Dibutuhkan?

Bayangkan Anda punya toko online yang menggunakan layanan payment gateway. Saat ada pembeli melakukan pembayaran, sistem toko online Anda perlu memberi tahu sistem payment gateway: "Hei, tolong buatkan tagihan untuk customer A sebesar Rp100.000".

Pertanyaannya adalah:

  1. Bagaimana payment gateway tahu bahwa yang meminta adalah toko online Anda yang sah dan bukan orang iseng?

  2. Bagaimana payment gateway yakin bahwa detail permintaan (misalnya jumlah Rp100.000) tidak diubah di tengah jalan oleh peretas?

Inilah fungsi utama Access Key dan Secret Key: Autentikasi (membuktikan identitas) dan Integritas Pesan (memastikan data tidak diubah). Ini memungkinkan komunikasi server-to-server yang aman tanpa perlu login manual setiap saat.


Cara Kerja dan Flow Verifikasi di Belakang Layar

Proses ini menggunakan teknik kriptografi yang disebut HMAC (Hash-based Message Authentication Code). Kuncinya adalah: Secret Key tidak pernah dikirimkan melalui jaringan. Yang dikirim adalah "bukti" bahwa Anda memiliki Secret Key tersebut.

Berikut adalah alur kerjanya langkah demi langkah:

Langkah 1: Di Sisi Aplikasi Anda (Contoh: Toko Online)

  1. Buat Permintaan (Request): Aplikasi Anda menyiapkan semua data yang ingin dikirim. Misalnya:

    • Aksi: create_invoice

    • Jumlah: 100000

    • ID Pesanan: XYZ-123

    • Stempel Waktu (Timestamp): 2025-07-07T10:00:00Z (Ini penting untuk mencegah serangan replay).

  2. Buat "Tanda Tangan" (Signature): Ini adalah langkah paling krusial.

    • Aplikasi Anda mengambil semua data permintaan di atas dan menggabungkannya menjadi satu string (teks) yang teratur.

    • String ini kemudian di-hash (diacak secara matematis) menggunakan Secret Key Anda sebagai "kunci" hashing.

    • Hasil dari proses hashing ini adalah sebuah string acak dan unik yang disebut Signature (tanda tangan digital).

    Analogi: Anggap Secret Key adalah stempel rahasia milik Anda. Anda menempelkan stempel ini pada dokumen permintaan. Siapapun bisa melihat stempelnya (signature), tapi hanya Anda yang bisa membuatnya karena hanya Anda yang punya stempel aslinya (Secret Key).

  3. Kirim Permintaan: Aplikasi Anda mengirim semua data permintaan ke server layanan (misal, payment gateway), BERSAMA DENGAN:

    • Access Key Anda (agar server tahu "siapa" yang mengirim).

    • Signature yang baru saja dibuat.

    PENTING: Perhatikan bahwa Secret Key Anda tetap aman dan TIDAK PERNAH DIKIRIM.

Langkah 2: Di Sisi Server Layanan (Contoh: Payment Gateway)

  1. Terima Permintaan: Server menerima data permintaan, Access Key, dan Signature dari aplikasi Anda.

  2. Identifikasi Pengguna: Server menggunakan Access Key yang diterima untuk mencari Secret Key yang sesuai di dalam databasenya. Server sekarang tahu "Oh, ini permintaan dari Toko Anda, dan ini Secret Key yang seharusnya dia miliki".

  3. Buat Ulang Signature Versi Server: Server melakukan proses yang PERSIS SAMA seperti yang Anda lakukan di Langkah 1.

    • Server mengambil data permintaan yang diterimanya (aksi, jumlah, ID pesanan, timestamp).

    • Server menggabungkannya menjadi string dengan format yang sama persis.

    • Server melakukan proses hashing pada string tersebut menggunakan Secret Key yang tadi ia temukan di databasenya.

    • Server kini memiliki "Signature Versi Server".

  4. Verifikasi: Server membandingkan dua hal:

    • Signature yang dikirim oleh aplikasi Anda.

    • Signature Versi Server yang baru saja dibuatnya sendiri.

  5. Ambil Keputusan:

    • ✅ Jika kedua signature cocok, berarti permintaan itu ASLI (datang dari pemilik Secret Key yang sah) dan UTUH (tidak ada data yang diubah di tengah jalan). Permintaan akan diproses.

    • ❌ Jika tidak cocok, berarti ada yang salah. Mungkin Secret Key yang digunakan salah, atau data telah dimanipulasi oleh peretas. Permintaan akan langsung DITOLAK dengan kode error (misalnya 401 Unauthorized atau 403 Forbidden).

Contoh Praktis

  • Amazon S3: Saat Anda ingin mengunggah file dokumen.pdf dari server Anda ke S3, aplikasi Anda akan membuat signature berdasarkan detail permintaan (nama bucket, nama file, tipe file, dll) menggunakan Secret Key Anda. S3 akan memverifikasi signature ini sebelum mengizinkan file diunggah.

  • Payment Gateway: Saat toko Anda meminta pembuatan tagihan, signature memastikan bahwa tidak ada yang bisa mencegat permintaan dan mengubah jumlah tagihan dari Rp100.000 menjadi Rp1.000.000. Jika diubah, signature tidak akan cocok lagi.

Last updated