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

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