कैप्टिव पोर्टल के लिए WeChat OAuth ऑथेंटिकेशन को कैसे कॉन्फ़िगर करें

कैप्टिव पोर्टल के लिए WECHAT OAUTH ऑथेंटिकेशन को कैसे कॉन्फ़िगर करें एक Purple तकनीकी ब्रीफिंग - लगभग 10 मिनट --- परिचय और संदर्भ (लगभग 1 मिनट) आपका स्वागत है। यदि आप किसी होटल, रिटेल चेन, स्टेडियम या कॉन्फ्रेंस सेंटर में गेस्ट WiFi के लिए जिम्मेदार हैं जो चीनी विज़िटर्स को सेवा प्रदान करता है, तो यह ब्रीफिंग आपके लिए है। Tencent के 2024 के आंकड़ों के अनुसार, WeChat के पास 1.38 बिलियन मासिक सक्रिय उपयोगकर्ता हैं। इनमें से अधिकांश चीन में हैं, लेकिन इस प्लेटफ़ॉर्म की अंतरराष्ट्रीय स्तर पर भी महत्वपूर्ण उपस्थिति है - संयुक्त राज्य अमेरिका में चार मिलियन उपयोगकर्ता, मलेशिया में 12 मिलियन, और दक्षिण पूर्व एशिया, यूरोप और मध्य पूर्व में इसकी संख्या बढ़ रही है। जब कोई चीनी गेस्ट आपके WiFi से कनेक्ट होता है और केवल ईमेल, Facebook या वाउचर कोड वाला लॉगिन पेज देखता है, तो उन्हें तुरंत असुविधा का सामना करना पड़ता है। हो सकता है कि उनके पास उस डिवाइस पर कोई स्थानीय ईमेल पता सेट न हो। उनके पास निश्चित रूप से WeChat होता है। इसलिए सवाल यह नहीं है कि क्या आपको WeChat लॉगिन की पेशकश करनी चाहिए - बल्कि यह है कि आप इसे सही ढंग से, सुरक्षित रूप से और इस तरह से कैसे कॉन्फ़िगर करते हैं जिससे ऐसा फ़र्स्ट-पार्टी डेटा जनरेट हो जिसका आप वास्तव में उपयोग कर सकें। आज हम इसी विषय को कवर करने जा रहे हैं। हम OAuth 2.0 फ़्लो, आपके लिए आवश्यक दो प्लेटफ़ॉर्म रजिस्ट्रेशन, स्कोप का निर्णय जो यह निर्धारित करता है कि आप क्या डेटा एकत्र करते हैं, नेटवर्क-साइड प्रवर्तन तंत्र (network-side enforcement mechanism), और 2026 में महत्वपूर्ण अनुपालन संबंधी विचारों पर चर्चा करेंगे। --- तकनीकी गहन विश्लेषण (लगभग 5 मिनट) आइए आर्किटेक्चर से शुरुआत करें। एक कैप्टिव पोर्टल किसी अनऑथेंटिकेटेड डिवाइस से आने वाले HTTP ट्रैफ़िक को रोकता है और उसे लॉगिन पेज पर रीडायरेक्ट करता है। वह लॉगिन पेज एक पोर्टल सर्वर पर होस्ट किया जाता है - चाहे वह ऑन-प्रिमाइसेस हो या क्लाउड में। जब आप WeChat OAuth जोड़ते हैं, तो आप उस फ़्लो में एक थर्ड-पार्टी पहचान प्रदाता (identity provider) को शामिल कर रहे होते हैं। यहाँ इसका क्रम दिया गया है। गेस्ट आपके 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 Platform वेबसाइट एप्लिकेशन और मोबाइल ऐप को संभालता है। mp.weixin.qq.com पर WeChat Official Accounts Platform सार्वजनिक खातों (public accounts) को संभालता है - जिसकी वास्तव में अधिकांश स्थानों को आवश्यकता होती है। WeChat इन-ऐप ब्राउज़र के अंदर गेस्ट्स को सेवा देने वाले कैप्टिव पोर्टल के लिए, आपको Official Accounts Platform पर एक Service Account की आवश्यकता होती है। एक Subscription Account काम नहीं करेगा - इसमें OAuth वेब पेज ऑथराइजेशन अनुमतियां नहीं होती हैं। एक Service Account में यह होती हैं, और यह snsapi_base और snsapi_userinfo दोनों स्कोप का समर्थन करता है। WeChat के बाहर एक मानक मोबाइल ब्राउज़र - Android पर Chrome, iOS पर Safari - से एक्सेस किए जाने वाले कैप्टिव पोर्टल के लिए, आपको Open Platform पर रजिस्टर्ड एक Website Application की आवश्यकता होती है। यह snsapi_login स्कोप का उपयोग करता है और एक QR कोड प्रस्तुत करता है जिसे उपयोगकर्ता अपने WeChat ऐप से स्कैन करता है। व्यवहार में, अधिकांश स्थान डिप्लॉयमेंट दोनों का उपयोग करते हैं। किसी होटल के WiFi पर एक गेस्ट Chrome में पोर्टल खोल सकता है, एक QR कोड देख सकता है, उसे WeChat से स्कैन कर सकता है, और ऑथेंटिकेट कर सकता है। या वे WeChat के भीतर ही किसी लिंक का अनुसरण कर सकते हैं, इन-ऐप ब्राउज़र पर पहुंच सकते हैं, और snsapi_base के साथ चुपचाप ऑथेंटिकेट कर सकते हैं। आइए स्कोप चयन के बारे में बात करते हैं, क्योंकि यह एक वास्तविक निर्णय बिंदु है। snsapi_base केवल OpenID लौटाता है - जो आपके Official Account के भीतर उस उपयोगकर्ता के लिए एक विशिष्ट पहचानकर्ता है। इसके लिए किसी उपयोगकर्ता सहमति प्रॉम्प्ट की आवश्यकता नहीं होती है। ऑथेंटिकेशन उपयोगकर्ता के लिए अदृश्य होता है। यह उन लौटने वाले गेस्ट्स के लिए आदर्श है जिनका प्रोफ़ाइल आपने पहले ही बना लिया है, या उन स्थानों के लिए जहाँ आप बिना किसी नए डेटा के शून्य असुविधा (zero friction) चाहते हैं। snsapi_userinfo OpenID के साथ-साथ उपयोगकर्ता का WeChat उपनाम, प्रोफ़ाइल चित्र, लिंग, भाषा सेटिंग और शहर लौटाता है। इसके लिए एक स्पष्ट सहमति स्क्रीन की आवश्यकता होती है। उपयोगकर्ता को एक प्रॉम्प्ट दिखाई देता है जिसमें पूछा जाता है कि क्या वे आपके Official Account को अपनी जानकारी तक पहुँचने की अनुमति देते हैं। अधिकांश उपयोगकर्ता इसे स्वीकार करते हैं, लेकिन इसमें असुविधा होती है। सही विकल्प आपके उपयोग के मामले पर निर्भर करता है। पहली बार आने वाले गेस्ट के रजिस्ट्रेशन के लिए जहाँ आप एक प्रोफ़ाइल बनाना चाहते हैं, snsapi_userinfo का उपयोग करें और इसे अपने पोर्टल पेज पर GDPR-अनुपालक सहमति परत (consent layer) के साथ जोड़ें। लौटने वाले गेस्ट के लिए जिसने पहले ही सहमति दे दी है और जिसका प्रोफ़ाइल आपके पास पहले से है, चुपचाप पुनः ऑथेंटिकेशन के लिए 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 Platform 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 Platform पर लिंक करना आवश्यक होता है। --- सारांश और अगले कदम (लगभग 1 मिनट) संक्षेप में। कैप्टिव पोर्टल के लिए WeChat OAuth ऑथेंटिकेशन दो-प्लेटफ़ॉर्म रजिस्ट्रेशन अभ्यास, एक स्कोप निर्णय, एक नेटवर्क प्रवर्तन एकीकरण और एक अनुपालन समीक्षा है। इन चार चीजों को सही तरीके से करें और आपके पास एक ऐसी लॉगिन विधि होगी जो बिना किसी पासवर्ड असुविधा के एक बिलियन से अधिक संभावित विज़िटर्स को सेवा प्रदान करती है। व्यावहारिक अगले कदम ये हैं। सबसे पहले, यह निर्धारित करें कि आपके विज़िटर्स को पोर्टल का सामना WeChat इन-ऐप ब्राउज़र के अंदर करना पड़ता है या एक मानक मोबाइल ब्राउज़र में - यह निर्धारित करता है कि आपको किस प्लेटफ़ॉर्म रजिस्ट्रेशन की आवश्यकता है। दूसरा, स्कोप तय करें - लौटने वाले गेस्ट्स के लिए snsapi_base, सहमति के साथ पहली बार रजिस्ट्रेशन के लिए snsapi_userinfo। तीसरा, पुष्टि करें कि आपका नेटवर्क हार्डवेयर RADIUS CoA का समर्थन करता है या विकल्प के रूप में MAC बाईपास कॉन्फ़िगर करें। चौथा, GDPR और PIPL आवश्यकताओं के विरुद्ध अपने गोपनीयता नोटिस और सहमति फ़्लो की समीक्षा करें। पांचवां, लाइव होने से पहले रीडायरेक्ट URI, स्टेट पैरामीटर सत्यापन और इन-ऐप ब्राउज़र डिटेक्शन का परीक्षण करें। यदि आप देखना चाहते हैं कि Purple एक व्यापक Guest WiFi और एनालिटिक्स प्लेटफ़ॉर्म के हिस्से के रूप में WeChat OAuth को कैसे संभालता है - 2024 में 80,000 स्थानों और 440 मिलियन लॉगिन में - तो purple.ai पर जाएं या अपनी अकाउंट टीम से बात करें। सुनने के लिए धन्यवाद। --- स्क्रिप्ट का अंत