Titik Rawan Keamanan pada Autentikasi dan Otorisasi API
Di balik hampir setiap layanan digital modern, API bekerja sebagai jalur pertukaran data antarsistem. Namun, satu lapisan yang kerap dianggap selesai hanya karena “sudah bisa login” justru menjadi sumber risiko serius: autentikasi dan otorisasi. Banyak insiden keamanan tidak bermula dari ketiadaan mekanisme, melainkan dari mekanisme yang dipasang tanpa pemahaman memadai tentang cara ia gagal. JWT tanpa masa berlaku, API key tertanam di kode sumber, redirect URI OAuth memakai wildcard, Basic Auth dipakai untuk layanan finansial tanpa kepastian TLS—semuanya bukan skenario hipotetis. Itu pola yang berulang di sistem produksi. Kesalahannya sering bukan pada insinyur yang lalai, melainkan pada organisasi yang tidak menetapkan standar, tidak menjelaskan failure mode, tidak memaksa kontrol sejak desain. Autentikasi menjawab siapa pemanggil layanan. Otorisasi menjawab apa yang boleh dilakukan pemanggil itu. Keduanya harus benar secara terpisah. Sistem yang mengenali pengguna dengan tepat tetap bisa membocorkan data bila izin aksesnya salah. Sistem dengan aturan akses ketat tetap mudah ditembus bila identitas pemanggilnya lemah.
Penerapan TLS Sebagai Standar Minimum Keamanan Transport
Sebelum memilih mekanisme, fondasi keamanan harus berdiri. TLS bukan opsi, melainkan syarat minimum untuk semua endpoint, semua lingkungan, bukan hanya produksi. Tanpa HTTPS, header yang membawa Basic Auth, API key, bearer token, atau JWT dapat disadap sebagai teks terbuka. Infrastruktur perlu menolak TLS lama seperti 1.0, 1.1, apalagi SSLv3. Kontrol ini bukan urusan kode aplikasi, melainkan konfigurasi platform. Lingkungan produksi juga tidak boleh terbuka melalui Swagger, Postman, atau tooling publik tanpa pengamanan ketat. Pengujian mesti memakai lingkungan terpisah, kredensial terpisah, data terpisah. Menyalin data produksi ke development bukan sekadar praktik buruk; dalam rezim perlindungan data seperti NDPA 2023 Nigeria, pemrosesan data pribadi harus memiliki tujuan eksplisit dan sah. Dalam PCI-DSS, lingkungan yang menyimpan atau memproses data kartu ikut masuk ruang lingkup kepatuhan. Jawaban teknisnya jelas: data sintetis, data anonim, kredensial nonproduksi, tanpa pengecualian.
Risiko Penggunaan Basic Authentication dan Kunci API Statis
Mekanisme paling sederhana, Basic Authentication, mengirim nama pengguna dan kata sandi pada setiap permintaan dalam bentuk Base64. Masalahnya, Base64 bukan enkripsi. Siapa pun yang memperoleh header dapat mendekodenya. Satu permintaan yang bocor berarti kredensial permanen bocor. Tanpa rate limiting, endpoint Basic Auth menjadi sasaran brute force. Karena itu, penggunaannya layak dibatasi untuk komunikasi internal yang sangat terkendali, selalu terenkripsi, tidak menghadap internet. API key sedikit lebih cocok untuk komunikasi server-ke-server atau integrasi pengembang, tetapi membawa risiko lain: sifatnya statis. Kunci yang muncul di GitHub, log, Slack, atau konfigurasi lama tetap hidup sampai dicabut. Kunci tidak boleh dipakai lintas klien atau lintas lingkungan. Harus ada allowlist domain, pemisahan staging-produksi, rotasi berkala, penyimpanan di secrets manager seperti Vault, AWS Secrets Manager, atau Azure App Configuration. .gitignore tidak cukup. Jika kunci pernah masuk repositori, anggap bocor.
Bearer token dan JWT menjadi pilihan umum untuk aplikasi web dan mobile modern karena lebih skalabel. Pengguna login sekali, menerima token, lalu token dikirim di header Authorization. Risiko utamanya pencurian token. Siapa pun yang memegang token valid dapat bertindak sebagai pengguna sampai token kedaluwarsa atau dicabut. Karena itu, access token harus berumur pendek, umumnya 15 menit hingga satu jam, disandingkan dengan refresh token rotation. JWT sendiri bukan mekanisme autentikasi terpisah, melainkan format bearer token yang membawa klaim seperti subjek, peran, issuer, issued at, expiry. Kelebihannya stateless: server dapat memverifikasi tanda tangan tanpa lookup database. Kelemahannya muncul saat implementasi lemah. Server yang menerima algoritma dari header token tanpa pembatasan dapat terkena serangan algorithm confusion, termasuk token dengan alg none. Secret lemah bisa dipecahkan offline. Token tanpa exp tidak pernah mati. Payload JWT juga hanya Base64, bukan terenkripsi, sehingga tidak boleh memuat kata sandi, nomor rekening penuh, BVN, atau PII sensitif. Untuk pencabutan, organisasi harus memilih blocklist token atau masa berlaku pendek dengan rotasi refresh token.
Delegasi Akses Aman Menggunakan Alur OAuth 2.0
OAuth 2.0 menjawab kebutuhan berbeda: delegasi akses. Ia memungkinkan aplikasi pihak ketiga mengakses sumber daya pengguna tanpa menerima kata sandi pengguna. Alurnya melibatkan authorization server, resource server, client, dan resource owner. Dalam Authorization Code flow, pengguna diarahkan ke penyedia identitas, menyetujui scope, lalu client menukar kode dengan access token. Failure mode yang paling sering berbahaya adalah redirect URI longgar. Bila authorization server mengizinkan wildcard atau tidak mencocokkan URI secara ketat, penyerang dapat membelokkan authorization code ke alamatnya. State parameter juga wajib untuk mencegah CSRF. Token tidak boleh dikirim melalui URL karena bisa tercatat di log server, riwayat peramban, atau referrer header. OpenID Connect menambahkan lapisan autentikasi di atas OAuth 2.0 melalui ID token. Jika pertanyaannya “siapa pengguna ini”, bukan sekadar “akses apa yang diberikan”, OIDC menjadi standar yang tepat untuk SSO, Google Sign-In, Azure AD, Okta, atau Auth0.
Untuk kebutuhan paling ketat, mutual TLS menawarkan autentikasi berbasis sertifikat di level transport. Dalam TLS biasa, klien memverifikasi server. Dalam mTLS, server juga memverifikasi sertifikat klien. Tidak ada bearer token yang mudah disalin; identitas dibuktikan melalui sertifikat yang diterbitkan CA tepercaya. Cocok untuk perbankan, payment gateway, microservices teregulasi. Namun, mTLS menuntut kapasitas operasional tinggi: sertifikat kedaluwarsa, rotasi harus otomatis, CA harus dilindungi. Salah kelola PKI dapat memutus layanan atau meruntuhkan kepercayaan. Pada akhirnya, pemilihan mekanisme harus berbasis siapa pemanggilnya, sensitivitas data, tuntutan kepatuhan, bukan kebiasaan proyek sebelumnya. Aplikasi pengguna cocok memakai bearer token/JWT berumur pendek. Delegasi pihak ketiga memakai OAuth 2.0. Identitas federatif memakai OIDC. Server-to-server risiko rendah memakai API key ketat. Sistem teregulasi memakai mTLS. Di atas semua itu, disiplin organisasi menentukan hasil: rotasi kunci terjadwal, secret manager wajib, standar algoritma terpusat, paket kriptografi internal, logging terstruktur dengan masking field sensitif. Autentikasi yang benar bukan sekadar bekerja saat demo. Ia harus tetap bertahan saat diserang.