Pembatasan Laju API untuk Verifikasi Identitas

Seiring dengan semakin banyaknya bisnis yang bergantung pada verifikasi identitas digital (IDV) untuk mendaftarkan pengguna, mencegah penipuan, dan menjaga kepatuhan, keamanan dan kinerja API IDV mereka menjadi sangat penting. Komponen penting dari sistem IDV yang kuat adalah penerapan pembatasan laju API yang efektif. Artikel ini membahas pentingnya pembatasan laju, praktik terbaik untuk implementasi, dan bagaimana Didit menerapkan pembatasan laju untuk menyediakan layanan yang aman dan andal.

Poin Utama 1 Pembatasan laju melindungi API IDV Anda dari penyalahgunaan, memastikan ketersediaan layanan bagi pengguna yang sah.

Poin Utama 2 Pembatasan laju yang efektif melibatkan pemilihan algoritma yang tepat, pengaturan batasan yang sesuai, dan penyediaan respons kesalahan yang informatif.

Poin Utama 3 Didit menggunakan sistem pembatasan laju yang canggih yang menyeimbangkan keamanan, keadilan, dan pengalaman pengembang.

Poin Utama 4 Pembatasan laju yang dirancang dengan baik adalah aspek kunci dari keamanan API dan ketahanan sistem secara keseluruhan.

Mengapa Pembatasan Laju API Penting untuk Verifikasi Identitas

API verifikasi identitas adalah target utama bagi pelaku jahat. Serangan brute-force, credential stuffing, dan upaya denial-of-service (DoS) dapat membebani sistem, menyebabkan gangguan layanan dan potensi pelanggaran keamanan. Pembatasan laju API bertindak sebagai mekanisme pertahanan, membatasi jumlah permintaan yang dapat dibuat klien dalam jangka waktu tertentu. Hal ini melindungi API dari kelebihan beban, memastikan ketersediaan bagi pengguna yang sah dan mencegah penyalahgunaan. Tanpa pembatasan laju API, penyerang berpotensi mengirimkan ribuan dokumen ID dalam waktu singkat, menyebabkan tekanan signifikan pada sumber daya dan berpotensi mengkompromikan sistem.

Algoritma dan Strategi Pembatasan Laju

Beberapa algoritma dapat digunakan untuk menerapkan pembatasan laju API. Berikut adalah beberapa pendekatan umum:

• Token Bucket: Sebuah ember virtual menyimpan token, mewakili alokasi permintaan. Setiap permintaan mengkonsumsi sebuah token. Token diisi ulang dengan kecepatan tetap. Ini memungkinkan semburan lalu lintas sambil mempertahankan laju rata-rata.
• Leaky Bucket: Mirip dengan token bucket, tetapi permintaan diproses dengan kecepatan tetap, dan permintaan yang melebihi dibuang.
• Fixed Window Counter: Menghitung permintaan dalam jendela waktu tetap (misalnya, 60 detik). Setelah batas tercapai, permintaan lebih lanjut diblokir hingga jendela berikutnya.
• Sliding Window Log: Memelihara log permintaan terbaru. Batas laju dihitung berdasarkan permintaan dalam jendela geser. Ini memberikan pembatasan laju yang lebih akurat daripada jendela tetap tetapi membutuhkan lebih banyak sumber daya.
• Sliding Window Counter: Pendekatan hibrida yang menggabungkan fixed window counter dengan sliding window log, menawarkan keseimbangan antara akurasi dan kinerja.

Memilih algoritma yang tepat bergantung pada persyaratan spesifik, seperti akurasi, kinerja, dan kompleksitas yang diinginkan. Untuk API IDV, kombinasi algoritma sering digunakan untuk memberikan perlindungan berlapis.

Merancang Batas Laju yang Efektif untuk API IDV

Menetapkan batas laju yang sesuai sangat penting. Batas yang terlalu ketat dapat membuat frustrasi pengguna yang sah, sementara batas yang terlalu longgar mungkin tidak memberikan perlindungan yang memadai. Berikut adalah beberapa pertimbangan:

• Batas Laju Bertingkat: Tingkat yang berbeda berdasarkan paket berlangganan atau penggunaan klien. Klien tingkat lebih tinggi dapat memiliki batas yang lebih tinggi.
• Batas Spesifik Endpoint API: Endpoint yang berbeda mungkin memiliki batas yang berbeda berdasarkan intensitas sumber dayanya. Misalnya, endpoint verifikasi dokumen ID mungkin memiliki batas yang lebih rendah daripada endpoint pencarian data sederhana.
• Batas Berbasis Klien: Batas berdasarkan kunci API atau alamat IP klien.
• Batas Laju Dinamis: Menyesuaikan batas secara dinamis berdasarkan beban sistem atau anomali yang terdeteksi.

Sebagai contoh, Didit menerapkan batas laju bertingkat berdasarkan tingkat berlangganan. Paket dasar mungkin mengizinkan 100 permintaan per menit, sedangkan paket perusahaan dapat mengizinkan 1000 permintaan per menit. Selain itu, endpoint verifikasi identitas, karena lebih intensif sumber daya, memiliki batas yang lebih rendah daripada endpoint penyaringan AML.

Bagaimana Didit Menangani Pembatasan Laju API

Didit menggunakan strategi pembatasan laju API berlapis:

• Algoritma Token Bucket: Digunakan sebagai mekanisme pembatasan laju inti.
• Batas Bertingkat: Paket yang berbeda memiliki batas laju yang berbeda.
• Batas Spesifik Endpoint: Setiap endpoint API memiliki batas laju yang dikonfigurasi sendiri.
• Batas Berbasis IP: Batas tambahan berdasarkan alamat IP asal.
• Pemantauan dan Penyesuaian Real-time: Beban sistem terus dipantau, dan batas disesuaikan secara dinamis jika diperlukan.

Ketika batas laju terlampaui, Didit mengembalikan kesalahan 429 Too Many Requests dengan header informatif, termasuk permintaan yang tersisa dan waktu reset. Contoh:

HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1678886400

Ini memungkinkan pengembang untuk menangani pembatasan laju dengan baik dan menerapkan logika coba lagi. API Didit juga menyediakan endpoint khusus untuk memeriksa status batas laju saat ini.

Praktik Terbaik untuk Integrasi dengan API yang Dibatasi Laju

• Implementasikan Logika Coba Lagi: Ketika kesalahan 429 diterima, implementasikan backoff eksponensial dengan jitter untuk menghindari membebani API.
• Cache Respons: Cache data yang sering diakses untuk mengurangi jumlah panggilan API.
• Optimalkan Penggunaan API: Gabungkan permintaan jika memungkinkan untuk mengurangi jumlah panggilan secara keseluruhan.
• Pantau Penggunaan API: Lacak penggunaan API untuk mengidentifikasi potensi hambatan dan mengoptimalkan integrasi.
• Hormati Header Batas Laju: Perhatikan header batas laju yang dikembalikan oleh API untuk menghindari melebihi batas.

Siap Memulai?

Lindungi sistem verifikasi identitas Anda dengan pembatasan laju API yang kuat. Platform Didit menyediakan solusi yang aman dan andal dengan pembatasan laju bawaan dan dokumentasi komprehensif.

Jelajahi dokumentasi API kami dan daftar untuk akun gratis untuk merasakan kekuatan platform identitas Didit.

FAQ

Apa yang terjadi ketika saya melebihi batas laju API?

Anda akan menerima kesalahan 429 Too Many Requests. Header respons akan menyertakan informasi tentang batas laju, permintaan yang tersisa, dan waktu reset. Implementasikan logika coba lagi dengan backoff eksponensial untuk menangani kesalahan ini dengan baik.

Bisakah saya meminta batas laju yang lebih tinggi?

Ya, Anda dapat menghubungi tim penjualan kami untuk membahas peningkatan paket berlangganan Anda untuk batas laju yang lebih tinggi. Kami menawarkan paket bertingkat untuk mengakomodasi kebutuhan penggunaan yang berbeda.

Bagaimana Didit menentukan batas laju yang sesuai?

Batas laju Didit didasarkan pada kombinasi faktor, termasuk tingkat berlangganan, endpoint API, beban sistem, dan pola penggunaan historis. Kami terus memantau dan menyesuaikan batas untuk memastikan kinerja dan keamanan yang optimal.

Apa perbedaan antara algoritma pembatasan laju token bucket dan fixed window?

Token bucket memungkinkan semburan lalu lintas selama masih ada token yang tersedia, sementara fixed window counter secara ketat membatasi jumlah permintaan dalam jendela waktu tetap. Token bucket umumnya lebih fleksibel, sedangkan fixed window counter lebih sederhana untuk diimplementasikan.