Otentikasi Biometrik untuk Akses API AI: Mengikat Hak Istimewa ke Individu (ID)

Verifikasi saat orientasi membuktikan siapa yang membuat akun. Ini tidak membuktikan siapa yang menggunakannya sekarang.

Kesenjangan itu biasa terjadi di sebagian besar produk dan konsekuensial pada platform AI, di mana aset di balik akun adalah akses model, kredit, dan kuota. Kunci API adalah token pembawa — siapa pun yang memegangnya adalah akun tersebut. Kunci dibagikan di dalam tim, ditempelkan ke repositori, dijual, dan diambil alih. Enam bulan setelah orientasi yang bersih, "akun ini telah diverifikasi" adalah pernyataan tentang masa lalu.

Otentikasi biometrik menutup kesenjangan itu. Ini memverifikasi ulang manusia yang sebenarnya pada saat tindakan istimewa — tanpa dokumen, tanpa kata sandi, kurang dari dua detik, $0,10 per autentikasi.

Poin-poin penting

• Verifikasi orientasi adalah snapshot. Otentikasi biometrik adalah pemeriksaan pada saat yang penting.
• Liveness ditambah pencocokan wajah terhadap potret yang sudah tersimpan dari verifikasi asli pengguna. Tanpa dokumen, tanpa kata sandi.
• Hanya sesi. Tidak ada endpoint /v3/biometric-auth/ — ini berjalan melalui sesi dengan workflow_type=BIOMETRIC_AUTHENTICATION.
• Detail implementasi yang krusial: gunakan vendor_data yang sama dengan verifikasi asli pengguna, atau wajah yang tersimpan tidak dapat diambil.
• Pemicu yang tepat: peningkatan kuota, pemberian kredit, penerbitan kunci API baru, peningkatan tingkat, penambahan anggota tim yang memiliki hak istimewa, dan peringatan perilaku apa pun dari lapisan lalu lintas Anda.
• $0,10 per autentikasi, bayar-per-berhasil, kurang dari dua detik.

Mengapa re-autentikasi diperlukan pada platform AI

Tiga mode kegagalan membuat snapshot orientasi tidak memadai.

Berbagi dan penjualan kembali kunci. Kunci yang dikeluarkan untuk pengembang yang terverifikasi dapat berakhir di mana saja. Akun tetap terverifikasi; orang yang menggunakannya bukanlah orang yang memverifikasi. Ini adalah mekanisme di mana akun yang terverifikasi secara sah menjadi titik masuk ke jaringan yang dibudidayakan — dan tidak terlihat oleh kontrol apa pun yang hanya melihat orientasi.

Pengambilalihan akun. Kredensial di-phishing atau diisi, dan penyerang mewarisi akun terverifikasi dengan reputasi yang mapan dan batas yang ditingkatkan. Akun terverifikasi adalah target pengambilalihan yang lebih menarik, bukan yang kurang menarik.

Eskalasi setelah fakta. Akun yang diverifikasi untuk akses sederhana pada bulan Januari meminta peningkatan kuota 50× pada bulan Agustus. Tidak ada yang terkait dengan verifikasi Januari yang berbicara tentang permintaan Agustus.

Dalam ketiga kasus tersebut, status verifikasi akun tidak berubah dan manusia di baliknya bukanlah yang Anda kira. Kata sandi, kode satu kali, atau token sesi tidak dapat membedakan kasus-kasus ini, karena setiap kasus adalah penyerang yang secara sah memegang kredensial. Hanya pemeriksaan biometrik yang mengajukan pertanyaan yang penting: apakah orang yang ada di sini saat ini adalah orang yang memverifikasi?

Cara kerjanya

Otentikasi Biometrik menggunakan kembali komponen LivenessV3 dan FaceMatchV3 yang sama dengan alur identitas reguler. Satu-satunya perbedaan adalah dari mana gambar referensi berasal — alih-alih potret pada dokumen yang baru saja diserahkan, ini menggunakan potret yang sudah tersimpan dari verifikasi sebelumnya pengguna.

Itulah mengapa tidak memerlukan dokumen, dan mengapa cukup cepat dan murah untuk ditempatkan dalam alur produk normal.

Hanya sesi

Tidak ada endpoint /v3/biometric-auth/ khusus. Otentikasi disampaikan melalui sesi yang alurnya dikonfigurasi untuk itu — workflow_type=BIOMETRIC_AUTHENTICATION. Jika Anda mencari endpoint mandiri dalam referensi API, inilah alasannya Anda tidak dapat menemukannya.

Alurnya

1. Konfigurasikan alur kerja tipe BIOMETRIC_AUTHENTICATION di konsol dan catat workflow_id-nya.
2. Buat sesi:

curl -X POST 'https://verification.didit.me/v3/session/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "workflow_id": "YOUR_BIOMETRIC_AUTH_WORKFLOW_ID",
    "vendor_data": "acct_8842",
    "callback": "https://yourplatform.example/auth/complete"
  }'

1. Kirim pengguna melalui sesi yang dikembalikan — di-hosting, atau disematkan dengan salah satu SDK gratis.
2. Ambil keputusan:

curl -X GET 'https://verification.didit.me/v3/session/{sessionId}/decision/' \
  -H 'x-api-key: YOUR_API_KEY'

Atau berlangganan session.status.updated dan ambil webhook.

Satu detail yang merusak integrasi

Gunakan vendor_data yang sama dengan verifikasi asli pengguna.

Nilai itu adalah cara Didit mengambil potret yang tersimpan untuk dicocokkan. vendor_data yang baru atau berbeda berarti tidak ada wajah yang tersimpan untuk dibandingkan, dan alur tidak dapat melakukan apa yang Anda minta. Jika Anda perlu menimpa referensi yang tersimpan secara sengaja, berikan portrait_image secara eksplisit — tetapi jalur normal adalah vendor_data yang stabil per akun, diatur saat orientasi dan digunakan kembali selamanya.

Ini adalah argumen untuk memperlakukan vendor_data sebagai pengidentifikasi kelas satu dalam skema Anda sendiri sejak hari pertama. Ini juga yang membuat hasil Pencarian Wajah memetakan dengan jelas ke akun Anda.

Membaca hasilnya

Hasil tiba di liveness_checks dan face_matches. Keduanya selalu berupa array — tidak pernah objek tunggal — dan setiap item membawa node_id sehingga alur kerja multi-instans dapat membedakan langkah-langkah. Masing-masing adalah null sampai langkahnya menghasilkan data.

Peringatan termasuk LOW_LIVENESS_SCORE, peringatan serangan wajah, pencocokan daftar hitam, dan kesamaan pencocokan wajah yang rendah. Ambang batas dan tindakan penolakan dapat dikonfigurasi, sehingga Anda dapat menjalankan standar yang lebih ketat untuk pemberian kredit besar daripada untuk peningkatan kuota rutin.

Apa yang harus memicu peningkatan

Nilai kontrol ini hampir seluruhnya bergantung pada desain pemicu. Terlalu banyak dan Anda telah membangun gangguan; terlalu sedikit dan itu tidak pernah berfungsi saat dibutuhkan.

Eskalasi akses — peningkatan kuota, pemberian kredit, penerbitan kunci API baru, peningkatan tingkat, pindah ke tingkat kemampuan yang Anda anggap sensitif.

Perubahan akun — anggota tim baru yang memiliki hak istimewa, perubahan pemilik penagihan, perubahan tujuan pembayaran, pengaturan ulang kata sandi atau MFA.

Peringatan perilaku — pemicu nilai tertinggi. Ketika lapisan lalu lintas Anda sendiri menandai akun untuk kueri terpusat atau pola berbentuk distilasi, peningkatan biometrik mengajukan satu pertanyaan yang tidak dapat dijawab oleh lapisan lalu lintas: apakah manusia yang terverifikasi masih yang mengoperasikan akun ini? Kelulusan mempersempit interpretasi. Kegagalan atau pengabaian itu sendiri merupakan sinyal yang kuat.

Sinyal penghubung — sesi yang membawa DEVICE_RECOVERED_HIGH_CONFIDENCE, atau wajah yang cocok dengan pengguna terverifikasi yang ada, telah mendapatkan peningkatan terlepas dari apa yang diminta akun tersebut.

Dormansi ditambah eskalasi — akun yang tenang selama berbulan-bulan yang tiba-tiba meminta peningkatan besar. Bukan dormansi saja; kombinasinya.

Mengapa tidak hanya memerlukan kata sandi atau kode?

Karena setiap faktor konvensional adalah kredensial pembawa, dan model ancaman di sini adalah penyerang yang memegang kredensial.

Kode satu kali masuk ke nomor telepon atau alamat yang terdaftar — yang dikendalikan penyerang setelah pengambilalihan, dan yang hanya diteruskan oleh pembagi kunci yang sah. Kata sandi membuktikan pengetahuan tentang string. Kunci perangkat keras membuktikan kepemilikan objek, yang dapat diserahkan bersama kunci.

Pencocokan wajah yang diperiksa liveness membuktikan bahwa manusia tertentu hadir pada saat ini. Untuk mengikat hak istimewa ke seseorang, itu adalah satu-satunya faktor yang menjawab pertanyaan sebenarnya. Dengan harga $0,10 dan kurang dari dua detik, ini juga cukup murah untuk digunakan pada pemicu nyata daripada menyimpannya untuk keadaan darurat.

Apa yang tidak dilakukannya juga patut disebutkan. Re-autentikasi manusia di balik akun tidak mencegah ekstraksi model dan tidak mendeteksinya. Pengembang yang terverifikasi masih dapat menyalahgunakan akses yang mereka miliki. Ini menutup kesenjangan antara "akun ini pernah diverifikasi" dan "manusia ini ada di sini sekarang" — kesenjangan yang sempit dan nyata. Kontrol output tingkat model dan deteksi lalu lintas semantik tetap merupakan lapisan terpisah, dan itu tetap menjadi milik Anda.

Kasus penggunaan

Platform API AI yang membatasi eskalasi kuota, pemberian kredit, dan penerbitan kunci di balik pemeriksaan pada manusia.

Produk agen dan otomatisasi yang memerlukan peningkatan sebelum agen diberikan kemampuan baru atau batas pengeluaran dinaikkan.

Layanan keuangan re-autentikasi sebelum transfer bernilai tinggi atau perubahan tujuan pembayaran.

Pasar memverifikasi ulang penjual sebelum perubahan metode pembayaran — pembayaran pengambilalihan akun yang paling umum.

Platform apa pun dengan alur pemulihan menggunakan re-autentikasi biometrik alih-alih pertanyaan berbasis pengetahuan, yang merupakan mata rantai terlemah dalam sebagian besar desain keamanan akun.

Pertanyaan yang Sering Diajukan

Apakah pengguna perlu mengirimkan dokumen lagi?

Tidak. Itulah intinya. Pemeriksaan berjalan terhadap potret yang sudah tersimpan dari verifikasi asli mereka — liveness ditambah pencocokan wajah, tanpa dokumen.

Bagaimana jika pengguna tidak pernah diverifikasi dengan Didit?

Maka tidak ada potret yang tersimpan dan tidak ada yang dapat diautentikasi. Otentikasi Biometrik adalah primitif verifikasi ulang; ini mengandaikan verifikasi sebelumnya di bawah vendor_data yang sama.

Berapa lama waktu yang dibutuhkan?

Inferensi kurang dari dua detik. Dari sudut pandang pengguna, itu adalah selfie dan sejenak.

Bisakah itu berjalan di dalam antarmuka kami sendiri?

Ya. SDK web, iOS, Android, React Native, dan Flutter semuanya gratis, dan White Label ($0,20) menghapus branding Didit.

Bagaimana jika seseorang memegang foto atau video pemilik akun?

Itulah gunanya deteksi liveness. Liveness pasif Didit memiliki evaluasi deteksi serangan presentasi iBeta Level 1, dan peringatan serangan wajah muncul dalam peringatan. Ambang batas dapat dikonfigurasi.

Berapa biayanya?

$0,10 per autentikasi, bayar-per-berhasil, tanpa minimum.

Haruskah setiap login memerlukan ini?

Tidak. Login adalah pemicu yang salah — itu sering terjadi dan sebagian besar tidak ada apa-apanya. Lampirkan ke eskalasi hak istimewa dan ke peringatan, di mana biaya kesalahan tinggi dan frekuensinya rendah.

Siap untuk memulai?

Konfigurasikan satu alur kerja, hubungkan ke titik eskalasi Anda, dan gunakan kembali di mana saja.

• Baca dokumen — Ikhtisar Otentikasi Biometrik dan API Sesi.
• Lihat produknya — Verifikasi Pengguna.
• Periksa harga — $0,10 per autentikasi, bayar-per-berhasil, tanpa minimum.
• Mulai gratis — business.didit.me, 500 verifikasi KYC per bulan tanpa biaya.