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

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

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

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

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

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

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

​
सत्यापन और निगरानी कनेक्ट करें

आपका बैकएंड प्रमाणित व्यक्ति से vendor_data निकालता है। वह उस व्यक्ति के लिए सत्यापन सत्र बनाता है या सीमित-क्षेत्र वाले निगरानी token जारी करता है। ऐप को केवल सत्र क्रेडेंशियल या सीमित-क्षेत्र वाला token लौटाएँ; API कुंजी सर्वर पर ही रहती है। जब आपको पहचान सत्यापन की आवश्यकता हो, तो iOS सत्यापन SDK उपयोग करें। अपने प्लेटफ़ॉर्म पर निगरानी समर्थन के लिए SDK लेन-देन सबमिशन का पालन करें। साइन-इन, सत्यापन और लेन-देन के निर्णयों को अलग-अलग मानें।

​
इंटीग्रेशन सत्यापित करें

बंद अवस्था वाले एप्लिकेशन पर वापसी, बैकग्राउंड और फ़ोरग्राउंड बदलाव, ब्राउज़र रद्द करना, बेमेल कॉलबैक, कोड को दोबारा चलाना या पुनः प्रस्तुत करना, token की समय-सीमा समाप्ति, समवर्ती refresh, MFA, लॉगआउट और किसी दूसरे उपयोगकर्ता के रूप में साइन-इन करने का परीक्षण करें। जब वह रिलीज़ उपलब्ध हो, तब समर्थित डिवाइसों पर passkey एनरोलमेंट और साइन-इन का परीक्षण करें। डिवाइस-केवल जाँच तब तक असत्यापित रहती है जब तक वह लक्ष्य प्लेटफ़ॉर्म पर न चले।
अंतिम संशोधन 7 नवंबर 2026