शुरू करें
इंटीग्रेट करें / SDK
उपयोगकर्ता सत्यापन
व्यवसाय सत्यापन
लेन-देन निगरानी
चेंजलॉगयह कैसे काम करता है
हर एप्लिकेशन को अपना साइन-इन ओरिजिन और अपना token इश्यूअर मिलता है। लाइव और सैंडबॉक्स एप्लिकेशन अलग-अलग होते हैं: उनके ओरिजिन, सेटिंग्स और पहचान अलग होती हैं।
फ़्लो OAuth 2.0 ऑथराइज़ेशन कोड है, जिसमें PKCE (केवल
S256) का उपयोग होता है:
- आपका एप्लिकेशन
redirect_uri,state,code_challengeऔरcode_challenge_method=S256के साथ{origin}/sign-inखोलता है। - होस्टेड पेज उन तरीकों से व्यक्ति को साइन-इन या साइन-अप कराता है जो आपने चालू किए हैं, जिसमें कोई आवश्यक दूसरा कारक भी शामिल है।
- ब्राउज़र
codeऔरstateके साथ आपकेredirect_uriपर लौटता है। - आपका एप्लिकेशन
POST {origin}/token/पर कोड को एक्सेस टोकन, ID टोकन और रीफ़्रेश टोकन के लिए बदलता है।
अपना प्लेटफ़ॉर्म चुनें
JavaScript
होस्टेड साइन-इन, कॉलबैक, सत्र और लॉगआउट।
React
क्लाइंट स्टेट और सुरक्षित एप्लिकेशन व्यू।
Next.js
सर्वर सत्र, कॉलबैक रूट और कुकीज़।
iOS
सिस्टम ब्राउज़र और सुरक्षित token स्टोरेज।
Android
ब्राउज़र प्राधिकरण और ऐप कॉलबैक।
React Native
नेटिव प्रमाणीकरण रैपर की तैयारी।
Flutter
नेटिव प्रमाणीकरण रैपर की तैयारी।
अपने एप्लिकेशन की तैयारी करें
- Didit से कहें कि आपके एप्लिकेशन के लिए Authentication चालू करे। पहले सैंडबॉक्स एप्लिकेशन में परीक्षण करें।
- अपने सटीक रीडायरेक्ट URL (अधिकतम 50) और ब्राउज़र
allowed_origins(अधिकतम 50) पंजीकृत करें, जिनसे रनटाइम API को कॉल किया जाता है। - वे साइन-इन विधियाँ चालू करें जो आप देना चाहते हैं। Didit ID Wallet हमेशा चालू रहता है।
- अपनी सत्र और पासवर्ड सेटिंग्स चुनें (नीचे देखें)।
- लाइव जाने से पहले साइन-अप, साइन-इन, पासवर्ड भूल जाने की प्रक्रिया, MFA, सत्र समाप्ति और लॉगआउट का परीक्षण करें।
रीडायरेक्ट URL
Didit किसी व्यक्ति को केवल उसी पते पर लौटाता है जिसे आपने पंजीकृत किया है। इसे कंसोल में Authentication > Security and sessions > Redirect URLs and allowed origins के अंतर्गत पंजीकृत करें। साइन-इन अनुरोध मेंredirect_uri को पंजीकृत URL से अक्षर-दर-अक्षर मेल खाना चाहिए: स्कीम, होस्ट, पोर्ट, पाथ और क्वेरी। अलग पोर्ट, अंत में स्लैश, या अक्षरों का अलग केस, ये सब अलग पते माने जाते हैं।
वाइल्डकार्ड, फ़्रैगमेंट, URL में क्रेडेंशियल और कस्टम स्कीम अस्वीकार किए जाते हैं।
जब कोई पता पंजीकृत नहीं होता, तब Didit कभी उस पर रीडायरेक्ट नहीं करता।
{origin}/sign-in 400 रिस्पॉन्स के साथ ऐसा पेज लौटाता है जो बताता है कि क्या और कहाँ पंजीकृत करना है, और POST {origin}/authorize/ 400 {"error": "invalid_redirect_uri"} लौटाता है।
लोकल डेवलपमेंट
अपनी मशीन पर अपने सैंडबॉक्स एप्लिकेशन के साथ परीक्षण करें:- अपना कॉलबैक उसके पोर्ट के साथ पंजीकृत करें, उदाहरण के लिए
http://localhost:3000/auth/callback। - यदि ब्राउज़र कोड रनटाइम API को कॉल करता है, उदाहरण के लिए
POST {origin}/token/पर कोड बदलने के लिए, तो ओरिजिन को अनुमत स्रोत में भी जोड़ें:http://localhost:3000, बिना पाथ और बिना अंत के स्लैश के। - अपने
pk_test_...key के साथ, अपने सैंडबॉक्स ओरिजिनhttps://<slug>.sandbox.auth.didit.meपर साइन-इन शुरू करें।
localhost, 127.0.0.1 और [::1] अलग-अलग पते हैं, और हर पोर्ट भी अलग है।
आप जितने भी पते उपयोग करते हैं, उन्हें अलग-अलग पंजीकृत करें।
लाइव एप्लिकेशन कभी http:// स्वीकार नहीं करते।
लाइव जाने से पहले, अपने लाइव एप्लिकेशन पर अपना प्रोडक्शन https:// कॉलबैक पंजीकृत करें।
एप्लिकेशन सेटिंग्स
आप ये सेटिंग्स कंसोल में, याwrite:authentication वाले अधिकृत कंसोल सत्र से प्रबंधित करते हैं।
उत्पादों में एक ही व्यक्ति को बनाए रखें
हर पहचान के साथ एकvendor_data मान जुड़ा होता है। यह वह external_id है जो आपने व्यक्ति को आयात करते समय दिया था, अन्यथा Didit पहचान ID। यह एक्सेस token, ID token और GET session/ में दिखाई देता है।
सत्यापन सत्र बनाते समय और लेन-देन सबमिट करते समय वही मान vendor_data के रूप में उपयोग करें। इससे प्रमाणीकरण इवेंट कंसोल में उसी व्यक्ति के साथ दिखेंगे जिसके साथ उसके सत्यापन और लेन-देन दर्ज हैं। देखें इवेंट और webhook।
vendor_data को अपने बैकएंड पर सत्यापित टोकन से निकालें, कभी भी बिना जाँचे गए ब्राउज़र फ़ील्ड से नहीं।
किसी भी संयोजन के लिए साझा इंटीग्रेशन प्रॉम्प्ट का उपयोग करें। साइन इन के समय लागू होने वाली नीतियों के लिए बॉट सुरक्षा पढ़ें।