Captive Portals साठी WeChat OAuth ऑथेंटिकेशन कसे कॉन्फिगर करावे

CAPTIVE PORTALS साठी WECHAT OAUTH ऑथेंटिकेशन कसे कॉन्फिगर करावे एक Purple तांत्रिक माहितीपत्रक - अंदाजे १० मिनिटे --- प्रस्तावना आणि संदर्भ (अंदाजे १ मिनिट) स्वागत आहे. जर तुम्ही चिनी अभ्यागतांना सेवा देणाऱ्या हॉटेल, रिटेल चेन, स्टेडियम किंवा कॉन्फरन्स सेंटरमधील गेस्ट WiFi साठी जबाबदार असाल, तर हे माहितीपत्रक तुमच्यासाठी आहे. Tencent च्या २०२४ च्या डेटाच्या मते, WeChat चे १.३८ अब्ज मासिक ॲक्टिव्ह युझर्स आहेत. यातील बहुतांश युझर्स चीनमध्ये आहेत, परंतु या प्लॅटफॉर्मचा आंतरराष्ट्रीय स्तरावरही मोठा प्रभाव आहे - युनायटेड स्टेट्समध्ये ४० लाख युझर्स, मलेशियामध्ये १.२ कोटी आणि आग्नेय आशिया, युरोप आणि मध्य पूर्वेमध्ये ही संख्या वाढत आहे. जेव्हा एखादा चिनी पाहुणा तुमच्या WiFi शी कनेक्ट होतो आणि त्याला केवळ ईमेल, Facebook किंवा व्हाउचर कोड असलेला लॉगिन पेज दिसतो, तेव्हा त्यांना लगेच अडथळा जाणवतो. त्यांच्याकडे त्या डिव्हाइसवर स्थानिक ईमेल पत्ता सेट केलेला नसू शकतो. परंतु त्यांच्याकडे WeChat नक्कीच असते. त्यामुळे प्रश्न हा नाही की तुम्ही WeChat लॉगिन ऑफर केले पाहिजे की नाही - तर तो हा आहे की तुम्ही ते योग्यरित्या, सुरक्षितपणे आणि तुम्ही प्रत्यक्षात वापरू शकाल असा फर्स्ट-पार्टी डेटा जनरेट होईल अशा पद्धतीने कसे कॉन्फिगर करता. आज आपण याच विषयावर चर्चा करणार आहोत. आपण OAuth 2.0 फ्लो, तुम्हाला आवश्यक असलेले दोन प्लॅटफॉर्म रजिस्ट्रेशन्स, तुम्ही कोणता डेटा गोळा करता हे ठरवणारा स्कोपचा निर्णय, नेटवर्क-साइड एन्फोर्समेंट मेकॅनिझम आणि २०२६ मध्ये महत्त्वाचे असणारे अनुपालन (compliance) विचार याबद्दल सविस्तर माहिती घेणार आहोत. --- तांत्रिक सखोल विश्लेषण (अंदाजे ५ मिनिटे) चला आर्किटेक्चरपासून सुरुवात करूया. एक captive portal अनऑथेंटिकेटेड डिव्हाइसवरील HTTP ट्रॅफिक अडवते आणि ते पोर्टल सर्व्हरवर - एकतर ऑन-प्रिमाइसेस किंवा क्लाउडवर होस्ट केलेल्या लॉगिन पेजवर रिडायरेक्ट करते. जेव्हा तुम्ही WeChat OAuth जोडता, तेव्हा तुम्ही त्या फ्लोमध्ये थर्ड-पार्टी आयडेंटिटी प्रोव्हाइडर समाविष्ट करत असता. याचा क्रम असा आहे. पाहुणा तुमच्या SSID शी कनेक्ट होतो. ॲक्सेस पॉईंट किंवा वायरलेस कंट्रोलरला समजते की डिव्हाइसचे कोणतेही ऑथेंटिकेटेड सेशन नाही आणि ते सर्व HTTP ट्रॅफिक तुमच्या captive portal URL कडे रिडायरेक्ट करते. पोर्टल पेज लोड होते आणि लॉगिन पर्याय सादर करते - ज्यामध्ये WeChat समाविष्ट आहे. पाहुणा WeChat लॉगिनवर टॅप करतो. तुमचा पोर्टल सर्व्हर ब्राउझरला open.weixin.qq.com वरील WeChat च्या ऑथरायझेशन एंडपॉईंटवर रिडायरेक्ट करतो, ज्यामध्ये तुमचा AppID, रिडायरेक्ट URI, कोडचा रिस्पॉन्स टाईप आणि स्कोप पाठवला जातो. WeChat ऑथेंटिकेशन पूर्णपणे स्वतःच्या सर्व्हरवर हाताळते. जर पाहुणा आधीच त्यांच्या ब्राउझरमध्ये WeChat मध्ये लॉग इन असेल, तर त्यांना संमती स्क्रीन (consent screen) दिसते. जर ते WeChat इन-ॲप ब्राउझर वापरत असतील, तर `snsapi_base` स्कोपसह हा अनुभव सायलेंट असू शकतो - कोणतीही संमतीची सूचना न दाखवता. त्यानंतर WeChat तात्पुरत्या ऑथरायझेशन कोडसह तुमच्या पोर्टलच्या रिडायरेक्ट URI वर परत रिडायरेक्ट करते. तुमचा पोर्टल सर्व्हर तुमचा AppID, AppSecret, कोड आणि 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 वर Website Application रजिस्टर करणे आवश्यक आहे. हे `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 टोकन मिळवणे ओळख सिद्ध करते, परंतु ते नेटवर्क स्वयंचलितपणे उघडत नाही. यशस्वी ऑथेंटिकेशनचे नेटवर्क ॲक्सेसमध्ये रूपांतर करण्यासाठी तुम्हाला एका मेकॅनिझमची आवश्यकता आहे. दोन स्टँडर्ड दृष्टिकोन म्हणजे RFC 3576 मध्ये परिभाषित केलेले RADIUS Change of Authorisation आणि 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 असो. व्हेन्यू ऑपरेटरला ते भाषांतर मॅन्युअली व्यवस्थापित करण्याची आवश्यकता नाही. --- इम्प्लीमेंटेशन शिफारसी आणि त्रुटी (अंदाजे २ मिनिटे) मी तुम्हाला अशा पाच गोष्टी सांगतो ज्यांमुळे WeChat OAuth captive portal इम्प्लीमेंटेशन्स अयशस्वी होतात. पहिले: रिडायरेक्ट URI विसंगती (mismatch). तुम्ही प्लॅटफॉर्मवर रजिस्टर केलेल्या ऑथराइज्ड डोमेनशी WeChat रिडायरेक्ट URI ची पडताळणी करते. जर तुमचा पोर्टल सर्व्हर वेगळा सबडोमेन, वेगळा पाथ किंवा HTTPS ऐवजी HTTP वापरत असेल, तर OAuth फ्लो एरर 40029 - invalid code सह अयशस्वी होतो. तुम्ही वापरत असलेल्या प्रत्येक डोमेन व्हेरिएंटची नोंदणी करा, ज्यामध्ये स्टेजिंग एन्व्हायरनमेंट्सचाही समावेश आहे. दुसरे: क्लायंट-साइडवरील AppSecret. Adhesive AppSecret क्लायंट-साइड JavaScript मध्ये किंवा मोबाईल ॲप बायनरीमध्ये कधीही दिसू नये. ते तुमच्या सर्व्हरवर असले पाहिजे. जर ते उघड झाले, तर कोणीही तुमच्या ॲप्लिकेशनचे सोंग घेऊ शकते आणि तुमच्या वतीने WeChat च्या APIs ला कॉल करू शकते. तिसरे: गहाळ CSRF संरक्षण. OAuth विनंतीमधील स्टेट पॅरामीटर विशेषतः क्रॉस-साइट रिक्वेस्ट फॉर्जरी रोखण्यासाठी अस्तित्वात आहे. एक क्रिप्टोग्राफिकली रँडम स्टेट व्हॅल्यू जनरेट करा, ती युझरच्या सेशनमध्ये स्टोअर करा आणि जेव्हा WeChat परत रिडायरेक्ट करेल तेव्हा तिची पडताळणी करा. हे वगळल्यास तुमच्या सिस्टीममध्ये मोठी असुरक्षितता निर्माण होईल. चौथे: इन-ॲप ब्राउझर डिटेक्शन गॅप. WeChat चा इन-ॲप ब्राउझर "MicroMessenger" समाविष्ट असलेली एक विशिष्ट युझर एजंट स्ट्रिंग सेट करतो. जर तुमच्या पोर्टलने हे शोधले नाही आणि योग्य OAuth फ्लो प्रदान केला नाही - इन-ॲप ब्राउझरसाठी Official Account फ्लो, स्टँडर्ड ब्राउझरसाठी Open Platform QR फ्लो - तर युझर्सना खराब अनुभव किंवा एरर येतो. पाचवे: GDPR आणि PIPL संरेखन (alignment). जर तुम्ही युरोपियन अभ्यागतांना सेवा देत असाल, तर तुम्ही WeChat OAuth द्वारे गोळा करत असलेल्या डेटाला GDPR लागू होतो. जर तुम्ही चिनी अभ्यागतांना सेवा देत असाल, तर तुम्ही त्यांच्या डेटावर कशा प्रकारे प्रक्रिया करता याला चीनचा Personal Information Protection Law - PIPL - लागू होतो. दोन्हीसाठी प्रक्रियेचा कायदेशीर आधार, स्पष्ट हेतू मर्यादा आणि डेटा मिनिमायझेशन आवश्यक आहे. `snsapi_userinfo` च्या तुलनेत डेटा मिनिमायझेशन तत्त्वांतर्गत `snsapi_base` चे समर्थन करणे सोपे आहे. तुम्ही जे काही गोळा कराल, तुमचा कायदेशीर आधार आणि तुमचा रिटेंशन कालावधी दस्तऐवजीकरण (document) करा. --- रॅपिड-फायर प्रश्न आणि उत्तरे (अंदाजे १ मिनिट) प्रश्न: मी ईमेल आणि SMS लॉगिन देखील ऑफर करणाऱ्या पोर्टलवर WeChat लॉगिन वापरू शकतो का? होय. Purple सह बहुतांश एंटरप्राइझ पोर्टल प्लॅटफॉर्म एकाच पोर्टल पेजवर अनेक ऑथेंटिकेशन पद्धतींना सपोर्ट करतात. WeChat इतर पर्यायांसोबत एक पर्याय म्हणून दिसतो. प्रश्न: WeChat OAuth हे iOS वर काम करते का? होय, पण एका फरकसह. Apple चे App Tracking Transparency फ्रेमवर्क सर्व्हर-साइड OAuth फ्लोवर परिणाम करत नाही. iOS वरील Safari मधील WeChat लॉगिन QR कोड फ्लो किंवा रिडायरेक्ट फ्लोद्वारे काम करते. WeChat ॲप स्वतः ऑथेंटिकेशन हाताळते. प्रश्न: जर WeChat चे API अनुपलब्ध असेल तर काय होईल? तुमच्या पोर्टलने फॉलबॅक इम्प्लीमेंट केला पाहिजे. जर WeChat API कॉल टाईम आऊट झाला किंवा एरर आला, तर युझरला पर्यायी लॉगिन पद्धतीवर रिडायरेक्ट करा. त्यांना रिकाम्या स्क्रीनवर सोडू नका. प्रश्न: मी OpenID चा वापर कायमस्वरूपी ग्राहक आयडेंटिफायर म्हणून करू शकतो का? तुमच्या Official Account मध्ये, होय. दिलेल्या युझरसाठी आणि दिलेल्या Official Account साठी OpenID स्थिर असतो. जर तुमच्याकडे एकापेक्षा जास्त Official Accounts असतील, तर त्याच युझरचे वेगवेगळ्या अकाउंट्समध्ये वेगवेगळे OpenIDs असतील. क्रॉस-अकाउंट ओळख रिझोल्यूशनसाठी, WeChat एक UnionID प्रदान करते, ज्यासाठी तुमचे अकाउंट्स Open Platform वर लिंक असणे आवश्यक आहे. --- सारांश आणि पुढील पायऱ्या (अंदाजे १ मिनिट) थोडक्यात सांगायचे तर. captive portals साठी WeChat OAuth ऑथेंटिकेशन हा दोन-प्लॅटफॉर्म रजिस्ट्रेशनचा सराव, स्कोपचा निर्णय, नेटवर्क एन्फोर्समेंट इंटिग्रेशन आणि अनुपालन पुनरावलोकन आहे. या चार गोष्टी योग्य करा आणि तुमच्याकडे अशी लॉगिन पद्धत असेल जी शून्य पासवर्ड अडथळ्यासह अब्जावधी संभाव्य अभ्यागतांना सेवा देते. पुढील व्यावहारिक पायऱ्या या आहेत. पहिले, तुमचे अभ्यागत WeChat इन-ॲप ब्राउझरमध्ये पोर्टलवर येतात की स्टँडर्ड मोबाईल ब्राउझरमध्ये - हे ठरवते की तुम्हाला कोणत्या प्लॅटफॉर्म रजिस्ट्रेशनची आवश्यकता आहे. दुसरे, स्कोप ठरवा - परत येणाऱ्या पाहुण्यांसाठी `snsapi_base`, संमतीसह पहिल्यांदा रजिस्ट्रेशन करण्यासाठी `snsapi_userinfo`. तिसरे, तुमचे नेटवर्क हार्डवेअर RADIUS CoA ला सपोर्ट करत असल्याची खात्री करा किंवा पर्याय म्हणून MAC बायपास कॉन्फिगर करा. चौथे, GDPR आणि PIPL आवश्यकतांनुसार तुमच्या प्रायव्हसी नोटीस आणि संमती फ्लोचे पुनरावलोकन करा. पाचवे, तुम्ही लाईव्ह जाण्यापूर्वी रिडायरेक्ट URI, स्टेट पॅरामीटर व्हॅलिडेशन आणि इन-ॲप ब्राउझर डिटेक्शनची चाचणी घ्या. जर तुम्हाला पाहायचे असेल की Purple एका व्यापक Guest WiFi आणि ॲनालिटिक्स प्लॅटफॉर्मचा भाग म्हणून WeChat OAuth कसे हाताळते - २०२४ मधील ८०,००० व्हेन्यूज आणि ४४ कोटी लॉगिनमध्ये - तर purple.ai ला भेट द्या किंवा तुमच्या अकाउंट टीमशी बोला. ऐकल्याबद्दल धन्यवाद. --- स्क्रिप्ट समाप्त