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

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

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

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

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

​
नेटिव SDK रिलीज़ प्रीव्यू

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

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

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

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

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