Pembatasan Laju API untuk Verifikasi Identitas yang Aman

Sebagai pengembang, kami memahami pentingnya proses verifikasi identitas yang kuat dan aman. Aspek penting yang sering terlewatkan adalah pembatasan laju API. Tanpa itu, sistem Anda rentan terhadap penyalahgunaan, serangan penolakan layanan (denial-of-service), dan biaya tak terduga. Panduan ini memberikan tinjauan mendalam tentang pembatasan laju API, khususnya dalam konteks verifikasi identitas, dan cara menerapkannya secara efektif. Kami juga akan mengeksplorasi bagaimana Didit mengatasi masalah ini.

Poin Utama 1 Pembatasan laju melindungi API dan infrastruktur Anda dari serangan berbahaya dan penggunaan berlebihan.

Poin Utama 2 Pembatasan laju yang efektif meningkatkan pengalaman pengembang dengan memberikan kinerja yang dapat diprediksi dan penanganan kesalahan.

Poin Utama 3 Memilih strategi pembatasan laju yang tepat (token bucket, jendela tetap, jendela geser) bergantung pada kebutuhan dan pola lalu lintas spesifik Anda.

Poin Utama 4 Respons kesalahan yang tepat (HTTP 429 Too Many Requests) sangat penting untuk komunikasi yang jelas dengan pengembang.

Mengapa Pembatasan Laju API Penting untuk Verifikasi Identitas

API verifikasi identitas menangani data sensitif dan merupakan target utama penyalahgunaan. Aktor jahat mungkin mencoba:

• Serangan brute-force: Berulang kali mencoba memverifikasi identitas dengan kredensial yang berbeda.
• Serangan penolakan layanan (DoS): Membanjiri API dengan permintaan, membuatnya tidak tersedia bagi pengguna yang sah.
• Credential stuffing: Menggunakan kredensial curian untuk mencoba verifikasi.
• Data scraping: Mencoba mengekstrak sejumlah besar data dari API.

Tanpa pembatasan laju API, serangan ini dapat mengganggu kinerja sistem Anda, keamanan, dan bahkan menyebabkan kerugian finansial. Selain itu, lonjakan lalu lintas yang tidak terduga (misalnya, selama kampanye pemasaran) juga dapat membebani sumber daya Anda jika tidak dikelola dengan baik.

Strategi Pembatasan Laju: Ikhtisar Pengembang

Beberapa strategi dapat digunakan untuk pembatasan laju API, masing-masing dengan kelebihan dan kekurangannya:

1. Token Bucket

Bayangkan sebuah ember yang menampung token. Setiap permintaan menghabiskan satu token. Token diisi ulang dengan kecepatan tetap. Setelah ember kosong, permintaan ditolak sampai token tersedia. Algoritma ini memberikan pembatasan laju yang lancar dan dapat menangani lonjakan lalu lintas.

2. Jendela Tetap

Membagi waktu menjadi jendela ukuran tetap (misalnya, 1 menit). Setiap permintaan menambah penghitung dalam jendela. Setelah penghitung mencapai batas yang telah ditentukan, permintaan ditolak sampai jendela direset. Sederhana untuk diterapkan tetapi dapat mengalami lalu lintas lonjakan di batas jendela.

3. Jendela Geser

Peningkatan dari jendela tetap, pendekatan ini mempertimbangkan permintaan selama jendela waktu geser. Ini memberikan pembatasan laju yang lebih akurat tetapi lebih kompleks untuk diterapkan.

4. Ember Bocor

Mirip dengan ember token, tetapi permintaan diproses dengan kecepatan konstan, terlepas dari kedatangan. Ini efektif untuk menghaluskan lalu lintas tetapi dapat menimbulkan latensi.

Pilihan strategi tergantung pada persyaratan spesifik Anda. Untuk verifikasi identitas, algoritma ember token seringkali lebih disukai karena kemampuannya menangani lonjakan tanpa mengorbankan keadilan.

Menerapkan Pembatasan Laju: Pertimbangan Utama

Saat menerapkan pembatasan laju API, pertimbangkan hal berikut:

• Granularitas: Batasi laju berdasarkan pengguna, alamat IP, kunci API, atau kombinasi. Batasan laju khusus pengguna sangat penting untuk mencegah penyalahgunaan.
• Tingkat Batas Laju: Terapkan batas laju yang berbeda untuk titik akhir API yang berbeda. Titik akhir yang lebih sensitif (misalnya, verifikasi KYC) harus memiliki batasan yang lebih ketat.
• Respons Kesalahan: Kembalikan pesan kesalahan yang informatif (HTTP 429 Too Many Requests) dengan detail tentang batas laju dan kapan permintaan dapat dicoba kembali. Sertakan header seperti Retry-After.
• Pemantauan dan Pemberitahuan: Lacak penggunaan batas laju dan siapkan pemberitahuan untuk memberi tahu Anda tentang potensi penyalahgunaan atau pola lalu lintas yang tidak terduga.
• Penyesuaian Dinamis: Pertimbangkan untuk menyesuaikan batas laju secara dinamis berdasarkan beban sistem dan pola lalu lintas.

Contoh respons kesalahan (JSON):

{
  "error": "Terlalu Banyak Permintaan",
  "message": "Anda telah melampaui batas laju Anda. Silakan coba lagi setelah 60 detik.",
  "retry_after": 60
}

Bagaimana Didit Menangani Pembatasan Laju API

Di Didit, kami memprioritaskan keamanan dan keandalan API verifikasi identitas kami. Kami menggunakan pendekatan berlapis untuk pembatasan laju API:

• Algoritma Ember Token: Kami menggunakan algoritma ember token dengan batas laju granular berdasarkan kunci API dan pengguna.
• Batas Khusus Titik Akhir: Titik akhir yang berbeda memiliki batas laju yang berbeda, dengan operasi yang lebih sensitif (misalnya, penyaringan AML) memiliki batasan yang lebih ketat.
• Pembatasan Laju Dinamis: Sistem kami secara dinamis menyesuaikan batas laju berdasarkan pola lalu lintas dan beban sistem waktu nyata.
• Respons Kesalahan yang Kuat: Kami memberikan pesan kesalahan (HTTP 429) yang jelas dan informatif dengan header Retry-After.
• Pemantauan & Pemberitahuan: Kami terus memantau penggunaan batas laju dan memiliki peringatan otomatis untuk mendeteksi dan menanggapi potensi penyalahgunaan.

Batas Laju Default Didit (contoh):

| Titik Akhir | Batas Laju (Permintaan/Menit) | Tingkat Pengguna | Tingkat Kunci API | |---|---|---|---| | /id/verify | 60 | 200 | 1000 | | /aml/screen | 30 | 100 | 500 | | /liveness/check | 120 | 400 | 2000 |

Batas ini dapat berubah dan dapat disesuaikan untuk klien perusahaan.

Siap Memulai?

Lindungi sistem verifikasi identitas Anda dengan pembatasan laju API yang kuat. Jelajahi platform Didit hari ini untuk merasakan solusi identitas yang aman, andal, dan terukur.

Lihat Harga | Baca Dokumentasi | Minta Demo

FAQ

Apa yang terjadi jika saya melebihi batas laju?

Anda akan menerima respons kesalahan HTTP 429 Too Many Requests. Respons akan menyertakan header Retry-After yang menunjukkan berapa lama untuk menunggu sebelum mencoba kembali permintaan Anda.

Bisakah saya meminta batas laju yang lebih tinggi?

Ya, klien perusahaan dapat meminta batas laju yang lebih tinggi berdasarkan kebutuhan spesifik mereka. Hubungi tim penjualan kami untuk membahas persyaratan Anda.

Apa praktik terbaik untuk menangani kesalahan batas laju di aplikasi saya?

Terapkan backoff eksponensial dengan jitter. Ini berarti menunggu waktu yang semakin lama sebelum mencoba kembali, dengan elemen acak untuk menghindari membanjiri API.

Apakah Didit menawarkan alat apa pun untuk membantu saya memantau penggunaan API saya?

Ya, Konsol Didit menyediakan analitik terperinci tentang penggunaan API, termasuk konsumsi batas laju. Anda juga dapat menyiapkan peringatan untuk memberi tahu Anda tentang potensi masalah.