Integrating WeChat WiFi Authentication: Captive Portal Onboarding for APAC Customers
WeChat cuenta con 1.410 millones de usuarios activos mensuales, lo que lo convierte en la principal identidad digital para los consumidores chinos a nivel mundial. Esta guía explica cómo integrar la autenticación OAuth 2.0 de WeChat en los Captive Portals empresariales para establecimientos de la región APAC, abarcando el registro en la plataforma, la selección de alcances, la aplicación de Change of Authorisation de RADIUS y el cumplimiento del doble marco normativo con el GDPR y la PIPL de China. Está dirigida a directores de TI, arquitectos de red y directores de operaciones de establecimientos que necesiten actuar este trimestre.
Escuchar esta guía
Ver transcripción del podcast
Resumen ejecutivo
Para los establecimientos empresariales que operan en la región APAC, o que atienden a turistas chinos a nivel mundial, la autenticación de WeChat WiFi ya no es opcional. Con 1.410 millones de usuarios activos mensuales a partir de 2025 (fuente: Tencent), WeChat es la identidad digital principal para los consumidores chinos. Un invitado que se conecta a su SSID y solo ve opciones de inicio de sesión por correo electrónico o Facebook se enfrenta a una fricción inmediata. Es casi seguro que tienen WeChat. Es casi seguro que no tienen una dirección de correo electrónico local configurada en ese dispositivo.
Esta guía detalla cómo integrar WeChat OAuth 2.0 en un Captive Portal. Cubrimos los dos registros de plataforma distintos que requiere Tencent, la decisión de alcance que determina qué datos de origen recopila y el mecanismo de Cambio de Autorización (CoA) de RADIUS que traduce un intercambio de OAuth exitoso en acceso real a la red. También abordamos los requisitos de cumplimiento superpuestos de GDPR y la Ley de Protección de Información Personal de China (PIPL).
La plataforma Guest WiFi de Purple automatiza la capa de aplicación de red en hardware de Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Purple opera en más de 80.000 establecimientos activos y registró 440 millones de inicios de sesión en 2024 (datos internos de Purple).
Análisis técnico profundo
El flujo de OAuth 2.0
Un Captive Portal (una pasarela de autenticación basada en web que intercepta el tráfico HTTP de dispositivos no autenticados) redirige a los invitados a una página de inicio de sesión alojada en un servidor de portal, ya sea local o en la nube. Agregar WeChat OAuth inserta la infraestructura de identidad de Tencent en ese flujo.
La secuencia se ejecuta de la siguiente manera. El invitado se asocia con el SSID. El controlador inalámbrico detecta la ausencia de una sesión autenticada y redirige todo el tráfico HTTP a la URL del Captive Portal. La página del portal se carga y presenta opciones de inicio de sesión, incluido WeChat. El invitado selecciona WeChat. El servidor del portal construye una redirección al endpoint de autorización de WeChat en open.weixin.qq.com, pasando cuatro parámetros: el AppID, el URI de redirección, el tipo de respuesta establecido en code y el alcance solicitado.
WeChat autentica al usuario completamente en su propia infraestructura. Si el invitado ya ha iniciado sesión a través del navegador integrado de WeChat, el alcance snsapi_base permite una autenticación silenciosa sin ninguna indicación visible. WeChat redirige de nuevo a la URI de redirección registrada del portal con un código de autorización de corta duración. El servidor del portal intercambia este código por un token de acceso llamando a api.weixin.qq.com/sns/oauth2/access_token con el AppID, AppSecret, el código y el tipo de concesión. WeChat devuelve un token de acceso, un token de actualización, el OpenID del usuario y el alcance concedido. Si se solicitó snsapi_userinfo, una segunda llamada a la API a api.weixin.qq.com/sns/userinfo recupera el apodo del usuario, la imagen de perfil, el género y la ciudad.
Registro en la plataforma: la decisión que complica la mayoría de los despliegues
Tencent opera dos plataformas de desarrolladores independientes, y seleccionar la incorrecta es la causa más común de implementaciones fallidas.
| Contexto de acceso | Registro requerido | URL de la plataforma | Alcances admitidos |
|---|---|---|---|
| Navegador integrado de WeChat | Cuenta de servicio (Plataforma de Cuentas Oficiales) | mp.weixin.qq.com | snsapi_base, snsapi_userinfo |
| Navegador móvil estándar (Chrome, Safari) | Aplicación web (Plataforma abierta) | open.weixin.qq.com | snsapi_login (flujo de código QR) |
Una Cuenta de suscripción en la Plataforma de Cuentas Oficiales no funcionará. Carece de permisos de autorización de páginas web OAuth. Solo una Cuenta de servicio dispone de dichos permisos.
La mayoría de los despliegues empresariales en Hospitality y Retail implementan ambos registros. Un invitado en un hotel podría abrir el portal en Chrome, escanear un código QR con WeChat y autenticarse a través del flujo de la Plataforma abierta. O bien, podría seguir un enlace dentro del propio WeChat, acceder al navegador integrado y autenticarse de forma silenciosa a través del flujo de Cuentas Oficiales. Se deben gestionar ambas rutas.
Selección de alcance y recopilación de datos
El alcance de OAuth es una decisión arquitectónica real, no un detalle de configuración. Determina la fricción que experimenta el usuario y los datos que recibe su plataforma de WiFi Analytics .
snsapi_base devuelve únicamente el OpenID: un identificador único y estable para ese usuario dentro de su Cuenta Oficial. No requiere ninguna solicitud de consentimiento del usuario. La autenticación es invisible. Utilice esta opción para invitados recurrentes cuyos perfiles ya posea, o para entornos de alto rendimiento como estadios y centros de transporte donde la velocidad de conexión es la prioridad.
snsapi_userinfo devuelve el OpenID además del apodo, la imagen de perfil, el género, la configuración de idioma y la ciudad. Activa una pantalla de consentimiento explícito. Utilice esto para el registro de invitados por primera vez para crear un perfil de datos de origen, combinado con una capa de consentimiento que cumpla con PIPL y GDPR en la página del portal.
La regla práctica: use snsapi_base para mayor velocidad, snsapi_userinfo para obtener datos. Puede implementar ambos comprobando si el OpenID del usuario ya existe en su base de datos. Si existe, solicite snsapi_base. Si no, solicite snsapi_userinfo.
Ejecución de red: RADIUS CoA y bypass de MAC
Un token de OAuth demuestra la identidad. No abre la red. Un mecanismo independiente debe traducir la autenticación correcta en un cambio de política de red.
RADIUS Change of Authorisation (CoA), definido en RFC 3576, es el enfoque estándar. Después de que el servidor del portal recibe un token de OAuth válido, envía una solicitud de CoA al controlador inalámbrico. El controlador actualiza la sesión, moviendo el dispositivo de la VLAN de jardín vallado (un segmento de red restringido que solo permite el tráfico del portal) a la VLAN de invitados completa. Esto funciona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet.
El bypass de dirección MAC registra la dirección MAC del dispositivo como un cliente autorizado después de un OAuth correcto. El controlador permite entonces el tráfico desde esa dirección sin más comprobaciones. Es más sencillo de implementar pero conlleva dos riesgos: las direcciones MAC se pueden suplantar, e iOS 14 y Android 10 en adelante utilizan la aleatorización de direcciones MAC de forma predeterminada, lo que rompe el mecanismo al volver a conectarse.
Para cualquier despliegue donde la seguridad sea importante, RADIUS CoA es la opción correcta. Para obtener más información sobre cómo proteger las redes de invitados, consulte What Is Secure WiFi: Essential Guide for Business 2026 y Enterprise WiFi Security: A Complete Guide for 2026 .
Guía de implementación
Lista de comprobación previa al despliegue
Antes de escribir una sola línea de configuración, complete estos cinco pasos.
Primero, determine el contexto de acceso. Analice su establecimiento e identifique si los invitados encontrarán el Captive Portal dentro del navegador integrado de WeChat, en un navegador móvil estándar o en ambos. La respuesta determina los requisitos de registro de su plataforma.
Segundo, regístrese en la plataforma correcta. Para el acceso desde el navegador integrado, cree una cuenta de servicio en la plataforma de cuentas oficiales de WeChat. Para el acceso desde un navegador estándar, registre una aplicación web en la plataforma abierta de WeChat. Anote su AppID y AppSecret para cada una.
Tercero, configure sus URI de redirección. Registre cada dominio y subdominio que utilice su portal, incluidos los entornos de prueba. WeChat aplica una validación de coincidencia exacta. Una discrepancia devuelve el error 40029.
Cuarto, implemente el intercambio de tokens en el lado del servidor. El AppSecret nunca debe aparecer en el código del lado del cliente. Cree un endpoint en el lado del servidor que acepte el código de autorización, lo intercambie por un token y devuelva solo los datos que su portal necesita.
En quinto lugar, implemente el parámetro state para la protección contra CSRF. Genere un valor aleatorio criptográficamente seguro, almacénelo en la sesión del usuario, páselo en la solicitud de OAuth y valídelo al recibir la respuesta.
Pasos de configuración para Ruckus SmartZone
Para los establecimientos que utilizan Ruckus SmartZone, la configuración del portal de WeChat se encuentra en Services and Profiles, luego en Hotspots and Portals y, por último, en la pestaña WeChat. Debe configurar la URL de autenticación (el endpoint de callback de WeChat de su servidor de portal), el destino DNAT (el servidor que gestiona las redirecciones de clientes no autenticados) y el periodo de gracia (el intervalo durante el cual un usuario recientemente desconectado puede volver a conectarse sin tener que volver a autenticarse, que por defecto es de 60 minutos). También debe configurar la lista blanca del walled garden para permitir el tráfico hacia los endpoints de la API de WeChat durante la fase de autenticación. Consulte también la Guía paso a paso: Configuración de controladores inalámbricos Ruijie para portales cautivos de WiFi para invitados para conocer patrones de configuración de controladores similares.
Detección del navegador integrado en la aplicación
El navegador integrado de WeChat establece una cadena de agente de usuario que contiene MicroMessenger. Su portal debe detectar esta cadena y ofrecer el flujo de OAuth adecuado. Si MicroMessenger está presente, utilice el flujo de Official Accounts. Si no lo está, utilice el flujo de código QR de Open Platform. Si no se detecta correctamente, se producirán experiencias de usuario defectuosas o errores de autenticación.
Buenas prácticas
Minimización de datos y cumplimiento del doble marco normativo
El GDPR (aplicable a los visitantes europeos) y la PIPL (aplicable a los ciudadanos chinos) exigen una base jurídica para el tratamiento de datos personales, una limitación clara de la finalidad y la minimización de datos. El alcance snsapi_base es más fácil de justificar bajo los principios de minimización de datos que snsapi_userinfo. Cuando recopile datos demográficos a través de snsapi_userinfo, documente su base jurídica, su periodo de retención y su acuerdo de tratamiento de datos con Tencent.
La PIPL, en vigor desde noviembre de 2021, exige el consentimiento explícito para la información personal sensible y obliga a que los encargados del tratamiento de datos fuera de China implementen normas de protección equivalentes. Si el servidor de su portal se encuentra fuera de China continental, debe evaluar si se aplican las normas de transferencia transfronteriza de datos al OpenID de WeChat y a los datos de perfil que recibe.
UnionID para despliegues en múltiples propiedades
El OpenID es único por usuario y por Official Account. Si gestiona varias Official Accounts en distintas propiedades, el mismo invitado tendrá diferentes OpenID en cada una de ellas. WeChat proporciona un UnionID que se mantiene consistente en todas las cuentas vinculadas al mismo registro de Open Platform. Para cadenas hoteleras, grupos de retail u operadores aeroportuarios que gestionan múltiples establecimientos, implemente la resolución de identidad basada en UnionID desde el principio.
Refuerzo de la seguridad
Almacene el AppSecret en una variable de entorno o en un gestor de secretos, nunca en el código fuente. Rotelo de inmediato si sospecha que ha quedado expuesto. Implemente una limitación de tasa (rate limiting) en su endpoint de intercambio de tokens para evitar abusos. Registre todos los errores de OAuth, especialmente el 40029 (código no válido) y el 40163 (código caducado), ya que indican una configuración incorrecta o un sondeo activo.
Para obtener una visión más amplia de la arquitectura de seguridad de las redes de invitados, consulte Por qué los equipos de WiFi domésticos no deben estar en su red de invitados .
Casos de estudio
Cadena de hoteles de lujo, Singapur
Un hotel de lujo de 350 habitaciones en Singapur que atiende principalmente a un segmento de viajes de negocios chino implementó la autenticación de WeChat WiFi junto con su opción de inicio de sesión por correo electrónico existente. Antes de la implementación, el personal de recepción informaba de una media de 15 quejas de huéspedes al día sobre dificultades para iniciar sesión en el WiFi. Los huéspedes chinos intentaban utilizar direcciones de correo electrónico que no tenían configuradas en sus dispositivos de viaje.
El hotel registró una cuenta de servicio en la plataforma de cuentas oficiales de WeChat y una aplicación web en la plataforma abierta. Configuraron snsapi_userinfo para las conexiones por primera vez y snsapi_base para los huéspedes que regresaban identificados por la dirección MAC. El controlador HPE Aruba se configuró para RADIUS CoA para gestionar la promoción de la sesión.
En un plazo de 30 días, las quejas sobre el inicio de sesión de WiFi de los huéspedes disminuyeron a menos de dos al día. La base de datos de WiFi Analytics del hotel creció en 4.200 perfiles de origen verificados en el primer mes, con datos demográficos a nivel de ciudad que permitieron comunicaciones personalizadas después de la estancia.
Centro comercial internacional, Kuala Lumpur
Un centro comercial de gama alta en Kuala Lumpur, con 12 millones de usuarios de WeChat solo en Malasia, necesitaba una experiencia de incorporación a la red WiFi que cumpliera con las expectativas digitales de su base de compradores. El centro comercial operaba puntos de acceso Cisco Meraki en 180.000 metros cuadrados de superficie comercial.
La implementación utilizó la plataforma Guest WiFi de Purple como capa en la nube, con WeChat OAuth como método de autenticación principal y SMS OTP como alternativa de respaldo. La arquitectura independiente del hardware de Purple gestionó la integración de RADIUS CoA con Cisco Meraki sin necesidad de desarrollo personalizado.
El centro comercial registró un aumento del 34 % en el inicio de sesiones de WiFi en el primer trimestre posterior a la implementación, lo que se atribuyó a la reducción de la fricción en la incorporación de los usuarios de WeChat. Los datos de origen recopilados a través de los flujos de consentimiento de snsapi_userinfo permitieron al equipo de marketing del centro comercial segmentar a los compradores por su ciudad de origen para el envío de campañas personalizadas.
Resolución de problemas y mitigación de riesgos
| Error | Causa | Resolución |
|---|---|---|
| 40029 invalid code | Discrepancia en la URI de redirección o reutilización del código | Verifique que las URI registradas coincidan exactamente; los códigos son de un solo uso |
| 40163 code expired | Intercambio de tokens retrasado más de 5 minutos | Reducir el tiempo de procesamiento en el servidor; implementar lógica de reintento |
| Pantalla en blanco tras la autenticación | RADIUS CoA no configurado o fallando | Verificar la configuración de CoA del controlador y las reglas del cortafuegos en el puerto UDP 3799 |
| La aleatorización de MAC interrumpe el flujo de visitas recurrentes | Aleatorización de MAC en iOS/Android | Migrar al seguimiento de sesiones basado en OpenID; evitar la identificación basada únicamente en MAC |
| snsapi_userinfo devuelve campos vacíos | El usuario ha establecido restricciones de privacidad en WeChat | Gestionar los campos nulos de forma correcta; no requerir datos de perfil para el acceso |
ROI e impacto empresarial
El caso de negocio para la autenticación de WeChat WiFi se basa en tres resultados medibles.
Adquisición de datos de origen (first-party data). Cada autenticación snsapi_userinfo genera un perfil de invitado verificado con datos demográficos. Para un hotel de 200 habitaciones con una ocupación del 70 % y un 40 % de huéspedes chinos, esto representa aproximadamente 20 000 nuevos perfiles verificados al año, cada uno vinculado a una identidad de WeChat que permite un re-engagement continuo.
Reducción de la carga de soporte. Los problemas al iniciar sesión son el principal motivo de las llamadas de soporte de WiFi de los huéspedes. Los establecimientos que añaden la autenticación de WeChat junto con las opciones existentes reportan de manera constante una reducción en las consultas de recepción relacionadas con el WiFi, lo que libera tiempo del personal para interacciones de mayor valor.
Alcance de marketing. Las cuentas oficiales de WeChat permiten a los establecimientos enviar notificaciones push a los seguidores. Se puede invitar a un huésped que se autentica a través de su cuenta oficial a seguirla, creando un canal de comunicación directo que opera dentro del ecosistema de WeChat, donde los consumidores chinos pasan una media de 82 minutos al día (fuente: Walk the Chat).
El plan Engage de Purple amplía esto aún más, permitiendo el envío automatizado de mensajes tras la visita, activadores de fidelización y campañas segmentadas creadas a partir de los datos de origen recopilados en el punto de autenticación de WiFi.
Definiciones clave
Captive Portal
Una pasarela de autenticación basada en web que intercepta el tráfico HTTP de un dispositivo no autenticado y lo redirige a una página de inicio de sesión antes de conceder acceso a la red.
El mecanismo a través del cual se presenta la autenticación de WiFi de invitados a los usuarios. WeChat OAuth es uno de los diversos métodos de autenticación que puede ofrecer un Captive Portal.
OAuth 2.0
Un protocolo de autorización estándar del sector que permite a una aplicación de terceros (el Captive Portal) obtener acceso limitado a un servicio web (WeChat) en nombre de un usuario, sin que este comparta su contraseña con el tercero.
El marco subyacente que hace posible el inicio de sesión con WeChat. El portal nunca ve las credenciales de WeChat del usuario; solo recibe un token que confirma que WeChat lo ha autenticado.
RADIUS CoA
Change of Authorisation (Cambio de Autorización). Un mecanismo definido en el RFC 3576 que permite a un servidor RADIUS modificar dinámicamente los atributos de autorización de sesión de un cliente de red activo, como cambiar la asignación de VLAN.
El mecanismo de ejecución de red que traduce un intercambio exitoso de WeChat OAuth en un acceso real a la red. Sin CoA, el invitado se autentica pero el controlador no sabe que debe abrir la red.
OpenID
Un identificador único asignado por WeChat a un usuario específico para una Cuenta Oficial o Aplicación Web concreta. Es estable entre sesiones pero difiere entre cuentas.
La clave principal utilizada para identificar a un invitado en su base de datos de analíticas de WiFi. Utilice UnionID en su lugar si gestiona varias Cuentas Oficiales y necesita una resolución de identidad entre cuentas.
snsapi_base
Un alcance (scope) de WeChat OAuth que permite la autenticación silenciosa, devolviendo únicamente el OpenID del usuario sin mostrar una solicitud de consentimiento.
Utilícelo para invitados recurrentes o entornos de alto rendimiento donde la velocidad de conexión sea la prioridad. No devuelve datos demográficos más allá del OpenID.
snsapi_userinfo
Un alcance (scope) de WeChat OAuth que devuelve el OpenID del usuario, su apodo, imagen de perfil, género, idioma y ciudad, requiriendo una pantalla de consentimiento explícito del usuario.
Utilícelo para el registro de invitados por primera vez para crear un perfil de datos de origen (first-party data). Debe combinarse con una capa de consentimiento que cumpla con el GDPR y la PIPL.
PIPL
Personal Information Protection Law (Ley de Protección de Información Personal). La legislación integral de privacidad de datos de China, en vigor desde noviembre de 2021, que regula cómo se deben recopilar, procesar y transferir los datos personales de los ciudadanos chinos.
Se aplica a cualquier establecimiento que recopile datos de ciudadanos chinos a través de WeChat OAuth, independientemente de dónde se encuentre el establecimiento. Requiere consentimiento explícito, limitación de la finalidad y minimización de datos.
AppSecret
Una clave criptográfica confidencial emitida por WeChat que autentica su aplicación cuando llama a la API de intercambio de tokens de WeChat.
Debe almacenarse únicamente en el lado del servidor. Su exposición en el código del lado del cliente permite a cualquier parte suplantar su aplicación y realizar llamadas no autorizadas a la API de WeChat.
VLAN
Virtual Local Area Network (Red de Área Local Virtual). Un segmento de red lógico que aísla el tráfico en la capa de enlace de datos, lo que permite que una única red física transporte múltiples flujos de tráfico aislados.
Se utiliza en despliegues de Captive Portal para separar los dispositivos no autenticados (VLAN de jardín vallado) de los invitados autenticados (VLAN de invitados). RADIUS CoA mueve un dispositivo entre VLAN tras una autenticación exitosa.
UnionID
Un identificador de WeChat que se mantiene consistente para un usuario determinado en todas las Cuentas Oficiales y Aplicaciones Web vinculadas al mismo registro de Open Platform.
Esencial para cadenas hoteleras, grupos de distribución y operadores de múltiples establecimientos que necesitan reconocer al mismo invitado en varias propiedades, cada una con su propia Cuenta Oficial.
Ejemplos prácticos
Un hotel de lujo de 200 habitaciones en Singapur utiliza controladores HPE Aruba y atiende a un gran volumen de viajeros de negocios chinos. Quieren recopilar datos demográficos de los huéspedes que los visitan por primera vez y garantizar que los huéspedes que regresan se conecten automáticamente sin volver a ver el portal. ¿Cómo deben configurar la integración de WeChat OAuth?
Paso 1: Registre una cuenta de servicio en la plataforma de cuentas oficiales de WeChat (mp.weixin.qq.com) para gestionar el acceso de los huéspedes al portal dentro del navegador integrado de WeChat. Registre una aplicación web en la plataforma abierta de WeChat (open.weixin.qq.com) para los huéspedes que utilicen navegadores móviles estándar.
Paso 2: Configure el Captive Portal para detectar la cadena de agente de usuario de MicroMessenger. Ofrezca el flujo OAuth de cuentas oficiales para los usuarios del navegador integrado y el flujo de código QR de la plataforma abierta para los usuarios de navegadores estándar.
Paso 3: Para las conexiones por primera vez (sin OpenID existente en la base de datos), solicite el alcance snsapi_userinfo. Presente una pantalla de consentimiento que cumpla con la PIPL antes de la redirección de OAuth. Almacene el OpenID, el apodo, la ciudad y el género devueltos en la base de datos de perfiles de huéspedes.
Paso 4: Para los huéspedes que regresan (el OpenID ya existe en la base de datos), solicite el alcance snsapi_base. Esto realiza la autenticación de forma silenciosa sin que el usuario vea ninguna solicitud.
Paso 5: Configure el controlador HPE Aruba para RADIUS CoA en el puerto UDP 3799. Tras un OAuth correcto, el servidor del portal envía una solicitud CoA para pasar el dispositivo de la VLAN de jardín vallado (walled garden) a la VLAN de invitados.
Paso 6: Implemente el registro de direcciones MAC junto con OpenID para gestionar la detección de huéspedes que regresan. Tenga en cuenta que la aleatorización de MAC requiere OpenID como identificador principal, no solo la dirección MAC.
El equipo de TI de una cadena de tiendas informa de una alta tasa de fallos en los inicios de sesión de WeChat WiFi en tres centros comerciales. Los usuarios se autentican en WeChat pero vuelven a la página del portal con un error. Los registros del portal muestran el error 40029. ¿Cuál es la causa probable y cómo se resuelve?
El error 40029 significa que WeChat rechazó el código de autorización durante el intercambio de tokens. Las dos causas más comunes son una discrepancia en la URI de redirección y la reutilización del código.
Paso 1: Inicie sesión en la consola de desarrollador de WeChat tanto para la plataforma de cuentas oficiales como para la plataforma abierta. Vaya a la configuración de OAuth y enumere todas las URI de redirección registradas.
Paso 2: Compárelas con las URI de redirección reales que utiliza su servidor de portal en producción en las tres ubicaciones. Compruebe si hay diferencias de subdominio (portal.brand.com frente a brand.com), diferencias de protocolo (HTTP frente a HTTPS) y diferencias de ruta (/callback frente a /wechat/callback).
Paso 3: Registre cada variante en la consola de WeChat. WeChat realiza una validación de coincidencia exacta, no una coincidencia de prefijos.
Paso 4: Si las URI coinciden, investigue si el servidor de su portal está intentando reutilizar los códigos de autorización. Los códigos de WeChat son de un solo uso y caducan a los cinco minutos. Si su servidor vuelve a intentar el intercambio de tokens con el mismo código, recibirá el error 40029 en el segundo intento.
Paso 5: Implemente la idempotencia en el endpoint de intercambio de tokens para evitar solicitudes duplicadas.
Preguntas de práctica
Q1. You are deploying a captive portal for a 60,000-capacity stadium hosting international events with a significant Chinese fan base. The priority is getting all attendees online within the first 15 minutes of doors opening to reduce cellular congestion. Marketing data collection is a secondary objective. Which WeChat OAuth scope should you configure, and why?
Sugerencia: Consider the impact of a consent screen displayed to 15,000 simultaneous users on a portal server.
Ver respuesta modelo
Configure snsapi_base scope. This enables silent authentication with no user consent prompt, providing the fastest possible onboarding experience. At stadium scale, a consent screen adds friction that multiplies across thousands of simultaneous connections and can cause portal server load spikes. snsapi_base returns only the OpenID, which is sufficient to log the session and identify returning fans. For first-time fans where you want demographic data, you can prompt for profile completion via a post-connection survey rather than at the authentication gate.
Q2. A network architect on your team proposes storing the WeChat AppSecret in the captive portal's client-side JavaScript to reduce server round-trips by making the token exchange call directly from the browser. Explain why this approach is a critical security failure and what the correct architecture is.
Sugerencia: Consider who can view client-side code and what the AppSecret allows them to do.
Ver respuesta modelo
Storing the AppSecret in client-side JavaScript exposes it to any person who views the page source or intercepts network traffic. The AppSecret authenticates your application to WeChat's API. With it, a malicious actor can impersonate your application, call WeChat's token exchange endpoint with any valid authorisation code, retrieve user OpenIDs and profile data, and potentially exhaust your API rate limits. The correct architecture is a server-side token exchange endpoint. The browser receives the authorisation code from WeChat and passes it to your server. Your server, using the AppSecret stored in an environment variable or secrets manager, exchanges the code for a token and returns only the data the portal needs. The AppSecret never leaves your server.
Q3. Your venue operates three hotel properties in different cities, each with its own WeChat Official Account. A loyalty programme member who has authenticated at all three properties has three different OpenIDs in your database. How do you resolve this into a single guest identity?
Sugerencia: WeChat provides a mechanism for cross-account identity resolution that requires a specific platform configuration.
Ver respuesta modelo
Implement WeChat's UnionID mechanism. Link all three Official Accounts to the same Open Platform registration at open.weixin.qq.com. Once linked, WeChat returns a UnionID alongside the OpenID in the snsapi_userinfo response. The UnionID is consistent for a given user across all accounts linked to the same Open Platform registration. Migrate your database to use UnionID as the primary guest identifier for cross-property records, retaining the per-account OpenID for account-specific API calls. For guests who authenticated before UnionID was implemented, trigger a re-authentication with snsapi_userinfo at their next visit to capture the UnionID.
Q4. After deploying WeChat WiFi authentication at a retail venue running Cisco Meraki access points, guests report that they complete the WeChat login successfully but are returned to the portal page and cannot browse the internet. The portal server logs show successful token retrieval. What is the most likely cause and how do you diagnose it?
Sugerencia: The portal has verified identity. What has not happened yet?
Ver respuesta modelo
The RADIUS Change of Authorisation (CoA) is not completing. The portal server has verified the guest's identity via WeChat OAuth but has not successfully instructed the Cisco Meraki controller to move the device from the walled garden VLAN to the guest VLAN. Diagnose by checking: (1) whether the Meraki controller has RADIUS CoA enabled and the portal server's IP is listed as an authorised CoA client; (2) whether UDP port 3799 is open between the portal server and the controller; (3) the portal server logs for CoA request errors or timeouts; and (4) whether the shared secret configured on both sides matches. If CoA is not supported in your Meraki licence tier, MAC address bypass is the fallback, though it carries the MAC randomisation risk noted in the guide.
Continúe leyendo esta serie
Cómo configurar un Captive Portal en Starlink: guía para establecimientos remotos y marítimos
Esta guía detalla cómo omitir el hardware nativo de Starlink e integrar un Captive Portal gestionado en la nube utilizando equipos de enrutamiento empresariales. Aprenderá a superar la limitación de CGNAT, aplicar la segmentación de VLAN, gestionar las limitaciones de ancho de banda satelital y garantizar el cumplimiento normativo.
Mejores prácticas de Captive Portal: diseño para una alta conversión y cumplimiento normativo
Esta guía técnica ofrece a los responsables de TI, arquitectos de redes y directores de operaciones de establecimientos un plan completo para implementar Captive Portals que equilibren la seguridad de la red con una alta conversión de usuarios. Abarca toda la arquitectura, desde la segmentación de VLAN y la autenticación RADIUS hasta el diseño de consentimiento en conformidad con el GDPR y la selección del método de autenticación. Basada en la experiencia operativa de Purple en más de 80 000 establecimientos y 440 millones de inicios de sesión en 2024, cada recomendación se fundamenta en datos reales de implementación.
Cómo optimizar los captive portals para una máxima seguridad de red y conversión de usuarios
Esta guía proporciona un esquema técnico completo para optimizar los captive portals en entornos empresariales, abarcando la arquitectura de segmentación de red, la selección del método de autenticación, el diseño de consentimiento conforme a la GDPR y la optimización de la conversión. Está dirigida a responsables de TI, arquitectos de red y CTO de hoteles, cadenas de tiendas, estadios y organizaciones del sector público que necesitan equilibrar la seguridad de la red con la captura de datos de primera mano. Purple opera la infraestructura de captive portals en más de 80.000 establecimientos con 440 millones de inicios de sesión en 2024, y los marcos de trabajo aquí presentados reflejan esa experiencia operativa.