Integrating WeChat Authentication with Guest WiFi Captive Portals

CÓMO CONFIGURAR LA AUTENTICACIÓN WECHAT OAUTH PARA CAPTIVE PORTALS Un resumen técnico de Purple - Aproximadamente 10 minutos --- INTRODUCCIÓN Y CONTEXTO (aproximadamente 1 minuto) Bienvenido. Si eres el responsable de la red WiFi de invitados en un hotel, cadena de retail, estadio o centro de convenciones que recibe visitantes chinos, este resumen es para ti. WeChat cuenta con 1.38 mil millones de usuarios activos mensuales, de acuerdo con los datos de Tencent de 2024. La gran mayoría se encuentra en China, pero la plataforma también tiene una presencia internacional importante: cuatro millones de usuarios en Estados Unidos, 12 millones en Malasia y un número creciente en el sudeste asiático, Europa y Medio Oriente. Cuando un huésped chino se conecta a tu WiFi y ve una página de inicio de sesión que solo ofrece correo electrónico, Facebook o un código de cupón, se enfrenta a una fricción inmediata. Es posible que no tenga una dirección de correo electrónico local configurada en ese dispositivo. Lo que sí es casi seguro es que tiene WeChat. Por lo tanto, la pregunta no es si debes ofrecer el inicio de sesión con WeChat, sino cómo configurarlo de manera correcta, segura y de forma que genere datos de origen que realmente puedas utilizar. Eso es lo que vamos a cubrir hoy. Analizaremos el flujo de OAuth 2.0, los dos registros de plataforma que necesitas, la decisión de alcance (scope) que determina qué datos recopilas, el mecanismo de aplicación en el lado de la red y las consideraciones de cumplimiento que importan en 2026. --- ANÁLISIS TÉCNICO DETALLADO (aproximadamente 5 minutos) Comencemos con la arquitectura. Un Captive Portal intercepta el tráfico HTTP de un dispositivo no autenticado y lo redirige a una página de inicio de sesión. Esa página se aloja en un servidor de portal, ya sea de forma local o en la nube. Al agregar el inicio de sesión con WeChat OAuth, estás insertando un proveedor de identidad de terceros en ese flujo. Esta es la secuencia. El invitado se conecta a tu SSID. El punto de acceso o el controlador inalámbrico detecta que el dispositivo no tiene una sesión autenticada y redirige todo el tráfico HTTP a la URL de tu Captive Portal. La página del portal se carga y presenta las opciones de inicio de sesión, incluyendo WeChat. El invitado selecciona iniciar sesión con WeChat. El servidor de tu portal redirige el navegador al endpoint de autorización de WeChat, enviando tu App ID, el URI de redireccionamiento, el tipo de respuesta (response type) de código y el alcance (scope). WeChat gestiona la autenticación en su totalidad dentro de sus propios servidores. Si el invitado ya inició sesión en WeChat desde su navegador, verá una pantalla de consentimiento. Si está utilizando el navegador integrado de WeChat, la experiencia puede ser silenciosa con el alcance base snsapi, sin que aparezca ninguna solicitud de consentimiento. Después, WeChat redirige al usuario de vuelta a la URL de redireccionamiento de tu portal con un código de autorización temporal. El servidor de tu portal intercambia ese código por un token de acceso, enviando tu App ID, App Secret, el código y el tipo de concesión (grant type) del código de autorización. WeChat devuelve un token de acceso, un token de actualización (refresh token), el Open ID del usuario y el alcance otorgado. Si solicitaste el alcance de snsapi userinfo, puedes realizar una segunda llamada a la API para recuperar el apodo, avatar, género y ciudad del usuario. Ahora, hablemos de los dos registros de plataforma. Aquí es donde la mayoría de las implementaciones fallan. WeChat tiene dos plataformas de desarrolladores distintas. WeChat Open Platform gestiona las aplicaciones de sitios web y las aplicaciones móviles. WeChat Official Accounts Platform gestiona las cuentas públicas, que es lo que la mayoría de los establecimientos realmente necesitan. Para un Captive Portal que atienda a los usuarios dentro del navegador integrado de WeChat, se necesita una Service Account en la Official Accounts Platform. Una Subscription Account no funcionará, ya que no cuenta con los permisos de autorización de páginas web OAuth. Una Service Account sí los tiene y es compatible tanto con los alcances de snsapi base como de snsapi userinfo. Para un Captive Portal al que se accede desde un navegador móvil estándar fuera de WeChat (Chrome en Android o Safari en iOS), se requiere una Website Application registrada en la Open Platform. Esta utiliza el alcance snsapi login y muestra un código QR que el usuario debe escanear con su aplicación de WeChat. En la práctica, la mayoría de los despliegues en establecimientos utilizan ambos. Un huésped en el WiFi de un hotel podría abrir el portal en Chrome, ver un código QR, escanearlo con WeChat y autenticarse. O bien, podría seguir un enlace dentro de WeChat, acceder al navegador integrado y autenticarse de forma silenciosa con snsapi base. Hablemos de la selección del alcance (scope), ya que este es un punto de decisión fundamental. snsapi base devuelve únicamente el Open ID: un identificador único para ese usuario dentro de su Official Account. No requiere ninguna solicitud de consentimiento del usuario. La autenticación es invisible para el usuario, lo que resulta ideal para huéspedes que regresan y de los que ya tiene un perfil, o para establecimientos donde se busca eliminar cualquier tipo de fricción. snsapi userinfo devuelve el Open ID además del apodo de WeChat del usuario, su foto de perfil, género, configuración de idioma y ciudad. Este requiere una pantalla de consentimiento explícita. La mayoría de los usuarios la aceptan, pero introduce fricción. La elección correcta dependerá de su caso de uso. Para el registro de un huésped nuevo en el que desee crear un perfil, utilice snsapi userinfo y combínelo con una capa de consentimiento que cumpla con el GDPR en su página de portal. Para un huésped que regresa, que ya ha dado su consentimiento y cuyo perfil ya posee, utilice snsapi base para una reautenticación silenciosa. Ahora, pasemos al lado del control de acceso a la red. Obtener un token OAuth demuestra la identidad, pero no abre la red de forma automática. Se necesita un mecanismo para traducir una autenticación exitosa en acceso a la red. Los dos enfoques estándar son RADIUS Change of Authorisation (definido en RFC 3576) y el bypass de dirección MAC. Con RADIUS CoA, el servidor de su portal envía una solicitud CoA al controlador de red después de un OAuth exitoso, y el controlador mueve el dispositivo de la VLAN no autenticada a la VLAN de invitados. Esto funciona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist y la mayoría de los controladores de nivel empresarial. Con el bypass de dirección MAC, el servidor del portal registra la dirección MAC del dispositivo como un cliente autorizado y el controlador lo permite. El bypass de dirección MAC es más sencillo de implementar pero menos seguro, debido a que las direcciones MAC se pueden suplantar.La plataforma de Guest WiFi de Purple maneja ambos mecanismos. Una vez que se completa WeChat OAuth, la capa en la nube de Purple envía la señal adecuada al hardware subyacente, ya sea Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme o Fortinet. El operador del establecimiento no necesita gestionar esa traducción manualmente. --- RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES (aproximadamente 2 minutos) Permítame compartirle los cinco factores que causan que las implementaciones de Captive Portal con WeChat OAuth fallen. Primero: la discrepancia en la URI de redireccionamiento. WeChat valida la URI de redireccionamiento frente al dominio autorizado que registró en la plataforma. Si el servidor de su portal utiliza un subdominio diferente, una ruta distinta o HTTP en lugar de HTTPS, el flujo de OAuth fallará con el error 40029 (código no válido). Registre cada variante de dominio que utilice, incluyendo los entornos de prueba. Segundo: el App Secret en el lado del cliente. Su App Secret nunca debe aparecer en el JavaScript del lado del cliente. Pertenece a su servidor. Si queda expuesto, cualquiera puede suplantar su aplicación y realizar llamadas a las API de WeChat en su nombre. Tercero: la falta de protección CSRF. El parámetro de estado en la solicitud de OAuth existe específicamente para prevenir la falsificación de solicitudes en sitios cruzados. Genere un valor de estado criptográficamente aleatorio, almacénelo en la sesión del usuario y valídelo cuando WeChat redirija de vuelta. Si omite esto, tendrá una vulnerabilidad real. Cuarto: la brecha en la detección del navegador integrado en la aplicación. El navegador integrado de WeChat establece una cadena de agente de usuario específica que contiene MicroMessenger. Si su portal no detecta esto y no ofrece el flujo de OAuth correcto, los usuarios experimentarán una interfaz rota o un error. Quinto: la alineación con GDPR y PIPL. Si atiende a visitantes europeos, se aplica el GDPR. Si atiende a visitantes chinos, se aplica la Ley de Protección de Información Personal de China (PIPL). Ambos exigen una base legal para el procesamiento, una limitación clara de la finalidad y la minimización de datos. El uso de snsapi base es más fácil de justificar bajo los principios de minimización de datos que snsapi userinfo. Independientemente de lo que recopile, documente su base legal y su periodo de retención. --- PREGUNTAS Y RESPUESTAS RÁPIDAS (aproximadamente 1 minuto) ¿Puedo usar el inicio de sesión de WeChat en un portal que también ofrece inicio de sesión por correo electrónico y SMS? Sí. La mayoría de las plataformas de portales empresariales, incluyendo Purple, admiten múltiples métodos de autenticación en la misma página del portal. ¿Funciona WeChat OAuth en iOS? Sí. El inicio de sesión de WeChat en Safari en iOS funciona a través del flujo de código QR o del flujo de redireccionamiento. La propia aplicación de WeChat se encarga de la autenticación. ¿Qué pasa si la API de WeChat no está disponible? Implemente una alternativa de respaldo. Si la llamada a la API de WeChat agota el tiempo de espera o devuelve un error, redirija al usuario a un método de inicio de sesión alternativo. ¿Puedo usar el Open ID como un identificador de cliente persistente? Dentro de su Cuenta Oficial, sí. Para la resolución de identidad entre cuentas en múltiples propiedades, utilice el UnionID en su lugar. --- RESUMEN Y PRÓXIMOS PASOS (aproximadamente 1 minuto) Para resumir. La autenticación WeChat OAuth para Captive Portals es un ejercicio de registro en dos plataformas, una decisión de alcance, una integración de aplicación de red y una revisión de cumplimiento. Haz bien esas cuatro cosas y tendrás un método de inicio de sesión que sirve a más de mil millones de visitantes potenciales con cero fricción de contraseñas. Los siguientes pasos prácticos: determina si tus visitantes se encuentran con el portal dentro del navegador integrado de WeChat o en un navegador móvil estándar. Decide el alcance: snsapi base para visitantes recurrentes, snsapi userinfo para el registro inicial con consentimiento. Confirma que tu hardware de red sea compatible con RADIUS CoA. Revisa tu aviso de privacidad frente a GDPR y PIPL. Prueba la URI de redirección, la validación del parámetro de estado y la detección del navegador integrado antes de entrar en producción. Si quieres ver cómo Purple maneja WeChat OAuth como parte de una plataforma más amplia de WiFi de invitados y análisis (a través de 80,000 establecimientos y 440 millones de inicios de sesión en 2024), visita purple.ai o habla con tu equipo de cuenta. Gracias por escuchar. --- FIN DEL GUION