Captive Portals साठी WeChat OAuth प्रमाणीकरण कसे कॉन्फिगर करावे

कॅप्टिव्ह पोर्टल्ससाठी WECHAT OAUTH ऑथेंटिकेशन कसे कॉन्फिगर करावे एक Purple तांत्रिक माहितीपत्रक - साधारण १० मिनिटे --- परिचय आणि संदर्भ (साधारण १ मिनिट) स्वागत आहे. जर आपण चायनीज पर्यटकांना सेवा देणाऱ्या हॉटेल, रिटेल साखळी, स्टेडियम किंवा कॉन्फरन्स सेंटरमधील अतिथी WiFi साठी जबाबदार असाल, तर हे माहितीपत्रक आपल्यासाठी आहे. Tencent च्या २०२४ च्या डेटा नुसार, WeChat चे १.३८ अब्ज मासिक सक्रिय वापरकर्ते आहेत. त्यातील बहुतांश चीनमध्ये आहेत, परंतु या प्लॅटफॉर्मचा लक्षणीय आंतरराष्ट्रीय प्रभाव देखील आहे - युनायटेड स्टेट्समध्ये ४ दशलक्ष वापरकर्ते, मलेशियामध्ये १२ दशलक्ष, आणि संपूर्ण आग्नेय आशिया, युरोप आणि मध्य पूर्वेमध्ये ही संख्या वाढत आहे. जेव्हा एखादा चायनीज अतिथी आपल्या WiFi शी कनेक्ट होतो आणि त्याला फक्त ईमेल, Facebook किंवा व्हाउचर कोड असलेले लॉगिन पेज दिसते, तेव्हा त्यांना त्वरित अडचणीचा सामना करावा लागतो. त्यांच्याकडे त्या डिव्हाइसवर स्थानिक ईमेल पत्ता सेट केलेला नसू शकतो. त्यांच्याकडे WeChat नक्कीच असते. त्यामुळे प्रश्न आपण WeChat लॉगिन ऑफर करावे की नाही हा नसून - ते अचूक, सुरक्षितपणे आणि आपण प्रत्यक्षात वापरू शकू असा फर्स्ट-पार्टी डेटा कसा जनरेट होईल अशा पद्धतीने कसे कॉन्फिगर करावे हा आहे. आज आपण याबद्दलच माहिती घेणार आहोत. आपण OAuth २.० फ्लो, आपल्याला आवश्यक असणारे दोन प्लॅटफॉर्म रजिस्ट्रेशन्स, आपण कोणता डेटा गोळा करतो हे ठरवणारा स्कोप निर्णय, नेटवर्क-साइड एन्फोर्समेंट मेकॅनिझम आणि २०२६ मध्ये महत्त्वाचे असणारे कंप्लायन्सचे मुद्दे समजून घेणार आहोत. --- तांत्रिक विश्लेषण (साधारण ५ मिनिटे) चला आर्किटेक्चरपासून सुरुवात करूया. एक 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, कोड आणि authorization_code चा ग्रँट टाईप पास करून api.weixin.qq.com/sns/oauth2/access_token वर कॉल करून त्या कोडच्या बदल्यात ॲक्सेस टोकन मिळवतो. WeChat एक ॲक्सेस टोकन, रिफ्रेश टोकन, वापरकर्त्याचा OpenID आणि मंजूर केलेला स्कोप परत पाठवते. आपण snsapi_userinfo स्कोपची विनंती केली असल्यास, आपण वापरकर्त्याचे टोपणनाव (nickname), अवतार, लिंग आणि शहर मिळवण्यासाठी दुसरा API कॉल करू शकता. आता, दोन प्लॅटफॉर्म Registrations बद्दल जाणून घेऊया. बहुतांश अंमलबजावणीमध्ये याच ठिकाणी चूक होते. WeChat चे दोन स्वतंत्र डेव्हलपर प्लॅटफॉर्म्स आहेत. open.weixin.qq.com वरील WeChat Open Platform हा वेबसाइट ॲप्लिकेशन्स आणि मोबाईल ॲप्स हाताळतो. तर mp.weixin.qq.com वरील WeChat Official Accounts Platform हा पब्लिक अकाउंट्स हाताळतो - ज्याची बहुतांश ठिकाणांना (venues) प्रत्यक्षात गरज असते. 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 मधील त्या वापरकर्त्याचा एक युनिक आयडेंटिफायर आहे. यासाठी कोणत्याही वापरकर्त्याच्या संमतीची (consent prompt) गरज नसते. हे ऑथेंटिकेशन वापरकर्त्याला दिसत नाही. हे अशा पाहुण्यांसाठी आदर्श आहे ज्यांची प्रोफाइल तुम्ही आधीच तयार केली आहे, किंवा अशा ठिकाणांसाठी जेथे तुम्हाला नवीन डेटा गोळा न करता अगदी सुलभ अनुभव द्यायचा आहे. snsapi_userinfo हा OpenID सोबत वापरकर्त्याचे WeChat निकनेम, प्रोफाइल पिक्चर, लिंग, भाषा सेटिंग आणि शहर रिटर्न करतो. यासाठी स्पष्ट संमती स्क्रीनची (consent screen) आवश्यकता असते. वापरकर्त्याला त्यांच्या माहितीमध्ये प्रवेश मिळवण्यासाठी तुमचे Official Account अनुमती देत आहे का, असे विचारणारा प्रॉमप्ट दिसतो. बहुतांश वापरकर्ते हे स्वीकारतात, पण यामुळे प्रक्रियेत एक अतिरिक्त पायरी वाढते. योग्य निवड ही तुमच्या वापराच्या परिस्थितीवर (use case) अवलंबून असते. पहिल्यांदाच नोंदणी करणाऱ्या पाहुण्यासाठी जिथे तुम्हाला प्रोफाइल तयार करायची आहे, तिथे snsapi_userinfo वापरा आणि तुमच्या पोर्टल पेजवर GDPR सुसंगत संमती लेयरसह त्याची जोडणी करा. आधीच संमती दिलेल्या आणि ज्यांची प्रोफाइल तुमच्याकडे आधीपासूनच आहे अशा परत येणाऱ्या पाहुण्यांसाठी, सुलभ रि-ऑथेंटिकेशनसाठी 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 address अधिकृत क्लायंट म्हणून नोंदणीकृत करतो आणि कंट्रोलर त्याला परवानगी देतो. MAC bypass ची अंमलबजावणी करणे सोपे आहे परंतु कमी सुरक्षित आहे, कारण MAC address स्पूफ केले जाऊ शकतात. Purple चे Guest WiFi प्लॅटफॉर्म या दोन्ही यंत्रणा हाताळते. WeChat OAuth पूर्ण झाल्यानंतर, Purple चे क्लाउड ओव्हरले संबंधित हार्डवेअरला योग्य सिग्नल पाठवते - मग ते Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium किंवा Fortinet असो. ठिकाण संचालकाला ते भाषांतर स्वहस्ते व्यवस्थापित करण्याची आवश्यकता नाही. - - - अंमलबजावणीच्या शिफारसी आणि त्रुटी (अंदाजे 2 मिनिटे) WeChat OAuth captive portal अंमलबजावणी अपयशी ठरण्यास कारणीभूत असलेल्या पाच गोष्टी मी तुम्हाला सांगतो. पहिली: redirect URI विसंगती. WeChat तुम्ही प्लॅटफॉर्मवर नोंदणीकृत केलेल्या अधिकृत डोमेनच्या विरुद्ध redirect URI सत्यापित करते. जर तुमचा पोर्टल सर्व्हर भिन्न सबडोमेन, भिन्न मार्ग किंवा HTTPS ऐवजी HTTP वापरत असेल, तर OAuth फ्लो 'error 40029 - invalid code' सह अपयशी ठरतो. तुम्ही वापरत असलेल्या प्रत्येक डोमेन व्हेरिएंटची नोंदणी करा, ज्यामध्ये स्टेजिंग वातावरणाचा देखील समावेश आहे. दुसरी: क्लायंट बाजूचे AppSecret. तुमचे AppSecret कधीही क्लायंट-साइड JavaScript किंवा मोबाईल ॲप बायनरीमध्ये दिसू नये. ते तुमच्या सर्व्हरवर असणे आवश्यक आहे. जर ते उघड झाले, तर कोणीही तुमच्या ॲप्लिकेशनचे सोंग घेऊ शकते आणि तुमच्या वतीने WeChat च्या API ला कॉल करू शकते. तिसरी: गहाळ CSRF संरक्षण. OAuth विनंतीमधील 'state' पॅरामीटर विशेषतः cross-site request forgery रोखण्यासाठी अस्तित्वात आहे. एक क्रिप्टोग्राफिकदृष्ट्या यादृच्छिक 'state' व्हॅल्यू जनरेट करा, ती वापरकर्त्याच्या सेशनमध्ये स्टोअर करा आणि WeChat पुन्हा रिडायरेक्ट करते तेव्हा ती सत्यापित करा. हे वगळल्यास गंभीर सुरक्षा त्रुटी निर्माण होऊ शकते. चौथी: इन-ॲप ब्राउझर डिटेक्शन गॅप. WeChat चा इन-ॲप ब्राउझर एक विशिष्ट युझर एजंट स्ट्रिंग सेट करतो ज्यामध्ये "MicroMessenger" समाविष्ट असते. जर तुमचे पोर्टल हे शोधण्यात आणि योग्य OAuth फ्लो प्रदान करण्यात अपयशी ठरले - इन-ॲप ब्राउझरसाठी Official Account फ्लो, मानक ब्राउझरसाठी Open Platform QR फ्लो - तर वापरकर्त्यांना खराब अनुभव येतो किंवा त्रुटी येते. पाचवी: GDPR आणि PIPL संरेखन. तुम्ही युरोपियन अभ्यागतांना सेवा देत असल्यास, तुम्ही WeChat OAuth द्वारे गोळा करत असलेल्या डेटाला GDPR लागू होतो. जर तुम्ही चीनी अभ्यागतांना सेवा देत असल्यास, तुम्ही त्यांच्या डेटावर कशा प्रकारे प्रक्रिया करता याला चीनचा वैयक्तिक माहिती संरक्षण कायदा - PIPL - लागू होतो. दोन्हीसाठी प्रक्रियेचा कायदेशीर आधार, स्पष्ट हेतू मर्यादा आणि डेटाचे न्यूनीकरण आवश्यक आहे. snsapi_base चे समर्थन करणे snsapi_userinfo च्या तुलनेत डेटा न्यूनीकरण तत्त्वांतर्गत सोपे आहे. तुम्ही जे काही गोळा करता, त्याचा तुमचा कायदेशीर आधार आणि तुमच्या डेटा जतन करण्याचा कालावधी दस्तऐवजीकरण करा. - - - रॅपिड-फायर प्रश्न आणि उत्तरे (अंदाजे 1 मिनिट) प्रश्न: मी ईमेल आणि SMS लॉगिन देणाऱ्या पोर्टलवर WeChat लॉगिन वापरू शकतो का? होय. Purple सह बहुतांश एंटरप्राइझ पोर्टल प्लॅटफॉर्म्स, एकाच पोर्टल पेजवर मल्टिपल ऑथेंटिकेशन पद्धतींना सपोर्ट करतात. इतर पर्यायांसह WeChat हा एक पर्याय म्हणून दिसतो. प्रश्न: WeChat OAuth हे iOS वर काम करते का? होय, पण एका फरकासह. Apple चे App Tracking Transparency फ्रेमवर्क सर्व्हर-साइड OAuth फ्लोवर परिणाम करत नाही. iOS वरील Safari मधील WeChat लॉगिन हे QR कोड फ्लो किंवा रीडायरेक्ट फ्लोद्वारे काम करते. WeChat ॲप स्वतः ऑथेंटिकेशन हाताळते. प्रश्न: WeChat ची API अनुपलब्ध असल्यास काय होते? तुमच्या पोर्टलमध्ये एक पर्यायी व्यवस्था (fallback) असायला हवी. जर WeChat API कॉल टाईम आऊट झाला किंवा एरर आली, तर वापरकर्त्याला पर्यायी लॉगिन पद्धतीकडे रीडायरेक्ट करा. त्यांना रिकामी स्क्रीन दाखवू नका. प्रश्न: मी OpenID चा वापर सातत्यपूर्ण ग्राहक ओळखकर्ता म्हणून करू शकतो का? तुमच्या Official Account अंतर्गत, होय. दिलेल्या वापरकर्त्यासाठी आणि दिलेल्या Official Account साठी OpenID स्थिर असतो. तुमच्याकडे मल्टिपल Official Accounts असल्यास, त्याच वापरकर्त्याचे त्या खात्यांवर वेगवेगळे OpenID असतील. क्रॉस-अकाउंट ओळख रिझोल्यूशनसाठी, WeChat एक UnionID प्रदान करते, ज्यासाठी तुमचे अकाउंट्स Open Platform वर लिंक असणे आवश्यक आहे. --- सारांश आणि पुढील पायऱ्या (अंदाजे १ मिनिट) थोडक्यात सांगायचे तर. Captive Portal साठी WeChat OAuth ऑथेंटिकेशन हा दोन-प्लॅटफॉर्म नोंदणीचा सराव, स्कोपचा निर्णय, नेटवर्क अंमलबजावणीचे एकत्रीकरण आणि अनुपालन पुनरावलोकन आहे. या चार गोष्टी व्यवस्थित करा आणि तुमच्याकडे अशी लॉगिन पद्धत असेल जी कोणत्याही पासवर्डच्या त्रासाशिवाय एक अब्जाहून अधिक संभाव्य अभ्यागतांना सेवा देते. पुढील व्यावहारिक पायऱ्या या आहेत. पहिली, तुमचे अभ्यागत WeChat इन-ॲप ब्राउझरमध्ये पोर्टलचा सामना करतात की मानक मोबाईल ब्राउझरमध्ये हे निश्चित करा - हे तुम्हाला कोणत्या प्लॅटफॉर्म नोंदणीची आवश्यकता आहे हे ठरवते. दुसरी, स्कोप ठरवा - परत येणाऱ्या पाहुण्यांसाठी snsapi_base, संमतीसह पहिल्यांदा नोंदणी करण्यासाठी snsapi_userinfo. तिसरी, तुमचे नेटवर्क हार्डवेअर RADIUS CoA ला सपोर्ट करत असल्याची पुष्टी करा किंवा पर्याय म्हणून MAC बायपास कॉन्फिगर करा. चौथी, तुमच्या प्रायव्हसी नोटीस आणि संमती फ्लोचे GDPR आणि PIPL आवश्यकतांनुसार पुनरावलोकन करा. पाचवी, लाईव्ह जाण्यापूर्वी रीडायरेक्ट URI, स्टेट पॅरामीटर व्हॅलिडेशन आणि इन-ॲप ब्राउझर डिटेक्शन तपासा. जर तुम्हाला पाहायचे असेल की Purple हे २०२४ मध्ये ८०,००० पेक्षा जास्त ठिकाणांवर आणि ४४० दशलक्ष लॉगिनसह एका व्यापक Guest WiFi आणि ॲनालिटिक्स प्लॅटफॉर्मचा भाग म्हणून WeChat OAuth कसे हाताळते - तर purple.ai ला भेट द्या किंवा तुमच्या अकाउंट टीमशी संपर्क साधा. ऐकल्याबद्दल धन्यवाद. --- स्क्रिप्ट समाप्त