Vai al contenuto principale
Italiano

Integrazione dell'autenticazione WeChat con i Captive Portal WiFi per gli ospiti

Questa guida spiega come integrare l'autenticazione WeChat OAuth 2.0 nei Captive Portal WiFi aziendali per gli ospiti. Copre i requisiti di registrazione su doppia piattaforma, la selezione dello scope per l'acquisizione di dati di prima parte, l'applicazione delle policy di rete tramite RADIUS Change of Authorization e la conformità con il GDPR e la PIPL cinese. I gestori di location nei settori hospitality, retail ed eventi troveranno passaggi concreti di implementazione, casi di studio reali e linee guida per il rafforzamento della sicurezza per distribuire il login WeChat su guest WiFi su scala.

📖 8 minuti di lettura📝 1,966 parole🔧 2 esempi pratici❓ 4 domande di esercitazione📚 9 definizioni chiave

Ascolta questa guida

Visualizza trascrizione del podcast
HOW TO CONFIGURE WECHAT OAUTH AUTHENTICATION FOR CAPTIVE PORTALS A Purple Technical Briefing - Approximately 10 Minutes --- INTRODUCTION AND CONTEXT (approximately 1 minute) Welcome. If you are responsible for guest WiFi at a hotel, retail chain, stadium, or conference centre that serves Chinese visitors, this briefing is for you. WeChat has 1.38 billion monthly active users, according to Tencent's 2024 data. The overwhelming majority are in China, but the platform has a meaningful international footprint too - four million users in the United States, 12 million in Malaysia, and growing numbers across Southeast Asia, Europe, and the Middle East. When a Chinese guest connects to your WiFi and sees a login page with only email, Facebook, or a voucher code, they face immediate friction. They may not have a local email address set up on that device. They almost certainly have WeChat. So the question is not whether you should offer WeChat login - it is how you configure it correctly, securely, and in a way that generates first-party data you can actually use. That is what we are going to cover today. We will walk through the OAuth 2.0 flow, the two platform registrations you need, the scope decision that determines what data you collect, the network-side enforcement mechanism, and the compliance considerations that matter in 2026. --- TECHNICAL DEEP-DIVE (approximately 5 minutes) Let us start with the architecture. A captive portal intercepts HTTP traffic from an unauthenticated device and redirects it to a login page. That login page is hosted on a portal server - either on-premises or in the cloud. When you add WeChat OAuth, you are inserting a third-party identity provider into that flow. Here is the sequence. The guest connects to your SSID. The access point or wireless controller detects that the device has no authenticated session and redirects all HTTP traffic to your captive portal URL. The portal page loads and presents login options - including WeChat. The guest taps WeChat login. Your portal server redirects the browser to WeChat's authorisation endpoint, passing your App ID, the redirect URI, the response type of code, and the scope. WeChat handles the authentication entirely on its own servers. If the guest is already logged into WeChat in their browser, they see a consent screen. If they are using the WeChat in-app browser, the experience can be silent with the snsapi base scope - no consent prompt at all. WeChat then redirects back to your portal's redirect URI with a temporary authorisation code. Your portal server exchanges that code for an access token, passing your App ID, App Secret, the code, and grant type of authorisation code. WeChat returns an access token, a refresh token, the user's Open ID, and the scope granted. If you requested snsapi userinfo scope, you can then make a second API call to retrieve the user's nickname, avatar, gender, and city. Now, the two platform registrations. This is where most implementations go wrong. WeChat has two separate developer platforms. The WeChat Open Platform handles website applications and mobile apps. The WeChat Official Accounts Platform handles public accounts - what most venues actually need. For a captive portal serving guests inside the WeChat in-app browser, you need a Service Account on the Official Accounts Platform. A Subscription Account will not work - it does not have OAuth web page authorisation permissions. A Service Account does, and it supports both snsapi base and snsapi userinfo scopes. For a captive portal accessed from a standard mobile browser outside WeChat - Chrome on Android, Safari on iOS - you need a Website Application registered on the Open Platform. This uses snsapi login scope and presents a QR code that the user scans with their WeChat app. In practice, most venue deployments use both. A guest on a hotel's WiFi might open the portal in Chrome, see a QR code, scan it with WeChat, and authenticate. Or they might follow a link in WeChat itself, land in the in-app browser, and authenticate silently with snsapi base. Let us talk about scope selection, because this is a genuine decision point. snsapi base returns only the Open ID - a unique identifier for that user within your Official Account. It requires no user consent prompt. The authentication is invisible to the user. This is ideal for returning guests you have already profiled, or for venues where you want zero friction. snsapi userinfo returns the Open ID plus the user's WeChat nickname, profile picture, gender, language setting, and city. It requires an explicit consent screen. Most users accept, but there is friction. The right choice depends on your use case. For a first-time guest registration where you want to build a profile, use snsapi userinfo and pair it with a GDPR-compliant consent layer on your portal page. For a returning guest who has already consented and whose profile you already hold, use snsapi base for silent re-authentication. Now, the network enforcement side. Getting an OAuth token proves identity, but it does not automatically open the network. You need a mechanism to translate a successful authentication into network access. The two standard approaches are RADIUS Change of Authorisation, defined in RFC 3576, and MAC address bypass. With RADIUS CoA, your portal server sends a CoA request to the network controller after successful OAuth, and the controller moves the device from the unauthenticated VLAN to the guest VLAN. This works with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, and most enterprise-grade controllers. With MAC bypass, the portal server registers the device's MAC address as an authorised client, and the controller allows it. MAC bypass is simpler to implement but less secure, because MAC addresses can be spoofed. Purple's Guest WiFi platform handles both mechanisms. After WeChat OAuth completes, Purple's cloud overlay sends the appropriate signal to the underlying hardware - whether that is Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, or Fortinet. The venue operator does not need to manage that translation manually. --- IMPLEMENTATION RECOMMENDATIONS AND PITFALLS (approximately 2 minutes) Let me give you the five things that cause WeChat OAuth captive portal implementations to fail. First: the redirect URI mismatch. WeChat validates the redirect URI against the authorised domain you registered on the platform. If your portal server uses a different subdomain, a different path, or HTTP instead of HTTPS, the OAuth flow fails with error 40029 - invalid code. Register every domain variant you use, including staging environments. Second: the App Secret on the client side. Your App Secret must never appear in client-side JavaScript. It belongs on your server. If it is exposed, anyone can impersonate your application and call WeChat's APIs on your behalf. Third: missing CSRF protection. The state parameter in the OAuth request exists specifically to prevent cross-site request forgery. Generate a cryptographically random state value, store it in the user's session, and validate it when WeChat redirects back. Skip this and you have a real vulnerability. Fourth: the in-app browser detection gap. WeChat's in-app browser sets a specific user agent string containing MicroMessenger. If your portal does not detect this and serve the correct OAuth flow, users get a broken experience or an error. Fifth: GDPR and PIPL alignment. If you serve European visitors, GDPR applies. If you serve Chinese visitors, China's Personal Information Protection Law - PIPL - applies. Both require a lawful basis for processing, clear purpose limitation, and data minimisation. snsapi base is easier to justify under data minimisation principles than snsapi userinfo. Whatever you collect, document your legal basis and your retention period. --- RAPID-FIRE Q AND A (approximately 1 minute) Can I use WeChat login on a portal that also offers email and SMS login? Yes. Most enterprise portal platforms, including Purple, support multiple authentication methods on the same portal page. Does WeChat OAuth work on iOS? Yes. WeChat login in Safari on iOS works via the QR code flow or redirect flow. The WeChat app itself handles the authentication. What happens if WeChat's API is unavailable? Implement a fallback. If the WeChat API call times out or returns an error, redirect the user to an alternative login method. Can I use the Open ID as a persistent customer identifier? Within your Official Account, yes. For cross-account identity resolution across multiple properties, use the UnionID instead. --- SUMMARY AND NEXT STEPS (approximately 1 minute) To summarise. WeChat OAuth authentication for captive portals is a two-platform registration exercise, a scope decision, a network enforcement integration, and a compliance review. Get those four things right and you have a login method that serves over a billion potential visitors with zero password friction. The practical next steps: determine whether your visitors encounter the portal inside the WeChat in-app browser or in a standard mobile browser. Decide on scope - snsapi base for returning guests, snsapi userinfo for first-time registration with consent. Confirm your network hardware supports RADIUS CoA. Review your privacy notice against GDPR and PIPL. Test the redirect URI, the state parameter validation, and the in-app browser detection before you go live. If you want to see how Purple handles WeChat OAuth as part of a broader Guest WiFi and analytics platform - across 80,000 venues and 440 million logins in 2024 - visit purple.ai or speak to your account team. Thanks for listening. --- END OF SCRIPT

header_image.png

Executive summary

Quando un visitatore cinese si connette alla tua rete aziendale e incontra un Captive Portal che offre solo e-mail, Facebook o un codice coupon, introduci un attrito immediato. WeChat conta 1,38 miliardi di utenti attivi mensili, secondo i dati di Tencent del 2024. L'integrazione delle funzionalità di login WeChat su guest WiFi non è una semplice comodità per l'hospitality, ma un requisito tecnico per acquisire dati di prima parte da questo target demografico senza attriti.

Questa guida descrive in dettaglio l'architettura tecnica per l'integrazione dell'autenticazione WeChat OAuth 2.0 nei Captive Portal. Spiega la registrazione su doppia piattaforma richiesta per supportare sia i browser mobili standard sia il browser in-app di WeChat, valuta i compromessi tra gli scope snsapi_base e snsapi_userinfo per la raccolta dei dati e illustra come applicare l'accesso alla rete utilizzando RADIUS Change of Authorization (CoA) o il bypass dell'autenticazione MAC. Copre inoltre le configurazioni di sicurezza e i mandati di conformità (GDPR e PIPL cinese) necessari per distribuire questa soluzione su scala su infrastrutture Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.

Technical deep-dive: WeChat OAuth 2.0 architecture

Un Captive Portal intercetta il traffico HTTP da un dispositivo non autenticato e lo reindirizza a una pagina di login ospitata su un server del portale. L'aggiunta dell'autenticazione WeChat inserisce un provider di identità di terze parti in questo flusso utilizzando il protocollo OAuth 2.0, lo stesso standard utilizzato da Google, Microsoft Entra ID e Okta per l'identità federata.

oauth_flow_diagram.png

La sequenza di autenticazione funziona come segue. L'ospite si connette all'SSID. L'access point o il controller wireless rileva la sessione non autenticata e reindirizza il traffico HTTP all'URL del Captive Portal. L'ospite seleziona il login WeChat sulla pagina del portale. Il server del portale reindirizza il browser all'endpoint di autorizzazione di WeChat all'indirizzo open.weixin.qq.com, passando l' AppID, l'URI di reindirizzamento, il tipo di risposta code e lo scope richiesto. WeChat gestisce l'autenticazione sui propri server. Se l'ospite utilizza il browser in-app di WeChat con lo scope snsapi_base, l'autenticazione è silenziosa: non viene visualizzata alcuna richiesta di consenso. Se si utilizza snsapi_userinfo, WeChat presenta una schermata di consenso. WeChat reindirizza quindi all'URI di reindirizzamento del portale con un codice di autorizzazione temporaneo. Il server del portale scambia questo codice con un token di accesso chiamando l'API api.weixin.qq.com/sns/oauth2/access_token, passando l' AppID, l' AppSecret, il codice e un tipo di concessione authorization_code. WeChat restituisce un token di accesso, un token di aggiornamento, l'OpenID dell'utente e lo scope concesso. Se è stato concesso snsapi_userinfo, il server effettua una seconda chiamata API per recuperare il nickname, l'avatar, il genere e la città dell'utente.

The dual-platform registration requirement

La maggior parte delle implementazioni fallisce nella fase di registrazione. WeChat gestisce due piattaforme di sviluppo separate e le distribuzioni aziendali in genere richiedono entrambe.

Piattaforma URL Tipo di account richiesto Scope supportato Contesto del browser
Official Accounts Platform mp.weixin.qq.com Service Account snsapi_base, snsapi_userinfo Browser in-app di WeChat
Open Platform open.weixin.qq.com Website Application snsapi_login Browser mobile standard

Per gli ospiti che accedono al portale all'interno del browser in-app di WeChat, è necessario un Service Account sulla Official Accounts Platform. Un Subscription Account non funzionerà: non dispone delle autorizzazioni di autorizzazione della pagina web OAuth. Per gli ospiti che accedono al portale da Chrome su Android o Safari su iOS, è necessaria una Website Application sulla Open Platform, che utilizza lo scope snsapi_login e presenta un codice QR che l'utente deve scansionare.

In pratica, la maggior parte delle installazioni nelle location utilizza entrambe. Un ospite in un hotel potrebbe aprire il portale in Chrome, vedere un codice QR, scansionarlo con WeChat e autenticarsi. Oppure potrebbe seguire un link all'interno di WeChat stesso, atterrare nel browser in-app e autenticarsi silenziosamente con snsapi_base.

Scope selection: data capture vs. friction

scope_comparison.png

Lo scope richiesto determina quali dati vengono raccolti e l'attrito riscontrato dall'ospite. Questo è un vero e proprio punto decisionale con implicazioni di conformità.

snsapi_base restituisce solo l'OpenID, un identificatore univoco per quell'utente all'interno del tuo Official Account. Non richiede alcuna richiesta di consenso da parte dell'utente. L'autenticazione è invisibile per l'ospite. Utilizzalo per gli ospiti di ritorno di cui possiedi già i profili o quando dai la priorità a un accesso senza attriti. Secondo i principi di minimizzazione dei dati del GDPR e della PIPL, snsapi_base è più facile da giustificare.

snsapi_userinfo restituisce l'OpenID più il nickname, l'immagine del profilo, il genere e la città dell'utente. Richiede una schermata di consenso esplicito. Utilizzalo per la registrazione degli ospiti al primo accesso in cui è necessario creare un profilo, abbinato a un livello di consenso conforme sulla pagina del portale.

UnionID for multi-property deployments

L'OpenID è univoco per la combinazione di un utente e uno specifico Official Account. Un gruppo alberghiero con 20 strutture, ciascuna con il proprio Official Account, vedrà 20 OpenID diversi per lo stesso ospite. Il UnionID risolve questo problema. Si tratta di un identificatore unico che rappresenta un utente in tutti gli Official Account e le app collegate allo stesso account Open Platform. Collega i tuoi Official Account al tuo account Open Platform e l'UnionID verrà restituito nella risposta OAuth. Questa è la base di crriconoscimento degli ospiti oss-property.

Guida all'implementazione

Meccanismi di applicazione della rete

L'ottenimento di un token OAuth prova l'identità. Non apre la rete. È necessario segnalare al controller di consentire il traffico.

RADIUS Change of Authorization (CoA), definito in RFC 3576, è l'approccio aziendale consigliato. Dopo un OAuth andato a buon fine, il server del portale invia una richiesta CoA al controller di rete. Il controller sposta il dispositivo dalla VLAN di pre-autenticazione alla VLAN guest. Funziona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.

MAC Authentication Bypass (MAB) registra l'indirizzo MAC del dispositivo come client autorizzato nel database RADIUS. Il controller consente l'accesso in base a tale MAC. MAB è più semplice da implementare ma inaffidabile: i moderni dispositivi iOS e Android randomizzano gli indirizzi MAC per impostazione predefinita, interrompendo l'associazione della sessione alla riconnessione.

La piattaforma Guest WiFi di Purple automatizza questa traduzione. Al completamento di WeChat OAuth, l'overlay cloud di Purple invia il segnale CoA o MAB appropriato all'hardware sottostante, eliminando la configurazione manuale della VLAN.

Configurazione della sicurezza

Tre configurazioni non sono negoziabili.

  1. Proteggere l'AppSecret. L'AppSecret non deve mai apparire nel JavaScript lato client. Deve rimanere sul server. Se esposto, gli aggressori possono impersonare l'applicazione ed effettuare chiamate alle API di WeChat per conto dell'utente.
  2. Implementare la protezione CSRF. Generare un valore state crittograficamente casuale, memorizzarlo nella sessione dell'utente e convalidarlo quando WeChat reindirizza l'utente. Ciò previene gli attacchi di cross-site request forgery come definito in RFC 6749.
  3. Registrare tutte le varianti di URI di reindirizzamento. WeChat convalida l'URI di reindirizzamento rispetto al dominio registrato. Registrare ogni sottodominio e variante di percorso utilizzati, inclusi gli ambienti di staging, per evitare l'errore 40029 (codice non valido).

Rilevamento del browser in-app

Il browser in-app di WeChat imposta una stringa user agent contenente MicroMessenger. Il portale deve rilevare questa stringa e instradare di conseguenza: flusso Official Account per il browser in-app, flusso con codice QR Open Platform per i browser standard. Il mancato rilevamento produce un'esperienza utente interrotta o errori di autenticazione.

hotel_wechat_wifi.png

Best practice e conformità

Conformità GDPR

Se offrite servizi a visitatori europei o operate in Europa, il GDPR si applica ai dati raccolti tramite WeChat OAuth. È necessario stabilire una base giuridica per il trattamento, in genere il consenso o il legittimo interesse. È necessario fornire un'informativa sulla privacy chiara sul Captive Portal prima dell'autenticazione. È necessario soddisfare le richieste di accesso e di cancellazione degli interessati. Per un quadro di conformità dettagliato, consultare The Compliance Playbook: GDPR and Guest WiFi Data Privacy .

Conformità PIPL

La legge cinese sulla protezione delle informazioni personali (PIPL) si applica quando si trattano i dati personali di cittadini cinesi. Come il GDPR, la PIPL richiede una chiara limitazione delle finalità, la minimizzazione dei dati e una base giuridica documentata. snsapi_base è più facile da giustificare nell'ambito della minimizzazione dei dati rispetto a snsapi_userinfo. Qualsiasi dato venga raccolto, documentare la base giuridica e il periodo di conservazione prima della messa in servizio.

Segmentazione della rete

Isolare il traffico WiFi degli ospiti dalla rete aziendale utilizzando la segmentazione VLAN. Gli ospiti autenticati tramite WeChat dovrebbero atterrare in una VLAN guest dedicata con solo accesso a Internet, senza accesso ai sistemi interni. Ciò è in linea con i requisiti PCI DSS per l'isolamento dell'ambiente dei dati dei titolari di carta e con le pratiche generali di sicurezza aziendale. Per ulteriori informazioni sull'architettura di segmentazione, consultare Bandwidth Management: A Practical Guide for 2026 .

Autenticazione di fallback

Se l'API di WeChat non è disponibile, il portale deve reindirizzare a un metodo di acesso alternativo. Non lasciare gli ospiti con una schermata vuota. Un fallback su e-mail o SMS garantisce la continuità. Questo è particolarmente importante per le strutture nei settori Trasporti e Sanità in cui la connettività rappresenta un obbligo di servizio.

Casi di studio reali

Ospitalità: gruppo alberghiero di lusso

Un hotel di lusso da 400 camere a Londra accoglie una percentuale significativa di ospiti provenienti dalla Cina continentale. Il loro Captive Portal esistente richiedeva un indirizzo e-mail e la verifica tramite SMS. I numeri di cellulare cinesi spesso non riescono a ricevere SMS da provider europei e molti ospiti non hanno un'e-mail locale configurata sul proprio dispositivo. Il risultato è stato un tasso di abbandono del 60% sul portale.

L'hotel ha registrato un Service Account sulla Official Accounts Platform e una Website Application sulla Open Platform. Il portale rileva lo user agent MicroMessenger e attiva snsapi_base per gli utenti del browser in-app, connettendoli in meno di tre secondi senza alcuna schermata di consenso. Gli ospiti che arrivano tramite Chrome o Safari vedono un codice QR. Nei soggiorni successivi, lo stesso OpenID viene riconosciuto e l'ospite viene riautenticato in modo silenzioso. Il CRM dell'hotel registra la visita di ritorno, consentendo comunicazioni mirate prima dell'arrivo. Per saperne di più sulla distribuzione del WiFi nel settore dell'ospitalità, consultare Ospitalità .

Retail: analisi dei centri commerciali

Un grande centro commerciale desidera acquisire dati demografici dagli acquirenti cinesi per orientare il mix di locatari e le decisioni di marketing. Hanno bisogno della città di origine, del sesso e della frequenza delle visite. snsapi_base non è sufficiente: è necessario snsapi_userinfo. Il portale richiede l'ambito userinfo completo. L'ospite visualizza una schermata di consenso di WeChat e tocca Consenti. La piattaforma di analisi del centro commerciale, integrata con WiFi Analytics di Purple, riceve un flusso di dati demografici verificati. Il sabato pomeriggio, il 40% degli utenti WiFi proviene da una regione specifica. Quei dati indirizzfornisce informazioni su quali brand approcciare per eventi pop-up. Per saperne di più sulle installazioni WiFi nel settore retail, consulta Retail .

Risoluzione dei problemi e mitigazione dei rischi

I cinque scenari di errore più comuni nelle implementazioni di Captive Portal con OAuth WeChat sono i seguenti.

Mancata corrispondenza del Redirect URI (errore 40029). WeChat convalida il redirect URI rispetto al dominio registrato. Qualsiasi discrepanza di sottodominio, percorso o protocollo fa fallire lo scambio di codice. Registra ogni variante, inclusi gli ambienti di staging.

Esposizione dell'AppSecret. L'inserimento dell'AppSecret nel codice client-side è l'errore di sicurezza più grave in assoluto. Sposta tutta la logica di scambio dei token sul server.

Protezione CSRF mancante. L'omissione della convalida del parametro state rende il portale vulnerabile ad attacchi di tipo cross-site request forgery. Genera un valore crittograficamente casuale per sessione e convalidalo al callback.

Mancato rilevamento del browser in-app. Il mancato rilevamento di MicroMessenger nello user agent comporta l'invio del flusso OAuth errato agli utenti del browser in-app, generando errori.

La randomizzazione dell'indirizzo MAC interrompe le sessioni MAB. I moderni sistemi operativi mobili randomizzano gli indirizzi MAC. Gli ospiti che utilizzano l'autenticazione basata su MAB perderanno la sessione al momento della riconnessione. Passa a RADIUS CoA per una gestione affidabile delle sessioni. Per indicazioni sulla configurazione sicura del WiFi, consulta Cos'è il WiFi sicuro: Guida essenziale per le aziende 2026 .

ROI e impatto sul business

L'implementazione della funzionalità di login WiFi per gli ospiti tramite WeChat ha tre impatti misurabili.

Aumento dei tassi di autenticazione. L'eliminazione del punto di errore della verifica tramite SMS e dell'obbligo di inserimento dell'e-mail aumenta la percentuale di visitatori cinesi che si connettono con successo. Un tasso di abbandono del 60% è un valore di riferimento realistico per i portali senza supporto WeChat.

Qualità dei dati di prima parte. I profili autenticati tramite WeChat includono un OpenID verificato e, con snsapi_userinfo, attributi demografici provenienti direttamente dalla piattaforma social. Questi dati confluiscono nelle piattaforme di analytics per guidare campagne di marketing mirate senza dipendere da cookie di terze parti.

Riduzione dei costi di supporto. Un login senza attriti riduce le chiamate alla reception e al supporto IT da parte di ospiti internazionali che riscontrano problemi di connessione.

Purple opera in oltre 80.000 location e ha gestito 440 milioni di login nel 2024 (dati interni Purple). La piattaforma è certificata ISO 27001, conforme a GDPR e CCPA, e mantiene un uptime del 99,999%. Per le strutture nei settori Retail e Hospitality , l'autenticazione WeChat trasforma la rete da un centro di costo a un canale affidabile per l'acquisizione di dati di prima parte.

Definizioni chiave

Captive portal

A web page that intercepts HTTP traffic from an unauthenticated device and requires the user to interact with it before network access is granted.

The primary interface where the WeChat login option is presented to the guest. The portal server hosts this page and orchestrates the OAuth flow.

OAuth 2.0

An industry-standard authorisation protocol (RFC 6749) that allows a third-party application to obtain limited access to an HTTP service on behalf of a user.

The underlying protocol WeChat uses to pass authentication tokens to the portal server without exposing user credentials. The same protocol used by Microsoft Entra ID, Okta, and Google Workspace.

OpenID

A unique alphanumeric identifier assigned to a specific WeChat user for a specific Official Account.

Used as the primary key to identify returning guests in the WiFi analytics database. Changes per Official Account - use UnionID for cross-property recognition.

UnionID

A single WeChat identifier representing a user across all Official Accounts and apps linked to the same Open Platform account.

Essential for hotel groups, retail chains, and stadium operators with multiple venues who need to recognise the same guest across their entire estate.

RADIUS CoA (Change of Authorization)

An extension to the RADIUS protocol (RFC 3576) that allows a RADIUS server to dynamically change the authorisation attributes of an active session.

The secure method used to move a guest device from an isolated pre-authentication VLAN to the active internet VLAN after successful WeChat login. Supported by Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet.

snsapi_base

A WeChat OAuth scope that returns only the user's OpenID and requires no consent prompt from the user.

The recommended scope for returning guest re-authentication. Easier to justify under GDPR and PIPL data minimisation principles.

snsapi_userinfo

A WeChat OAuth scope that returns the user's OpenID, nickname, avatar, gender, and city, and requires an explicit consent screen.

Used for first-time guest registration where demographic data is required for analytics. Requires documented lawful basis under GDPR and PIPL.

PIPL (Personal Information Protection Law)

China's comprehensive data privacy legislation, effective November 2021, regulating the processing of personal information of natural persons located in China.

Applies when venues process data from Chinese citizens via WeChat OAuth. Requires clear consent, purpose limitation, data minimisation, and a deletion mechanism.

AppSecret

A confidential cryptographic key issued by WeChat during application registration, used to authenticate API calls from the portal server.

Must be stored exclusively on the server side. Exposure in client-side JavaScript allows attackers to impersonate the application and call WeChat APIs maliciously.

Esempi pratici

A 400-room luxury hotel in London has a 60% portal drop-off rate among guests from mainland China. The current portal requires email and SMS verification. The IT Director needs to implement WeChat authentication while maintaining GDPR compliance and network security.

Step 1: Register a Service Account on the WeChat Official Accounts Platform (mp.weixin.qq.com) and a Website Application on the WeChat Open Platform (open.weixin.qq.com). Step 2: Configure the portal to detect the MicroMessenger user agent string. If detected, trigger the snsapi_base OAuth flow for silent authentication. If not detected, present the QR code flow. Step 3: Add a GDPR-compliant privacy notice and consent checkbox to the portal page before the WeChat login button becomes active. The notice must state: data collected (OpenID only), purpose (guest WiFi access and return visit recognition), and retention period. Step 4: After successful OAuth token exchange, the portal server issues a RADIUS CoA request to the Cisco Meraki controller, moving the guest device from the pre-auth VLAN to the segmented guest VLAN. Step 5: Store the OpenID against the device MAC address in the guest database. On subsequent visits, the returning OpenID triggers silent re-authentication.

Commento dell'esaminatore: This approach correctly addresses both the technical and compliance requirements. Using snsapi_base aligns with GDPR data minimisation principles, reducing legal risk while eliminating the SMS verification failure point. RADIUS CoA ensures secure, automated network segmentation. The consent checkbox satisfies the GDPR requirement for a documented lawful basis. The key decision is snsapi_base over snsapi_userinfo - the hotel does not need demographic data for this use case, so collecting it would introduce unnecessary compliance obligations.

A retail mall wants to capture gender and city data from Chinese shoppers via guest WiFi to feed into their analytics platform. They currently use MAC Authentication Bypass for their existing portal running on HPE Aruba hardware.

Step 1: Register a Service Account on the WeChat Official Accounts Platform. Step 2: Configure the portal to use snsapi_userinfo scope to retrieve gender and city. Step 3: Add a clear consent screen explaining the value exchange: free WiFi in return for profile data access. The consent must be explicit and granular under both GDPR and PIPL. Step 4: After authentication, the portal server registers the device's MAC address in the RADIUS database. The HPE Aruba controller permits access via MAB. Step 5: Document the lawful basis (consent), purpose (venue analytics and marketing), and retention period (24 months) in a data processing register. Provide a data deletion mechanism.

Commento dell'esaminatore: The snsapi_userinfo scope correctly retrieves the required demographic data. However, relying on MAB introduces a significant operational risk: iOS 14+ and Android 10+ randomise MAC addresses by default, meaning guests will lose their authenticated session on reconnect and be forced to re-authenticate. The mall should plan to migrate to RADIUS CoA on HPE Aruba to resolve this. The PIPL compliance documentation is not optional - it is a legal requirement for processing data from Chinese citizens, regardless of where the venue is located.

Domande di esercitazione

Q1. You are deploying a captive portal at a stadium. You want returning season ticket holders who have previously authenticated to connect automatically without seeing a login screen on subsequent visits. Which WeChat OAuth scope should you implement for the re-authentication flow, and why?

Suggerimento: Consider which scope allows for silent authentication without prompting the user for consent on each visit.

Visualizza risposta modello

Use snsapi_base. This scope returns only the user's OpenID and requires no consent prompt, enabling silent re-authentication. On the first visit, you store the OpenID against the fan's profile. On subsequent visits, the portal detects the returning OpenID via snsapi_base, confirms the match, and issues a RADIUS CoA to grant access - all without the fan seeing a login screen. This also aligns with GDPR data minimisation principles, as you are not collecting additional data beyond what is needed for the authentication function.

Q2. During testing, your portal successfully redirects to WeChat, the user grants consent, and WeChat redirects back to your portal. However, the portal server logs show OAuth error 40029 (invalid code). What is the most likely configuration error, and how do you resolve it?

Suggerimento: WeChat strictly validates the destination it sends the authorisation code to against a registered list.

Visualizza risposta modello

The most likely cause is a redirect URI mismatch. WeChat validates the redirect URI in the OAuth request against the authorised domain registered on the platform. If the portal server uses a different subdomain, a different path, or HTTP instead of HTTPS, the code exchange fails with error 40029. Resolution: log into the WeChat developer platform, navigate to your Service Account or Website Application settings, and add every redirect URI variant you use - including staging subdomains, different paths, and HTTPS versions. Ensure the redirect_uri parameter in your OAuth request exactly matches one of the registered URIs, including URL encoding.

Q3. An IT manager proposes embedding the WeChat AppSecret in the captive portal's front-end JavaScript to speed up the token exchange process directly from the client browser. Why must you reject this proposal, and what is the correct architecture?

Suggerimento: Consider the security implications of exposing cryptographic keys in publicly accessible code.

Visualizza risposta modello

Reject this proposal. The AppSecret is a confidential cryptographic key. Embedding it in client-side JavaScript exposes it to anyone who views the page source or intercepts network traffic. An attacker can extract the AppSecret and impersonate the application, calling WeChat APIs on the venue's behalf, accessing user data, and potentially compromising the entire Official Account. The correct architecture: the client-side portal page receives the authorisation code from WeChat and forwards it to the portal server via a server-side API call. The portal server holds the AppSecret in a secure environment variable and performs the token exchange with WeChat's API. The AppSecret never leaves the server.

Q4. A hotel group with 15 properties across Europe wants to build a unified guest profile that recognises when the same Chinese guest stays at different properties. Each property has its own WeChat Official Account. What WeChat identifier should they use, and what configuration is required?

Suggerimento: The OpenID is account-specific. There is a different identifier designed for cross-account recognition.

Visualizza risposta modello

Use the UnionID. The OpenID changes per Official Account, so the same guest will have 15 different OpenIDs across 15 accounts. The UnionID is a stable identifier representing a user across all Official Accounts and apps linked to the same Open Platform account. Configuration required: link all 15 Official Accounts to a single WeChat Open Platform account. Once linked, the UnionID is returned in the OAuth response when the user has authorised at least one of the linked accounts. Use the UnionID as the primary key in the guest CRM to build cross-property profiles and recognise returning guests regardless of which property they visit.

Continua a leggere questa serie

Integrazione dell'autenticazione WiFi WeChat: onboarding tramite Captive Portal per i clienti APAC

WeChat conta 1,41 miliardi di utenti attivi mensili, il che lo rende l'identità digitale principale per i consumatori cinesi a livello globale. Questa guida spiega come integrare l'autenticazione WeChat OAuth 2.0 nei Captive Portal aziendali per le sedi APAC, coprendo la registrazione della piattaforma, la selezione dello scope, l'applicazione del RADIUS Change of Authorisation e la conformità al doppio framework con il GDPR e la PIPL cinese. Si rivolge a IT manager, network architect e direttori delle operazioni delle sedi che devono agire in questo trimestre.

Leggi la guida →

Integrazione di Cisco WLC e Catalyst con Purple WiFi: guida passo-passo all'accesso guest

Questa guida descrive in dettaglio l'integrazione passo-passo di Cisco WLC e Catalyst 9800 Wireless con Purple, coprendo il reindirizzamento al Captive Portal per Guest WiFi tramite Central Web Authentication, il WiFi aziendale sicuro per il personale tramite 802.1X EAP-TLS e la segmentazione multi-tenant tramite Cisco Identity Pre-Shared Keys (iPSK) con assegnazione dinamica della VLAN. È scritta per architetti di rete aziendali e direttori della sicurezza IT che distribuiscono l'infrastruttura Cisco nei settori hospitality, retail e grandi spazi pubblici.

Leggi la guida →

Guida alla configurazione SCEP aziendale: autenticazione Wi-Fi basata su certificati per l'istruzione superiore e le grandi reti

Questa guida fornisce un progetto tecnico completo per l'implementazione dell'autenticazione WiFi basata su certificati tramite SCEP. Copre la transizione architetturale dalle chiavi precondivise a EAP-TLS, le sequenze di implementazione sulle piattaforme MDM e le strategie critiche di mitigazione del rischio per le reti su larga scala.

Leggi la guida →