मुख्य सामग्री पर जाएं
प्रमाणीकरण नया है: इस होस्टेड-फ़्लो उदाहरण का उपयोग ऐसे एप्लिकेशन के साथ करें जिसमें प्रमाणीकरण चालू है। @didit-protocol/auth पैकेज अभी प्रकाशित नहीं हुआ है; नीचे दिया गया पैकेज API एक प्रीव्यू है, इंस्टॉल किया जा सकने वाला क्विकस्टार्ट नहीं।

होस्टेड साइन-इन कॉन्फ़िगर करें

अपने सैंडबॉक्स एप्लिकेशन के लिए ठीक वही कॉलबैक URL और अपना वेब origin रजिस्टर करें। कंसोल से इसका साइन-इन origin (https://<slug>.sandbox.auth.didit.me) कॉपी करें, जैसा ओवरव्यू में बताया गया है। यह उदाहरण ब्राउज़र की क्रिप्टोग्राफ़ी APIs का उपयोग करता है और HTTPS आवश्यक है, या सैंडबॉक्स में localhost का उपयोग करें: क्या रजिस्टर करना है, यह जानने के लिए लोकल डेवलपमेंट देखें। state और PKCE verifier का स्वामित्व एप्लिकेशन के पास है। पासवर्ड, ईमेल, पासकी, फ़ोन, SSO और आवश्यक MFA स्क्रीन होस्टेड साइन-इन द्वारा नियंत्रित की जाती हैं। इस कोड में कोई API कुंजी नहीं होनी चाहिए।
auth.js
अपने साइन-इन बटन से signIn() कॉल करें। पंजीकृत कॉलबैक पेज पर handleCallback() को एक बार कॉल करें, एक लोडिंग स्थिति दिखाएँ, और विफल होने पर उसकी त्रुटि दिखाएँ। वर्तमान उपयोगकर्ता के लिए getSession() और लॉगआउट के लिए signOut() उपयोग करें। कॉलबैक अनुरोध करने से पहले अपना code एड्रेस बार से हटा देता है। यह न्यूनतम उदाहरण टोकन मेमोरी में रखता है और पेज रीलोड होने या access token की समय-सीमा समाप्त होने के बाद फिर से साइन इन करवाता है। स्थायी सत्र के लिए, अपने बैकएंड का उपयोग करें और सुरक्षित cookies या सीरियलाइज़्ड refresh rotation लागू करें। Refresh tokens को कभी URLs या logs में न डालें। फ़्रंटएंड सत्र जाँच केवल प्रस्तुति को नियंत्रित करती है; आपके बैकएंड को हर सुरक्षित अनुरोध पर कॉल करने वाले की पुष्टि करनी होगी।

प्रमाणीकरण SDK रिलीज़ प्रीव्यू

प्रस्तावित @didit-protocol/auth कोर createDiditAuth({publishableKey}), signIn(), handleRedirectCallback(), getSession(), getToken(), onAuthStateChange और signOut() उपलब्ध कराता है, और identity में vendorData भी शामिल है। इसका उद्देश्य स्वचालित डिवाइस सिग्नल जोड़ना और verifyToken() के साथ एक सर्वर एंट्री पॉइंट जोड़ना है। Publishable key pk_live_ (लाइव एप्लिकेशन) या pk_test_ (सैंडबॉक्स एप्लिकेशन) होती है, इसके बाद आपके एप्लिकेशन के origin का base64url encoding होता है, बिना padding के। SDK अपने API कॉल उसी origin पर भेजता है। Key सार्वजनिक है: यह एप्लिकेशन की पहचान करती है और कोई secret नहीं है।

प्रीव्यू में Step-up और पुनः प्रमाणीकरण

  • stepUp({ action, amount?, currency?, redirectUri? }) आपके एप्लिकेशन के POST step-up/ को कॉल करता है, यह पूछने के लिए कि क्या action को पहचान जाँच की आवश्यकता है। action payout, bank या contact है, और payout के लिए amount आवश्यक है। जब आपका कोई step-up नियम लागू होता है, तो यह Didit द्वारा लौटाए गए verification पेज पर नेविगेट करता है।
  • handleStepUpCallback(url?) उस पेज पर चलता है जहाँ व्यक्ति वापस आता है। यह ?step_up=<id> पढ़ता है, इसे एड्रेस बार से हटाता है, और GET step-up/{id}/ से परिणाम पढ़ता है।
  • reauthenticate({ method? }) उसी व्यक्ति को होस्टेड पेज पर (method: "redirect", डिफ़ॉल्ट) या पासकी से (method: "passkey", केवल आपके एप्लिकेशन के Didit साइन-इन डोमेन पर) फिर से साइन इन करवाता है। होस्टेड पेज के बाद, इसे handleRedirectCallback() से पूरा करें। यदि कोई दूसरा व्यक्ति इसे पूरा करता है, तो यह step_up_user_mismatch के साथ reject हो जाता है और मूल सत्र बना रहता है।
दोनों step-up methods { id, status, approved, rule, method } के साथ resolve होते हैं, जहाँ status not_required, pending, approved, review, declined या expired है। redirectUri क्लाइंट के redirect पते पर डिफ़ॉल्ट होता है और आपके एप्लिकेशन के पंजीकृत redirect पतों में से किसी एक से ठीक मेल खाना चाहिए: जब जाँच आवश्यक हो, तो Didit किसी भी अन्य पते को अस्वीकार करता है। आपका बैकएंड step-up के आधार पर कार्य करने से पहले, GET step-up/{id}/ और व्यक्ति के access token के साथ step-up को फिर से पढ़ता है, क्योंकि ब्राउज़र द्वारा रिपोर्ट किए गए परिणाम को बदला जा सकता है। headless साइन-इन protection_required भी लौटा सकता है, जब आपके एप्लिकेशन के protection नियम उसे चिह्नित करें। तब व्यक्ति इसे उस code से पूरा करता है जो Didit ने उसे ईमेल किया है (protection.verify({ code })) या पासकी से (protection.passkey()), और methods बताता है कि वह इन दोनों में से कौन-सी विधि इस्तेमाल कर सकता है। कोई अनुमानित version इंस्टॉल न करें और अनुमानित कॉलबैक विकल्पों के अनुसार कोड न लिखें। होस्टेड उदाहरण बदलने से पहले प्रकाशित पैकेज के exports, issuer और key configuration की पुष्टि करें। पासवर्ड, ईमेल code, magic link, पासकी, फ़ोन, MFA, सोशल साइन-इन, step-up और agent methods उस रिलीज़ के समर्थित API पर निर्भर करेंगे।

अन्य उत्पाद जोड़ें

आपका बैकएंड access token की पुष्टि करता है (देखें टोकन और JWKS) और उसका vendor_data पढ़ता है। उस मान को सत्यापन सत्र बनाते समय या लेन-देन टोकन जारी करते समय vendor_data के रूप में उपयोग करें। सफल साइन-इन का अर्थ यह नहीं है कि किसी भी उत्पाद ने उपयोगकर्ता को स्वीकृत किया है। शिप करने से पहले, अपने सक्षम sandbox एप्लिकेशन के विरुद्ध sign-up, लौटने वाले उपयोगकर्ता का साइन-इन, रद्द करना, state का मेल न खाना, पुनः उपयोग किया गया code, पासवर्ड भूल जाना, MFA, समय-सीमा समाप्त होना और लॉगआउट का परीक्षण करें।
अंतिम संशोधन 7 नवंबर 2026