कैप्टिव पोर्टल के लिए WeChat OAuth प्रमाणीकरण को कैसे कॉन्फ़िगर करें

कैप्टिव पोर्टल के लिए WECHAT OAUTH प्रमाणीकरण को कैसे कॉन्फ़िगर करें एक Purple तकनीकी ब्रीफिंग - लगभग 10 मिनट --- परिचय और संदर्भ (लगभग 1 मिनट) स्वागत है। यदि आप किसी होटल, रिटेल चेन, स्टेडियम या कॉन्फ्रेंस सेंटर में गेस्ट WiFi के लिए ज़िम्मेदार हैं जो चीनी विज़िटर्स को सेवा प्रदान करता है, तो यह ब्रीफिंग आपके लिए है। Tencent के 2024 के आंकड़ों के अनुसार, WeChat के पास 1.38 बिलियन मासिक सक्रिय उपयोगकर्ता हैं। इनमें से अधिकांश चीन में हैं, लेकिन इस प्लेटफ़ॉर्म का एक महत्वपूर्ण अंतर्राष्ट्रीय पदचिह्न भी है - संयुक्त राज्य अमेरिका में चार मिलियन उपयोगकर्ता, मलेशिया में 12 मिलियन, और दक्षिण पूर्व एशिया, यूरोप और मध्य पूर्व में बढ़ती संख्या। जब कोई चीनी अतिथि आपके WiFi से कनेक्ट होता है और केवल ईमेल, Facebook या वाउचर कोड वाला लॉगिन पेज देखता है, तो उन्हें तुरंत बाधा का सामना करना पड़ता है। हो सकता है कि उनके पास उस डिवाइस पर स्थानीय ईमेल पता सेट न हो। उनके पास लगभग निश्चित रूप से WeChat होता है। इसलिए सवाल यह नहीं है कि क्या आपको WeChat लॉगिन की पेशकश करनी चाहिए - बल्कि यह है कि आप इसे सही ढंग से, सुरक्षित रूप से और इस तरह से कैसे कॉन्फ़िगर करते हैं जिससे ऐसा फ़र्स्ट-पार्टी डेटा जनरेट हो जिसका आप वास्तव में उपयोग कर सकें। आज हम इसी को कवर करने जा रहे हैं। हम OAuth 2.0 फ़्लो, आपके लिए आवश्यक दो प्लेटफ़ॉर्म पंजीकरण, स्कोप का निर्णय जो यह निर्धारित करता है कि आप क्या डेटा एकत्र करते हैं, नेटवर्क-साइड प्रवर्तन तंत्र (enforcement mechanism), और 2026 में महत्वपूर्ण अनुपालन विचारों के बारे में जानेंगे। --- तकनीकी गहन विश्लेषण (लगभग 5 मिनट) आइए आर्किटेक्चर से शुरू करें। एक कैप्टिव पोर्टल अप्रमाणित डिवाइस से HTTP ट्रैफ़िक को रोकता है और इसे लॉगिन पेज पर रीडायरेक्ट करता है। वह लॉगिन पेज एक पोर्टल सर्वर पर होस्ट किया जाता है - या तो ऑन-प्रिमाइसेस या क्लाउड में। जब आप WeChat OAuth जोड़ते हैं, तो आप उस फ़्लो में एक थर्ड-पार्टी पहचान प्रदाता को शामिल कर रहे होते हैं। यहाँ क्रम दिया गया है। अतिथि आपके SSID से कनेक्ट होता है। एक्सेस पॉइंट या वायरलेस कंट्रोलर यह पता लगाता है कि डिवाइस का कोई प्रमाणित सेशन नहीं है और सभी HTTP ट्रैफ़िक को आपके कैप्टिव पोर्टल URL पर रीडायरेक्ट कर देता है। पोर्टल पेज लोड होता है और लॉगिन विकल्प प्रस्तुत करता है - जिसमें WeChat शामिल है। अतिथि WeChat लॉगिन पर टैप करता है। आपका पोर्टल सर्वर ब्राउज़र को open.weixin.qq.com पर WeChat के ऑथराइज़ेशन एंडपॉइंट पर रीडायरेक्ट करता है, जिसमें आपका AppID, रीडायरेक्ट URI, कोड का रिस्पॉन्स टाइप और स्कोप पास किया जाता है। WeChat पूरी तरह से अपने सर्वर पर प्रमाणीकरण को संभालता है। यदि अतिथि पहले से ही अपने ब्राउज़र में WeChat में लॉग इन है, तो उन्हें एक सहमति स्क्रीन दिखाई देती है। यदि वे WeChat इन-ऐप ब्राउज़र का उपयोग कर रहे हैं, तो अनुभव `snsapi_base` स्कोप के साथ मूक (silent) हो सकता है - कोई सहमति प्रॉम्प्ट नहीं। WeChat फिर एक अस्थायी ऑथराइज़ेशन कोड के साथ आपके पोर्टल के रीडायरेक्ट URI पर वापस रीडायरेक्ट करता है। आपका पोर्टल सर्वर api.weixin.qq.com/sns/oauth2/access_token को कॉल करके, अपना AppID, AppSecret, कोड और authorization_code का ग्रांट टाइप पास करके उस कोड को एक्सेस टोकन से बदलता है। WeChat एक एक्सेस टोकन, एक रिफ्रेश टोकन, उपयोगकर्ता का OpenID और प्रदान किया गया स्कोप लौटाता है। यदि आपने `snsapi_userinfo` स्कोप का अनुरोध किया है, तो आप उपयोगकर्ता का उपनाम, अवतार, लिंग और शहर प्राप्त करने के लिए दूसरा API कॉल कर सकते हैं। अब, दो प्लेटफ़ॉर्म पंजीकरण। यहीं पर अधिकांश कार्यान्वयन गलत हो जाते हैं। WeChat के दो अलग-अलग डेवलपर प्लेटफ़ॉर्म हैं। open.weixin.qq.com पर WeChat Open प्लेटफ़ॉर्म वेबसाइट एप्लिकेशन और मोबाइल ऐप को संभालता है। mp.weixin.qq.com पर WeChat Official Accounts प्लेटफ़ॉर्म सार्वजनिक खातों को संभालता है - जिसकी अधिकांश स्थानों को वास्तव में आवश्यकता होती है। WeChat इन-ऐप ब्राउज़र के अंदर मेहमानों को सेवा देने वाले कैप्टिव पोर्टल के लिए, आपको Official Accounts प्लेटफ़ॉर्म पर एक Service Account की आवश्यकता होती है। एक Subscription Account काम नहीं करेगा - इसमें OAuth वेब पेज ऑथराइज़ेशन अनुमतियाँ नहीं होती हैं। एक Service Account में होती हैं, और यह `snsapi_base` और `snsapi_userinfo` दोनों स्कोप का समर्थन करता है। WeChat के बाहर एक मानक मोबाइल ब्राउज़र - Android पर Chrome, iOS पर Safari - से एक्सेस किए जाने वाले कैप्टिव पोर्टल के लिए, आपको Open प्लेटफ़ॉर्म पर पंजीकृत एक वेबसाइट एप्लिकेशन की आवश्यकता होती है। यह `snsapi_login` स्कोप का उपयोग करता है और एक QR कोड प्रस्तुत करता है जिसे उपयोगकर्ता अपने WeChat ऐप से स्कैन करते हैं। व्यावहारिक रूप से, अधिकांश स्थान डिप्लॉयमेंट दोनों का उपयोग करते हैं। होटल के WiFi पर एक अतिथि Chrome में पोर्टल खोल सकता है, एक QR कोड देख सकता है, इसे WeChat से स्कैन कर सकता है और प्रमाणित कर सकता है। या वे WeChat में ही किसी लिंक का अनुसरण कर सकते हैं, इन-ऐप ब्राउज़र पर पहुंच सकते हैं, और `snsapi_base` के साथ चुपचाप प्रमाणित कर सकते हैं। आइए स्कोप चयन के बारे में बात करते हैं, क्योंकि यह एक वास्तविक निर्णय बिंदु है। `snsapi_base` केवल OpenID लौटाता है - आपके Official Account के भीतर उस उपयोगकर्ता के लिए एक विशिष्ट पहचानकर्ता। इसके लिए किसी उपयोगकर्ता सहमति प्रॉम्प्ट की आवश्यकता नहीं होती है। प्रमाणीकरण उपयोगकर्ता के लिए अदृश्य होता है। यह उन लौटने वाले मेहमानों के लिए आदर्श है जिनका प्रोफ़ाइल आपने पहले ही बना लिया है, या उन स्थानों के लिए जहाँ आप शून्य नए डेटा की कीमत पर शून्य बाधा चाहते हैं। `snsapi_userinfo` OpenID के साथ-साथ उपयोगकर्ता का WeChat उपनाम, प्रोफ़ाइल चित्र, लिंग, भाषा सेटिंग और शहर लौटाता है। इसके लिए एक स्पष्ट सहमति स्क्रीन की आवश्यकता होती है। उपयोगकर्ता को एक प्रॉम्प्ट दिखाई देता है जिसमें पूछा जाता है कि क्या वे आपके Official Account को अपनी जानकारी तक पहुँचने की अनुमति देते हैं। अधिकांश उपयोगकर्ता स्वीकार करते हैं, लेकिन बाधा होती है। सही चुनाव आपके उपयोग के मामले पर निर्भर करता है। पहली बार आने वाले अतिथि के पंजीकरण के लिए जहाँ आप एक प्रोफ़ाइल बनाना चाहते हैं, `snsapi_userinfo` का उपयोग करें और इसे अपने पोर्टल पेज पर GDPR-अनुपालक सहमति परत के साथ जोड़ें। एक लौटने वाले अतिथि के लिए जिसने पहले ही सहमति दे दी है और जिसका प्रोफ़ाइल आपके पास पहले से है, चुपचाप पुनः प्रमाणीकरण के लिए `snsapi_base` का उपयोग करें। अब, नेटवर्क प्रवर्तन पक्ष। OAuth टोकन प्राप्त करना पहचान साबित करता है, लेकिन यह स्वचालित रूप से नेटवर्क नहीं खोलता है। यूज़र को सफल प्रमाणीकरण को नेटवर्क एक्सेस में बदलने के लिए एक तंत्र की आवश्यकता है। दो मानक दृष्टिकोण RADIUS Change of Authorisation (RFC 3576 में परिभाषित) और MAC एड्रेस बाईपास हैं। RADIUS CoA के साथ, आपका पोर्टल सर्वर सफल OAuth के बाद नेटवर्क कंट्रोलर को एक CoA अनुरोध भेजता, और कंट्रोलर डिवाइस को अप्रमाणित VLAN से गेस्ट VLAN में स्थानांतरित कर देता है। यह Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist और अधिकांश एंटरप्राइज़-ग्रेड कंट्रोलर्स के साथ काम करता है। MAC बाईपास के साथ, पोर्टल सर्वर डिवाइस के MAC एड्रेस को एक अधिकृत क्लाइंट के रूप में पंजीकृत करता है, और कंट्रोलर इसकी अनुमति देता है। MAC बाईपास को लागू करना सरल है लेकिन कम सुरक्षित है, क्योंकि MAC एड्रेस को स्पूफ़ किया जा सकता है। Purple का Guest WiFi प्लेटफ़ॉर्म दोनों तंत्रों को संभालता है। WeChat OAuth पूरा होने के बाद, Purple का क्लाउड ओवरले अंतर्निहित हार्डवेयर को उचित सिग्नल भेजता है - चाहे वह Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme या Fortinet हो। वेन्यू ऑपरेटर को उस अनुवाद को मैन्युअल रूप से प्रबंधित करने की आवश्यकता नहीं है। --- कार्यान्वयन सिफारिशें और नुकसान (लगभग 2 मिनट) मैं आपको वे पांच चीजें बताता हूं जिनके कारण WeChat OAuth कैप्टिव पोर्टल कार्यान्वयन विफल हो जाते हैं। पहला: रीडायरेक्ट URI बेमेल (mismatch)। WeChat आपके द्वारा प्लेटफ़ॉर्म पर पंजीकृत अधिकृत डोमेन के विरुद्ध रीडायरेक्ट URI को सत्यापित करता है। यदि आपका पोर्टल सर्वर किसी भिन्न सबडोमेन, भिन्न पाथ या HTTPS के बजाय HTTP का उपयोग करता है, तो OAuth फ़्लो त्रुटि 40029 - अमान्य कोड के साथ विफल हो जाता है। आपके द्वारा उपयोग किए जाने वाले प्रत्येक डोमेन संस्करण को पंजीकृत करें, जिसमें स्टेजिंग वातावरण भी शामिल है। दूसरा: क्लाइंट साइड पर AppSecret। आपका AppSecret कभी भी क्लाइंट-साइड JavaScript या मोबाइल ऐप बाइनरी में दिखाई नहीं देना चाहिए। यह आपके सर्वर पर होना चाहिए। यदि यह उजागर हो जाता है, तो कोई भी आपके एप्लिकेशन का रूप धारण कर सकता है और आपकी ओर से WeChat के API को कॉल कर सकता है। तीसरा: गायब CSRF सुरक्षा। OAuth अनुरोध में स्टेट पैरामीटर विशेष रूप से क्रॉस-साइट रिक्वेस्ट फ़ॉर्जरी को रोकने के लिए मौजूद है। एक क्रिप्टोग्राफ़िक रूप से रैंडम स्टेट वैल्यू जनरेट करें, इसे उपयोगकर्ता के सेशन में स्टोर करें, और WeChat के वापस रीडायरेक्ट करने पर इसे सत्यापित करें। इसे छोड़ दें और आपके पास एक वास्तविक भेद्यता (vulnerability) होगी। चौथा: इन-ऐप ब्राउज़र डिटेक्शन गैप। WeChat का इन-ऐप ब्राउज़र एक विशिष्ट उपयोगकर्ता एजेंट स्ट्रिंग सेट करता है जिसमें "MicroMessenger" होता है। यदि आपका पोर्टल इसका पता नहीं लगाता है और सही OAuth फ़्लो प्रदान नहीं करता है - इन-ऐप ब्राउज़र के लिए Official Account फ़्लो, मानक ब्राउज़र के लिए Open प्लेटफ़ॉर्म QR फ़्लो - तो उपयोगकर्ताओं को एक टूटा हुआ अनुभव या त्रुटि मिलती है। पांचवां: GDPR और PIPL संरेखण। यदि आप यूरोपीय विज़िटर्स को सेवा देते हैं, तो WeChat OAuth के माध्यम से आपके द्वारा एकत्र किए जाने वाले डेटा पर GDPR लागू होता है। यदि आप चीनी विज़िटर्स को सेवा देते हैं, तो चीन का व्यक्तिगत सूचना सुरक्षा कानून - PIPL - इस बात पर लागू होता है कि आप उनके डेटा को कैसे संसाधित करते हैं। दोनों के लिए प्रसंस्करण के लिए एक वैध आधार, स्पष्ट उद्देश्य सीमा और डेटा न्यूनीकरण की आवश्यकता होती है। `snsapi_base` को `snsapi_userinfo` की तुलना में डेटा न्यूनीकरण सिद्धांतों के तहत उचित ठहराना आसान है। आप जो कुछ भी एकत्र करते हैं, अपने कानूनी आधार और अपनी प्रतिधारण अवधि (retention period) का दस्तावेजीकरण करें। --- रैपिड-फायर प्रश्न और उत्तर (लगभग 1 मिनट) प्रश्न: क्या मैं ऐसे पोर्टल पर WeChat लॉगिन का उपयोग कर सकता हूँ जो ईमेल और SMS लॉगिन भी प्रदान करता है? हाँ। Purple सहित अधिकांश एंटरप्राइज़ पोर्टल प्लेटफ़ॉर्म, एक ही पोर्टल पेज पर कई प्रमाणीकरण विधियों का समर्थन करते हैं। WeChat अन्य विकल्पों के साथ एक विकल्प के रूप में दिखाई देता है। प्रश्न: क्या WeChat OAuth iOS पर काम करता है? हाँ, लेकिन एक सूक्ष्म अंतर के साथ। Apple का ऐप ट्रैकिंग ट्रांसपेरेंसी ढांचा सर्वर-साइड OAuth फ़्लो को प्रभावित नहीं करता है। iOS पर Safari में WeChat लॉगिन QR कोड फ़्लो या रीडायरेक्ट फ़्लो के माध्यम से काम करता है। WeChat ऐप स्वयं प्रमाणीकरण को संभालता है। प्रश्न: क्या होगा यदि WeChat का API अनुपलब्ध हो? आपके पोर्टल को एक फ़ॉलबैक लागू करना चाहिए। यदि WeChat API कॉल टाइम आउट हो जाती है या कोई त्रुटि लौटाती है, तो उपयोगकर्ता को एक वैकल्पिक लॉगिन विधि पर रीडायरेक्ट करें। उन्हें खाली स्क्रीन के साथ न छोड़ें। प्रश्न: क्या मैं OpenID का उपयोग एक स्थायी ग्राहक पहचानकर्ता के रूप में कर सकता हूँ? आपके Official Account के भीतर, हाँ। OpenID किसी दिए गए उपयोगकर्ता और दिए गए Official Account के लिए स्थिर है। यदि आपके पास कई Official Accounts हैं, तो एक ही उपयोगकर्ता के पास उन सभी में अलग-अलग OpenID होंगे। क्रॉस-अकाउंट पहचान समाधान के लिए, WeChat एक UnionID प्रदान करता है, जिसके लिए आपके खातों को Open प्लेटफ़ॉर्म पर लिंक करना आवश्यक होता है। --- सारांश और अगले कदम (लगभग 1 मिनट) संक्षेप में। कैप्टिव पोर्टल के लिए WeChat OAuth प्रमाणीकरण एक दो-प्लेटफ़ॉर्म पंजीकरण अभ्यास, एक स्कोप निर्णय, एक नेटवर्क प्रवर्तन एकीकरण और एक अनुपालन समीक्षा है। इन चार चीजों को सही करें और आपके पास एक लॉगिन विधि होगी जो शून्य पासवर्ड बाधा के साथ एक अरब से अधिक संभावित विज़िटर्स को सेवा प्रदान करती है। व्यावहारिक अगले कदम ये हैं। पहला, यह निर्धारित करें कि आपके विज़िटर्स को WeChat इन-ऐप ब्राउज़र के अंदर पोर्टल मिलता है या एक मानक मोबाइल ब्राउज़र में - यह निर्धारित करता है कि आपको किस प्लेटफ़ॉर्म पंजीकरण की आवश्यकता है। दूसरा, स्कोप तय करें - लौटने वाले मेहमानों के लिए `snsapi_base`, सहमति के साथ पहली बार पंजीकरण के लिए `snsapi_userinfo`। तीसरा, पुष्टि करें कि आपका नेटवर्क हार्डवेयर RADIUS CoA का समर्थन करता है या विकल्प के रूप में MAC बाईपास कॉन्फ़िगर करें। चौथा, GDPR और PIPL आवश्यकताओं के विरुद्ध अपने गोपनीयता नोटिस और सहमति फ़्लो की समीक्षा करें। पांचवां, लाइव होने से पहले रीडायरेक्ट URI, स्टेट पैरामीटर सत्यापन और इन-ऐप ब्राउज़र डिटेक्शन का परीक्षण करें। यदि आप देखना चाहते हैं कि Purple एक व्यापक Guest WiFi और एनालिटिक्स प्लेटफ़ॉर्म के हिस्से के रूप में WeChat OAuth को कैसे संभालता है - 2024 में 80,000 स्थानों और 440 million लॉगिन में - तो purple.ai पर जाएं या अपनी अकाउंट टीम से बात करें। सुनने के लिए धन्यवाद। --- स्क्रिप्ट का अंत