मुख्य सामग्री पर जाएं
Authentication नया है: didit_auth रिलीज़ पर निर्भर है। वितरण निर्देशांक, संस्करण और कॉल किए जा सकने वाले सिग्नेचर यहाँ पुष्ट नहीं हैं। कोई अनुमानित पैकेज इंस्टॉल न करें, और पहचान सत्यापन SDK को Authentication SDK के रूप में उपयोग न करें।

​
एप्लिकेशन तैयार करें

  1. पुष्टि करें कि आपके Didit एप्लिकेशन के लिए Authentication सक्षम है, और कंसोल से उसका sign-in origin (https://<slug>.auth.didit.me, या सैंडबॉक्स के लिए <slug>.sandbox.auth.didit.me) कॉपी करें।
  2. अपने एप्लिकेशन और रनटाइम द्वारा समर्थित एक सटीक कॉलबैक URL पंजीकृत करें। ऐप-लिंक के स्वामित्व की पुष्टि करें; यह न मानें कि मनमाने कस्टम URL स्कीम स्वीकार की जाएँगी।
  3. सैंडबॉक्स और लाइव कॉन्फ़िगरेशन को अलग रखें, जिसमें कॉलबैक हैंडलिंग और संग्रहीत क्रेडेंशियल भी शामिल हैं।
  4. Verification या निगरानी से जुड़ने से पहले अपनी स्थिर व्यक्ति मैपिंग चुनें।
iOS और Android पर कॉलबैक लिंक को अलग-अलग कॉन्फ़िगर करें और परखें। Authentication wrapper, didit_sdk से अलग है, जो सत्यापन को संभालता है।

​
होस्टेड फ़्लो लागू करें

नेटिव सिस्टम authentication browser को {origin}/sign-in URL के साथ खोलें। एक नया, यादृच्छिक state, एक S256 PKCE challenge और अपना पंजीकृत redirect_uri दें। Verifier को केवल उसी प्रयास के लिए अपने ऐप में रखें। JavaScript क्विकस्टार्ट अंतर्निहित प्रोटोकॉल दिखाता है; नेटिव कोड में ब्राउज़र globals के बजाय प्लेटफ़ॉर्म की क्रिप्टोग्राफ़ी और URL हैंडलिंग का उपयोग करें। कॉलबैक मिलने पर state, लेन-देन का जीवनकाल और कॉलबैक गंतव्य की पुष्टि करें, उसके बाद एक बार उपयोग होने वाले कोड को token/ पर एक्सचेंज करें। मूल verifier और सटीक redirect URI का उपयोग करें। ब्राउज़र रद्द करना या बंद करना सफल लॉगिन नहीं है। Refresh tokens को नेटिव प्लेटफ़ॉर्म-सुरक्षित स्टोरेज में रखें; कभी भी सादी preferences फ़ाइल, analytics या crash logs में नहीं। End-user Bearer token के साथ GET session/ का उपयोग करके वर्तमान सत्र की पुष्टि करें। Refresh को क्रमबद्ध (serialize) करें, दोनों टोकन एक साथ बदलें, और sign-out के बाद उपयोगकर्ता-विशिष्ट स्थिति साफ़ करें। अनुरोध अनुबंध और refresh-reuse व्यवहार के लिए टोकन और JWKS देखें।

​
नेटिव SDK रिलीज़ पूर्वावलोकन

नेटिव Authentication मॉड्यूल की योजना साइन-इन, वर्तमान सत्र तक पहुँच, टोकन प्राप्ति, sign-out और step-up देने की है, साथ में स्वचालित डिवाइस संकेत भी। नेटिव passkeys और संरक्षित टोकन स्टोरेज उसी रिलीज़ का हिस्सा हैं। Wrapper APIs अपने प्रकाशित प्लेटफ़ॉर्म अनुबंधों का पालन करेंगे; किसी डिज़ाइन उदाहरण से अनुमानित constructor arguments या method signatures कॉपी न करें। मॉड्यूल रिलीज़ होने तक उसका adapter बंद रखें, या अपने सक्षम एप्लिकेशन के लिए होस्टेड प्रोटोकॉल का समीक्षित कार्यान्वयन उपयोग करें। केवल पैकेज इंस्टॉल होने के आधार पर किसी काम करने वाले नेटिव Authentication quickstart का दावा न करें।

​
सत्यापन और निगरानी से जुड़ें

आपका बैकएंड प्रमाणित व्यक्ति से vendor_data निकालता है। वह उस व्यक्ति के लिए verification sessions बनाता है या scoped monitoring tokens जारी करता है। अपने ऐप को केवल session credential या scoped token लौटाएँ; API कुंजी सर्वर पर ही रहती है। पहचान सत्यापन की ज़रूरत हो तो Flutter सत्यापन SDK का उपयोग करें। अपने प्लेटफ़ॉर्म पर निगरानी समर्थन के लिए SDK लेन-देन सबमिशन का पालन करें। Sign-in, सत्यापन और लेन-देन निर्णयों को अलग-अलग मानें।

​
एकीकरण की जाँच करें

कोल्ड-स्टार्ट ऐप पर वापसी, background और foreground ट्रांज़िशन, ब्राउज़र रद्द करना, असंगत कॉलबैक, code replay, टोकन की समय-सीमा समाप्ति, समवर्ती refresh, MFA, logout और किसी दूसरे उपयोगकर्ता के रूप में साइन इन करने का परीक्षण करें। रिलीज़ उपलब्ध होने पर, समर्थित डिवाइसों पर passkey enrollment और sign-in का परीक्षण करें। डिवाइस-आधारित जाँच तब तक असत्यापित रहती है जब तक वह लक्ष्य प्लेटफ़ॉर्म पर न चले।
अंतिम संशोधन 7 नवंबर 2026