AI API एक्सेस के लिए बायोमेट्रिक स्टेप-अप: विशेषाधिकार को व्यक्ति से जोड़ना (HI-1)

ऑनबोर्डिंग पर सत्यापन यह साबित करता है कि किसने खाता बनाया है। यह इस बारे में कुछ भी साबित नहीं करता कि अब इसका उपयोग कौन कर रहा है।

यह अंतर अधिकांश उत्पादों में सामान्य है और एक AI प्लेटफॉर्म पर परिणामी है, जहां खाते के पीछे की संपत्ति मॉडल एक्सेस, क्रेडिट और कोटा हैं। एक एपीआई कुंजी एक वाहक टोकन है — जो भी इसे रखता है वह खाता होता है। कुंजियाँ टीमों के भीतर साझा की जाती हैं, रिपॉजिटरी में पेस्ट की जाती हैं, बेची जाती हैं और अधिग्रहण कर ली जाती हैं। एक स्वच्छ ऑनबोर्डिंग के छह महीने बाद, "यह खाता सत्यापित किया गया था" अतीत के बारे में एक बयान है।

बायोमेट्रिक प्रमाणीकरण उस अंतर को समाप्त करता है। यह एक विशेषाधिकार प्राप्त कार्रवाई के क्षण में वास्तविक व्यक्ति को फिर से सत्यापित करता है — कोई दस्तावेज़ नहीं, कोई पासवर्ड नहीं, दो सेकंड से भी कम समय में, प्रति प्रमाणीकरण $00.10।

मुख्य बातें

• ऑनबोर्डिंग सत्यापन एक स्नैपशॉट है। बायोमेट्रिक प्रमाणीकरण महत्वपूर्ण क्षण में एक जांच है।
• उपयोगकर्ता के मूल सत्यापन से पहले से संग्रहीत पोर्ट्रेट के विरुद्ध जीवंतता और फेस मैच। कोई दस्तावेज़ नहीं, कोई पासवर्ड नहीं।
• केवल सत्र। कोई /v3/biometric-auth/ एंडपॉइंट नहीं है — यह workflow_type=BIOMETRIC_AUTHENTICATION के साथ एक सत्र के माध्यम से चलता है।
• महत्वपूर्ण कार्यान्वयन विवरण: उपयोगकर्ता के मूल सत्यापन के समान vendor_data का उपयोग करें, अन्यथा संग्रहीत चेहरा पुनः प्राप्त नहीं किया जा सकता है।
• सही ट्रिगर: कोटा वृद्धि, क्रेडिट अनुदान, नई एपीआई कुंजी जारी करना, टियर अपग्रेड, विशेषाधिकार प्राप्त टीम के सदस्यों को जोड़ना, और आपकी ट्रैफ़िक परत से कोई भी व्यवहार संबंधी अलर्ट।
• प्रति प्रमाणीकरण $0.10, प्रति-सफलता भुगतान, दो सेकंड से भी कम समय में।

AI प्लेटफॉर्म पर पुनः-प्रमाणीकरण क्यों होना चाहिए

तीन विफलता मोड ऑनबोर्डिंग स्नैपशॉट को अपर्याप्त बनाते हैं।

कुंजी साझाकरण और पुनर्विक्रय। एक सत्यापित डेवलपर को जारी की गई कुंजी कहीं भी समाप्त हो सकती है। खाता सत्यापित रहता है; इसका उपयोग करने वाला व्यक्ति वह व्यक्ति नहीं है जिसने सत्यापित किया है। यह वह तंत्र है जिसके द्वारा एक वैध रूप से सत्यापित खाता एक फार्म किए गए नेटवर्क में प्रवेश बिंदु बन जाता है — और यह किसी भी नियंत्रण के लिए अदृश्य है जो केवल ऑनबोर्डिंग को देखता है।

खाता अधिग्रहण। क्रेडेंशियल फ़िश किए जाते हैं या स्टफ किए जाते हैं, और हमलावर एक स्थापित प्रतिष्ठा और बढ़ी हुई सीमाओं के साथ एक सत्यापित खाते का उत्तराधिकारी बन जाता है। एक सत्यापित खाता एक अधिक आकर्षक अधिग्रहण लक्ष्य है, न कि कम आकर्षक।

तथ्य के बाद वृद्धि। वह खाता जिसने जनवरी में मामूली पहुंच के लिए सत्यापित किया था, अगस्त में 50 गुना कोटा वृद्धि का अनुरोध करता है। जनवरी के सत्यापन के बारे में कुछ भी अगस्त के अनुरोध के बारे में नहीं बताता है।

इन तीनों में, खाते की सत्यापन स्थिति अपरिवर्तित है और इसके पीछे का व्यक्ति वह नहीं है जो आप सोचते हैं। एक पासवर्ड, एक वन-टाइम कोड, या एक सत्र टोकन इन मामलों को अलग नहीं कर सकता है, क्योंकि उनमें से प्रत्येक एक हमलावर है जो वैध रूप से क्रेडेंशियल रखता है। केवल एक बायोमेट्रिक जांच ही उस प्रश्न को पूछती है जो मायने रखता है: क्या अभी यहां मौजूद व्यक्ति वही व्यक्ति है जिसने सत्यापित किया था?

यह कैसे काम करता है

बायोमेट्रिक प्रमाणीकरण नियमित पहचान प्रवाह के समान LivenessV3 और FaceMatchV3 घटकों का पुनः उपयोग करता है। एकमात्र अंतर यह है कि संदर्भ छवि कहां से आती है — एक नए प्रस्तुत दस्तावेज़ पर पोर्ट्रेट के बजाय, यह उपयोगकर्ता के पिछले सत्यापन से पहले से संग्रहीत पोर्ट्रेट का उपयोग करता है।

इसलिए इसे किसी दस्तावेज़ की आवश्यकता नहीं है, और इसलिए यह इतना तेज़ और सस्ता है कि यह एक सामान्य उत्पाद प्रवाह में फिट हो सकता है।

यह केवल सत्र है

कोई समर्पित /v3/biometric-auth/ एंडपॉइंट नहीं है। प्रमाणीकरण एक सत्र के माध्यम से वितरित किया जाता है जिसका वर्कफ़्लो इसके लिए कॉन्फ़िगर किया गया है — workflow_type=BIOMETRIC_AUTHENTICATION। यदि आप एपीआई संदर्भ में एक स्टैंडअलोन एंडपॉइंट की तलाश कर रहे हैं, तो यही कारण है कि आपको कोई नहीं मिल रहा है।

प्रवाह

1. कंसोल में BIOMETRIC_AUTHENTICATION प्रकार का एक वर्कफ़्लो कॉन्फ़िगर करें और इसकी workflow_id नोट करें।
2. एक सत्र बनाएं:

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. उपयोगकर्ता को लौटाए गए सत्र के माध्यम से भेजें — होस्टेड, या किसी भी मुफ्त SDK के साथ एम्बेडेड।
2. निर्णय प्राप्त करें:

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

या session.status.updated की सदस्यता लें और वेबहुक लें।

एक विवरण जो एकीकरण को तोड़ता है

उपयोगकर्ता के मूल सत्यापन के समान vendor_data का उपयोग करें।

वह मान है कि Didit संग्रहीत पोर्ट्रेट को मिलान करने के लिए कैसे पुनः प्राप्त करता है। एक नया या अलग vendor_data का मतलब है कि तुलना करने के लिए कोई संग्रहीत चेहरा नहीं है, और प्रवाह वह नहीं कर सकता जो आपने मांगा था। यदि आपको जानबूझकर संग्रहीत संदर्भ को ओवरराइड करने की आवश्यकता है, तो portrait_image को स्पष्ट रूप से पास करें — लेकिन सामान्य पथ प्रति खाते एक स्थिर vendor_data है, जो ऑनबोर्डिंग पर सेट होता है और हमेशा के लिए पुनः उपयोग किया जाता है।

यह vendor_data को पहले दिन से अपनी योजना में एक प्रथम-श्रेणी पहचानकर्ता के रूप में मानने का तर्क है। यह भी है कि फेस सर्च परिणाम आपके खातों पर सफाई से कैसे मैप होते हैं।

परिणाम पढ़ना

परिणाम liveness_checks और face_matches में आते हैं। दोनों हमेशा ऐरे होते हैं — कभी भी एकवचन वस्तुएं नहीं — और प्रत्येक आइटम में एक node_id होता है ताकि मल्टी-इंस्टेंस वर्कफ़्लो चरणों को अस्पष्ट कर सकें। प्रत्येक null होता है जब तक कि उसका चरण डेटा उत्पन्न नहीं कर देता।

चेतावनी में LOW_LIVENESS_SCORE, फेस-अटैक अलर्ट, ब्लॉकलिस्ट मैच, और कम फेस-मैच समानता शामिल है। थ्रेसहोल्ड और अस्वीकार कार्रवाइयां कॉन्फ़िगर करने योग्य हैं, इसलिए आप एक नियमित कोटा वृद्धि की तुलना में एक बड़े क्रेडिट अनुदान के लिए एक सख्त बार चला सकते हैं।

स्टेप-अप को क्या ट्रिगर करना चाहिए

इस नियंत्रण का मूल्य लगभग पूरी तरह से ट्रिगर डिज़ाइन पर निर्भर करता है। बहुत अधिक और आपने एक उपद्रव का निर्माण किया है; बहुत कम और यह कभी भी तब नहीं चलता जब यह मायने रखता है।

पहुंच वृद्धि — कोटा वृद्धि, क्रेडिट अनुदान, नई एपीआई कुंजी जारी करना, टियर अपग्रेड, एक क्षमता टियर पर जाना जिसे आप संवेदनशील मानते हैं।

खाता परिवर्तन — एक नया विशेषाधिकार प्राप्त टीम का सदस्य, बिलिंग मालिक का परिवर्तन, भुगतान गंतव्य परिवर्तन, पासवर्ड या MFA रीसेट।

व्यवहार संबंधी अलर्ट — उच्चतम-मूल्य ट्रिगर। जब आपकी अपनी ट्रैफ़िक परत केंद्रित क्वेरीिंग या डिस्टिलेशन-आकार के पैटर्न के लिए एक खाते को फ़्लैग करती है, तो एक बायोमेट्रिक स्टेप-अप वह एक प्रश्न पूछता है जो ट्रैफ़िक परत नहीं कर सकती: क्या सत्यापित मानव अभी भी इस खाते का संचालन कर रहा है? एक पास व्याख्या को संकीर्ण करता है। एक विफलता या एक परित्याग स्वयं एक मजबूत संकेत है।

लिंकिंग सिग्नल — DEVICE_RECOVERED_HIGH_CONFIDENCE ले जाने वाला एक सत्र, या एक चेहरा जो मौजूदा सत्यापित उपयोगकर्ता से मेल खाता है, ने खाता क्या मांग रहा है, इसकी परवाह किए बिना एक स्टेप-अप अर्जित किया है।

सुस्ती और वृद्धि — महीनों तक शांत रहने वाला एक खाता जो अचानक एक बड़ी वृद्धि का अनुरोध करता है। केवल सुस्ती नहीं; संयोजन।

केवल एक पासवर्ड या कोड की आवश्यकता क्यों नहीं है?

क्योंकि हर पारंपरिक कारक एक वाहक क्रेडेंशियल है, और यहां खतरे का मॉडल एक हमलावर है जो क्रेडेंशियल रखता है।

एक वन-टाइम कोड फ़ाइल पर फोन नंबर या पते पर जाता है — जिसे हमलावर अधिग्रहण के बाद नियंत्रित करता है, और जिसे वैध कुंजी-साझा करने वाला बस आगे बढ़ाता है। एक पासवर्ड एक स्ट्रिंग के ज्ञान को साबित करता है। एक हार्डवेयर कुंजी एक वस्तु के कब्जे को साबित करती है, जिसे कुंजी के साथ सौंपा जा सकता है।

एक जीवंतता-जांच किया गया फेस मैच साबित करता है कि एक विशिष्ट मानव इस समय मौजूद है। एक व्यक्ति से विशेषाधिकार को जोड़ने के लिए, यह एकमात्र कारक है जो वास्तविक प्रश्न का उत्तर देता है। $0.10 और दो सेकंड से कम समय में, यह वास्तविक ट्रिगर्स पर उपयोग करने के लिए भी पर्याप्त सस्ता है बजाय इसके कि इसे आपात स्थिति के लिए बचाया जाए।

यह क्या नहीं करता है, यह भी बताना उचित है। एक खाते के पीछे के व्यक्ति को पुनः-प्रमाणीकृत करने से मॉडल निष्कर्षण को रोका नहीं जा सकता है और इसका पता नहीं चलता है। एक सत्यापित डेवलपर अभी भी उनके पास मौजूद पहुंच का दुरुपयोग कर सकता है। यह "यह खाता एक बार सत्यापित किया गया था" और "यह मानव अभी यहां है" के बीच के अंतर को समाप्त करता है — एक संकीर्ण, वास्तविक अंतर। मॉडल-स्तर आउटपुट नियंत्रण और सिमेंटिक ट्रैफ़िक डिटेक्शन अलग-अलग परतें रहते हैं, और वे आपके रहते हैं।

उपयोग के मामले

AI API प्लेटफॉर्म कोटा वृद्धि, क्रेडिट अनुदान और कुंजी जारी करने को मानव पर एक जांच के पीछे गेटिंग करते हैं।

एजेंट और ऑटोमेशन उत्पाद एक एजेंट को एक नई क्षमता प्रदान करने या खर्च सीमा बढ़ाने से पहले एक स्टेप-अप की आवश्यकता होती है।

वित्तीय सेवाएं एक उच्च-मूल्य हस्तांतरण या भुगतान-गंतव्य परिवर्तन से पहले पुनः-प्रमाणीकरण करती हैं।

मार्केटप्लेस भुगतान विधि परिवर्तन से पहले एक विक्रेता को पुनः-सत्यापित करते हैं — सबसे आम खाता-अधिग्रहण भुगतान।

किसी भी प्लेटफॉर्म में एक रिकवरी प्रवाह ज्ञान-आधारित प्रश्नों के बजाय बायोमेट्रिक पुनः-प्रमाणीकरण का उपयोग करता है, जो अधिकांश खाता-सुरक्षा डिज़ाइनों में सबसे कमजोर कड़ी हैं।

अक्सर पूछे जाने वाले प्रश्न

क्या उपयोगकर्ता को फिर से एक दस्तावेज़ जमा करना होगा?

नहीं। यही बात है। जांच उनके मूल सत्यापन से पहले से संग्रहीत पोर्ट्रेट के विरुद्ध चलती है — जीवंतता और फेस मैच, कोई दस्तावेज़ नहीं।

क्या होगा यदि उपयोगकर्ता को कभी Didit के साथ सत्यापित नहीं किया गया था?

तब कोई संग्रहीत पोर्ट्रेट नहीं है और प्रमाणित करने के लिए कुछ भी नहीं है। बायोमेट्रिक प्रमाणीकरण एक पुनः-सत्यापन आदिम है; यह उसी vendor_data के तहत पहले के सत्यापन को मानता है।

इसमें कितना समय लगता है?

दो सेकंड से कम समय में अनुमान। उपयोगकर्ता के दृष्टिकोण से यह एक सेल्फी और एक पल है।

क्या यह हमारे अपने इंटरफ़ेस के अंदर चल सकता है?

हाँ। वेब, iOS, Android, React Native और Flutter SDK सभी मुफ्त हैं, और व्हाइट लेबल ($0.20) Didit ब्रांडिंग को हटाता है।

क्या होगा यदि कोई खाताधारक की फोटो या वीडियो दिखाता है?

यही जीवंतता पहचान के लिए है। Didit की निष्क्रिय जीवंतता में iBeta लेवल 1 प्रेजेंटेशन-अटैक-डिटेक्शन मूल्यांकन है, और फेस-अटैक अलर्ट चेतावनियों में सामने आते हैं। थ्रेसहोल्ड कॉन्फ़िगर करने योग्य हैं।

इसकी लागत कितनी है?

प्रति प्रमाणीकरण $0.10, प्रति-सफलता भुगतान, कोई न्यूनतम नहीं।

क्या हर लॉगिन के लिए इसकी आवश्यकता होनी चाहिए?

नहीं। लॉगिन गलत ट्रिगर है — यह लगातार और ज्यादातर कुछ भी नहीं पर चलता है। इसे विशेषाधिकार वृद्धि और अलर्ट से जोड़ें, जहां गलत होने की लागत अधिक है और आवृत्ति कम है।

शुरू करने के लिए तैयार हैं?

एक वर्कफ़्लो कॉन्फ़िगर करें, इसे अपने वृद्धि बिंदुओं से जोड़ें, और इसे हर जगह पुनः उपयोग करें।

• दस्तावेज़ पढ़ें — बायोमेट्रिक प्रमाणीकरण अवलोकन और सत्र एपीआई।
• उत्पाद देखें — उपयोगकर्ता सत्यापन।
• मूल्य निर्धारण की जांच करें — प्रति प्रमाणीकरण $0.10, प्रति-सफलता भुगतान, कोई न्यूनतम नहीं।
• मुफ्त में शुरू करें — business.didit.me, प्रति माह 500 KYC सत्यापन बिना किसी लागत के।