हर बार किसी सेवा में साइनअप के लिए पहचान सत्यापन जोड़ते समय SMS भेजने की लागत बोझ बनती थी, इसलिए दिशा उलटकर बनाया गया यह मोबाइल verification API है.
मौजूदा SMS verification में सेवा उपयोगकर्ता को verification संदेश भेजती है (MT, Mobile Terminated). प्रति संदेश 9~50 won तक लागत आती है और मासिक बेस शुल्क भी जुड़ता है, इसलिए जैसे-जैसे उपयोगकर्ता बढ़ते हैं, खर्च भी बढ़ता जाता है. कॉन्ट्रैक्ट और समीक्षा प्रक्रिया के कारण integration में 1~2 हफ्ते भी लग सकते हैं.
OCTOMO ने इस दिशा को उलट दिया है (MO, Mobile Originated). उपयोगकर्ता अपने ही मोबाइल से तय किए गए नंबर पर verification code वाला संदेश भेजता है, और सेवा केवल API के जरिए प्राप्त हुए संदेश को query करती है. क्योंकि संदेश भेजने वाला उपयोगकर्ता है, इसलिए सेवा पक्ष पर sending cost नहीं आती, और चूंकि उपयोगकर्ता ने वास्तव में उसी डिवाइस से संदेश भेजा है, यह possession verification भी बन जाता है.
सुझाया गया flow यह है कि verification बटन दबाने पर मैसेज ऐप इस तरह खुले कि प्राप्तकर्ता नंबर और verification code पहले से भरे हों, और उपयोगकर्ता को सिर्फ send बटन दबाना पड़े. (
sms:deep link से इसे handle किया जाता है, इसलिए frontend में implementation करना होता है, लेकिन मोबाइल पर यही standard तरीका है.) नंबर गलत दर्ज करने या code में typo होने की संभावना नहीं रहती, इसलिए failure rate भी कम हो जाता है.API व्यावहारिक रूप से सिर्फ एक endpoint है.
POST /octomo/v1/public/message/exists
- इनपुट: मोबाइल नंबर + उपयोगकर्ता द्वारा भेजा गया code
- आउटपुट: क्या पिछले 5 मिनट के भीतर उस code वाला संदेश प्राप्त हुआ था (
verified: true/false)Integration flow लगभग इतना ही सरल है: "बटन टैप → मैसेज ऐप अपने-आप चलना (नंबर·code auto-fill) → उपयोगकर्ता send करे → यह API call करें, और true मिले तो pass". किसी अलग ऐप installation या SDK के बिना सिर्फ REST call से काम हो जाता है, और दस्तावेज़ में Node/Java/Python examples भी दिए गए हैं.
ईमानदारी से इसकी सीमाएँ भी लिख रहा हूँ.
- deep link से manual input की मेहनत हटा दी गई है, लेकिन उपयोगकर्ता को send बटन एक बार और दबाना पड़ता है (0 sending cost और मज़बूत possession verification के साथ यह trade-off है).
- यह कोरिया के मोबाइल नंबर आधारित है, इसलिए विदेशी उपयोगकर्ता इसके दायरे में नहीं आते.
- उपयोगकर्ता पर उसके अपने प्लान का SMS शुल्क लागू होगा (unlimited plan हो तो व्यावहारिक रूप से मुफ़्त).
खास तौर पर "क्या इस flow में user drop-off ज़्यादा नहीं होगा" जैसी UX चिंताएँ या security के नज़रिये से की जाने वाली आलोचनाएँ सुनना चाहता हूँ. Feedback का स्वागत है.
16 टिप्पणियां
ओह, यह एक तरह का MO verification है। ऐसा लगेगा कि अगर यह भी बताया जाए कि इस तरह की identity verification या mobile possession verification जैसी सेवाएँ Financial Supervisory Service आदि प्रमुख संबंधित संस्थानों की कानूनी आवश्यकताओं को पूरा करके वैध प्रभाव रखती हैं या नहीं, तो और भी अच्छा होगा। शुभकामनाएँ!
समर्थन के लिए धन्यवाद!
अच्छी service बनाने के लिए धन्यवाद!
SMS प्राप्त हुआ है या नहीं, यह हाल के 5 मिनट के भीतर तय होकर fixed है,
लेकिन कुछ मामलों में इसे इससे छोटा या लंबा रखना चाहा जा सकता है,
इसलिए यह भी अच्छा होगा अगर प्राप्ति की पुष्टि का समय API के parameter के भीतर specify किया जा सके!
अच्छे सुझाव के लिए धन्यवाद! आपने जिन बातों का ज़िक्र किया है, हम उनकी समीक्षा करके सेवा को और बेहतर बनाएँगे!
मैंने भी यह फीचर अंदरूनी तौर पर बनाकर इस्तेमाल करते हुए कभी सोचा था कि क्या इसी तरह का कोई SaaS साथ में चलाया जाए,
लेकिन मुझे लगा कि इसमें शायद कुछ कानूनी मुद्दे हो सकते हैं।
क्योंकि यह ऐसी स्थिति बन जाती है जहाँ मेरी कंपनी के नाम पर कॉन्ट्रैक्ट किए गए फ़ोन नंबर के उपयोग का अधिकार ग्राहक को बेचा जा रहा है,
तो मन में यह ख़याल आया कि कहीं यह बिजली और दूरसंचार कानून का उल्लंघन तो नहीं होगा...
फीचर फोन के ज़माने में मनचाहे तरीके से caller ID बदल सकने की बात याद आ रही है
उस समय होता तो यह तकनीक असरदार नहीं होती, लेकिन समय बदलने के साथ यह उपयोग में लाई जा सकने वाली तकनीक बन गई है, यह दिलचस्प है
रुचि दिखाने के लिए धन्यवाद!
ओह, बढ़िया आइडिया
धन्यवाद !
पुराने public certificate जारी करते समय, आपने जैसा बताया था उसी तरीके से किसी खास संख्या को SMS में जवाब भेजने वाले रूप की verification की जा रही होती है।
इस तरीके में यूज़र को खुद भेजने वाला प्रमाणीकरण तरीका भी कम सही, लेकिन इस्तेमाल हो रहा है, इसलिए concept पर अलग से feedback की ज़रूरत नहीं लगती।
व्यक्तिगत तौर पर, authentication code पाकर उसे दर्ज करने से यह तरीका मुझे ज़्यादा पसंद है।
वैसे भी जहाँ कानूनी पहचान प्रमाणीकरण की ज़रूरत होती है, वहाँ PASS को शामिल करना पड़ेगा, इसलिए उसे अलग मामला मानता हूँ...
मुझे पता है कि व्यक्तिगत पहचान सत्यापन और possession verification के कानूनी आवश्यकताएँ अलग-अलग होती हैं, इसलिए कुछ मामलों में व्यक्तिगत पहचान सत्यापन का इस्तेमाल करना ही पड़ता है। किन मामलों में केवल यह possession verification इस्तेमाल किया जा सकता है, यह अगर और स्पष्ट रूप से लिखा होता तो अच्छा रहता।
फ़ीडबैक के लिए धन्यवाद!
जैसा आपने कहा, identity verification और possession verification जिन आवश्यकताओं को पूरा करते हैं वे अलग हैं,
इसलिए किन मामलों में केवल possession verification पर्याप्त है, उसके मानदंड हम दस्तावेज़ में और अधिक स्पष्ट रूप से व्यवस्थित करके जोड़ेंगे।
इसे इतनी सटीकता से इंगित करने के लिए धन्यवाद!
ओह, यह तो ऐसी चीज़ है जिसकी मैंने कम-से-कम एक बार इच्छा की थी, और API भी पूरी तरह इस्तेमाल करने में आसान लग रही है...!
"यूज़र अपने ही मोबाइल फ़ोन से तय किए गए नंबर पर verification code SMS करता है"
यह हिस्सा थोड़ा भ्रमित कर रहा है, मतलब क्या यूज़र को OCTOMO द्वारा दिए गए नंबर पर SMS भेजने के लिए गाइड किया जाता है?
जी हाँ, बिल्कुल! आपको उपयोगकर्ताओं को यह निर्देश देना होगा कि वे OCTOMO द्वारा दिए गए नंबर पर verification code को SMS से भेजें.
ऐप environment में
sms:deep link का उपयोग करने की सलाह दी जाती है, ताकि जब उपयोगकर्ता verification बटन दबाए तो message application अपने-आप खुल जाए!वेब environment में फिलहाल verification code SMS भेजने का तरीका उपलब्ध है, और इसके अलावा QR code तरीका भी विकसित किया जा रहा है.
जब उपयोगकर्ता QR code स्कैन करेगा, तो उसे अपने-आप message application में ले जाने की व्यवस्था की जा रही है!
धन्यवाद!
वाह, यह तो बहुत बढ़िया है.. इसे side project में अच्छे से इस्तेमाल करूँगा haha