Verify सर्वोत्तम प्रथाएँ

Verify ऐसी डिफ़ॉल्ट सेटिंग्स के साथ आता है जो अधिकांश वन-टाइम-सत्यापन कोड फ़्लो के लिए उपयुक्त हैं। यह गाइड उन निर्णयों को कवर करती है जो डिफ़ॉल्ट सेटिंग्स आपके लिए नहीं लेतीं: कोड कितनी देर तक वैध रहना चाहिए, उसमें कितने अंक होने चाहिए, आप जो वास्तव में सत्यापित कर रहे हैं उसके लिए कौन सा चैनल उचित है, और डिलीवरी समस्या को सत्यापन समस्या से कैसे अलग पहचानें।

जहाँ किसी सार्वजनिक मानक की कोई राय है, यह गाइड उसे उद्धृत करती है। सत्यापन कोड प्रमाणीकरण का मानक NIST SP 800-63B है, Digital Identity Guidelines: Authentication and Authenticator Management, 3 सितम्बर 2026 को प्राप्त। उद्धरण वर्तमान संशोधन से हैं। पुराना Revision 3, जिसे बहुत सी OTP सलाह अभी भी संदर्भित करती है, NIST का अपना बैनर लगाए है: 1 अगस्त 2025 से SP 800-63-4 द्वारा प्रतिस्थापित।

कोड छह अंक या उससे अधिक रखें

Bird के कोड डिफ़ॉल्ट रूप से 6 अंकों के होते हैं और options.code_length प्रति अनुरोध 4 से 8 स्वीकार करता है (सत्यापन सेटिंग्स)। डिफ़ॉल्ट सही विकल्प है और इस सीमा का निचला छोर नहीं:

The verifier SHALL generate random authentication secrets that are at least six decimal digits (or equivalent) in length using an approved random bit generator

4 या 5 अंकों का कोड API द्वारा स्वीकार किए जाने की सीमा के अंदर है और मानक द्वारा अनुमत सीमा के बाहर है। कोड को छोटा केवल ऐसे फ़्लो के लिए करें जहाँ आपने तय किया है कि सत्यापन कोड एन्ट्रॉपी सुरक्षा का काम नहीं कर रही।

जीवनकाल दस मिनट या उससे कम रखें

Duration डिफ़ॉल्ट रूप से 10 मिनट है और 1 से 999 तक स्वीकार करता है (सत्यापन सेटिंग्स)। डिफ़ॉल्ट मानक की सीमा पर ठीक बैठता है:

In all cases, the authentication SHALL be considered invalid unless completed within 10 minutes.

तो यह सीमा अधिकतम से बहुत आगे जाती है। एक्सपायर हो चुके कोड के बारे में सपोर्ट संपर्क कम करने के लिए Duration बढ़ाना वह एक सेटिंग परिवर्तन है जो चुपचाप किसी फ़्लो को 800-63B के बाहर ले जाता है। अगर कोड उपयोगकर्ताओं तक पहुँचने से पहले एक्सपायर हो रहे हैं, तो समाधान आमतौर पर विंडो बढ़ाना नहीं बल्कि भेजने का मार्ग सुधारना है।

अनुरोध दर सीमित करना की दो परतें अपेक्षित रखें

जाँच प्रयास दो बार सीमित होता है, और दोनों सीमाएँ अलग-अलग खतरों का जवाब देती हैं।

आपकी सेटिंग। Maximum Retries डिफ़ॉल्ट रूप से 5 है और 1 से 10 तक स्वीकार करता है; इसके बाद सत्यापन attempts_exhausted के साथ विफल हो जाता है। मानक के अनुसार इतने छोटे कोड के लिए इस सीमा का होना आवश्यक है, और यह एक जानने योग्य नियम भी जोड़ता है:

Generating a new authentication secret SHALL NOT reset the failed authentication count.

इस सीमा की एक अधिकतम सीमा है, और यह वह एक जगह है जहाँ Verify द्वारा दी जाने वाली हर वैल्यू मानक के अंदर आराम से आती है:

the verifier SHALL limit consecutive failed authentication attempts using a specific authenticator on a single subscriber account to no more than 100 by disabling that authenticator

Maximum Retries अधिकतम 10 तक जाता है, इसलिए आपकी कोई भी कॉन्फ़िगरेशन 100 तक नहीं पहुँचती। यह ऊपर के दो सेक्शन का उल्टा है: कोड लंबाई और अवधि दोनों में एक ऐसी समर्थित वैल्यू है जो 800-63B से बाहर जाती है, और प्रयास सीमा में ऐसी कोई वैल्यू नहीं है।

Bird की प्लेटफ़ॉर्म कैप्स, जो आपकी किसी भी कॉन्फ़िगरेशन पर लागू होती हैं: प्रति पता प्रति रोलिंग घंटे 5 सेंड, शुरू करने और दोबारा भेजने दोनों में, और प्रति प्राप्तकर्ता पता सेट प्रति मिनट 10 जाँचें। दोनों Retry-After हेडर के साथ 429 लौटाती हैं (दुरुपयोग सुरक्षा)। ये OTP ट्रैफ़िक को आपके बिल या किसी अनजान व्यक्ति के हैंडसेट के खिलाफ़ हथियार बनाए जाने से रोकने के लिए हैं, इसलिए यहाँ 429 को सिस्टम के सही काम करने के रूप में देखें, न कि किसी ऐसी सीमा के रूप में जिसके आसपास इंजीनियरिंग करनी है।

आप जो सत्यापित कर रहे हैं उसके अनुसार चैनल चुनें

Verify ईमेल, SMS, WhatsApp और Telegram के ज़रिए डिलीवर करता है (चैनल)। मानक इनमें से दो को बहुत अलग तरीके से देखता है, और यह भेद इस बारे में है कि कोड किसलिए है, न कि कौन सा चैनल उसे ले जाता है।

ईमेल एक प्रमाणीकरण कारक नहीं है। 800-63B स्पष्ट है:

Email SHALL NOT be used for out-of-band authentication because it may be vulnerable to:

• Access using only a password
• Interception in transit or at intermediate mail servers
• Rerouting attacks, such as those caused by Domain Name System (DNS) spoofing

वही अनुच्छेद उस स्थिति को अलग करता है जिसके लिए Verify का ईमेल चैनल बना है:

Confirmation codes that are sent to validate email addresses or are issued as recovery codes (see Sec. 4.2.1.2) are not authentication processes and not affected by the above prohibition.

तो एक ईमेल कोड जो यह साबित करता है कि कोई व्यक्ति किसी पते को नियंत्रित करता है, मानक के अपवाद के दायरे में है और ठीक है। साइन-इन पर दूसरे कारक के रूप में उपयोग किया गया ईमेल कोड ठीक नहीं है। अगर आपका फ़्लो दूसरा वाला है, तो ईमेल चैनल का उपयोग न करें।

SMS और वॉइस अनुमत हैं लेकिन प्रतिबंधित। टेलीफ़ोन नेटवर्क पर डिलीवरी तीन दायित्व लाती है, दो लगातार वाक्यों में:

Accordingly, verifiers SHALL ensure that alternative authenticator types are available to all subscribers and SHOULD remind subscribers of this limitation of PSTN out-of-band authenticators before binding one or more devices controlled by the subscriber. Verifiers SHOULD consider risk indicators (e.g., device swap, SIM change, number porting, other abnormal behavior) before using the PSTN to deliver an out-of-band authentication secret.

SHALL एक प्रोडक्ट आवश्यकता है, Verify सेटिंग नहीं: अगर SMS आपका एकमात्र कारक है, तो आप इसे पूरा नहीं करते। Verify का प्रति-देश चैनल क्रम डिलीवरी में मदद करता है, क्योंकि अधिकांश देशों में WhatsApp पहले कोशिश किया जाता है और SMS फ़ॉलबैक के रूप में (चैनल), लेकिन SMS, WhatsApp और Telegram सभी एक ऑथेंटिकेटर प्रकार, आउट-ऑफ़-बैंड, के डिलीवरी पथ हैं, इसलिए इनके बीच बदलना कोई वैकल्पिक प्रकार प्रदान करना नहीं है। दो SHOULD वे हैं जो एक प्रोडक्ट टीम लागू करती है: जब कोई उपयोगकर्ता फ़ोन नंबर जोड़ता है तब एक सूचना, और भेजने से पहले पोर्टिंग और SIM-बदलाव संकेतों की जाँच।

दोबारा भेजने से पहले विफलता को पढ़ें

एक कोड जो पहुँचता नहीं और एक कोड जो पहुँचता है लेकिन गलत टाइप होता है, दोनों को अलग-अलग हैंडलिंग चाहिए, और इवेंट्स इन्हें अलग पहचानते हैं (इवेंट्स)।

verify.attempt.undelivered एक reason ले जाता है, और आगे क्या होता है यह प्राप्तकर्ता के चैनल प्लान पर निर्भर करता है। एक से अधिक चैनल उपलब्ध वाले प्राप्तकर्ता पर यह सत्यापन को समाप्त नहीं करता: Bird अगले चैनल पर आगे बढ़ता है, जिसे अपना verify.attempt.sent मिलता है, इसलिए एक अकेला अनडिलीवर्ड प्रयास कोई मृत सत्यापन नहीं है और आपकी ओर से दोबारा भेजने की ज़रूरत नहीं है। सिंगल-चैनल प्राप्तकर्ता पर आगे बढ़ने के लिए कुछ नहीं है, और सत्यापन समाप्त हो जाता है।

उस समाप्ति को अपनी अलग हैंडलिंग चाहिए, और एक इवेंट इसे पहचानता है। failed स्टेटस साझा है: एक सत्यापन वहाँ पहुँचता है जब बहुत अधिक गलत सत्यापन कोड सबमिट किए गए, reason attempts_exhausted के साथ, और जब कोई नियोजित चैनल डिलीवर नहीं कर सका, reason undeliverable के साथ। केवल दूसरा verify.verification.failed उत्सर्जित करता है। तो सिंगल-चैनल प्राप्तकर्ता पर स्टेटस नहीं बल्कि वह इवेंट आपको बताता है कि किसी को कोड नहीं मिला।

डिज़ाइन में पहले से शामिल करने योग्य एक गुण, और यह Bird का अपना है, मानक का नहीं: इवेंट्स बताता है कि डिलीवरी रिपोर्ट सूचनात्मक हैं, गारंटीड नहीं, क्योंकि कैरियर और मेलबॉक्स प्रदाता क्या पुष्टि करते हैं और कितनी जल्दी, इसमें भिन्नता है। कुछ बाज़ारों में एक प्रयास इवेंट मिनटों देर से आता है या डिलीवरी को स्वीकृति से अलग नहीं करता। "I didn't get a code" पथ POST /v1/verify/verifications/next-channel पर बनाएँ, जो सत्यापन को आगे बढ़ाता है, न कि ऐसे डिलीवरी इवेंट की प्रतीक्षा पर जो शायद आए ही नहीं।

अनुरोध को फिर से प्रयास करें, सत्यापन को नहीं

Verify के तीनों एंडपॉइंट Idempotency-Key स्वीकार करते हैं (सुरक्षित रूप से फिर से प्रयास करना)। टाइमआउट या कनेक्शन टूटने के बाद, उसी कुंजी के साथ फिर से प्रयास करने पर मूल प्रतिक्रिया दोहराई जाती है: न कोई दूसरा कोड जाता है और न कोई जाँच प्रयास खर्च होता है। बिना कुंजी के, खोई हुई प्रतिक्रिया के बाद फिर से प्रयास करने पर एक और कोड भेजा जाता है और प्रति घंटा कैप में से एक और सेंड खर्च होता है।

जानें कि एक सेंड की क्या लागत है

बिलिंग भेजे गए प्रत्येक कोड से जुड़ती है, गंतव्य के लिए चैनल की दर पर, और दोबारा भेजना या फ़ॉलबैक प्रति सेंड एक शुल्क जोड़ता है (लागत और बिलिंग)। दो परिणाम फिर से प्रयास नीति को आकार देते हैं:

• एक सत्यापन जो कई चैनलों से गुज़रता है, कई सेंड की लागत लगाता है, इसलिए एक विस्तृत चैनल प्लान उतना ही एक लागत निर्णय है जितना एक डिलीवरी निर्णय।
• Telegram एक अलग बिंदु पर बिल करता है। Telegram से पूछा जाता है कि क्या वह नंबर संदेश प्राप्त कर सकता है, और शुल्क तब लगता है जब उत्तर हाँ होता है, विश्वभर में एक समान दर पर। जो नंबर पहुँच योग्य नहीं है वह मुफ़्त है और बिना किसी बिल के अगले चैनल पर आगे बढ़ जाता है। तो शुल्क का मतलब है डिलीवरी के लिए स्वीकृत, पहुँचा नहीं: एक कोड जो फिर अनडिलीवर्ड रहता है, शुल्क लगा रहता है, और सत्यापन उस चैनल के लिए फिर से भुगतान करता है जिस पर वह आगे गिरता है। जहाँ वह दूसरा शुल्क नहीं चाहिए, उन देशों के लिए Countries पेज पर चैनल क्रम से Telegram हटा दें (लागत और बिलिंग)।

अगले कदम

• सत्यापन भेजना: सेटिंग्स, सुरक्षा उपाय और पूर्ण स्टेटस सूची
• इवेंट्स: प्रत्येक सेशन और डिलीवरी इवेंट अपने पेलोड के साथ
• देश: प्रति-देश चैनल क्रम और उपलब्धता
• प्रेषक और ब्रांडिंग: प्रत्येक संदेश कैसा दिखता है