Integración de la autenticación de WeChat con Captive Portals de WiFi para invitados

CÓMO CONFIGURAR LA AUTENTICACIÓN OAUTH DE WECHAT PARA CAPTIVE PORTALS Una sesión informativa técnica de Purple - Aproximadamente 10 minutos --- INTRODUCCIÓN Y CONTEXTO (aproximadamente 1 minuto) Bienvenido. Si es responsable de la WiFi para invitados en un hotel, cadena de tiendas, estadio o centro de conferencias que atiende a visitantes chinos, esta sesión informativa es para usted. WeChat tiene 1380 millones de usuarios activos mensuales, según los datos de Tencent de 2024. La gran mayoría se encuentra en China, pero la plataforma también tiene una presencia internacional significativa: cuatro millones de usuarios en los Estados Unidos, 12 millones en Malasia y un número creciente en el sudeste asiático, Europa y Oriente Medio. Cuando un invitado chino se conecta a su 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. Es casi seguro que tiene WeChat. Por lo tanto, la cuestión no es si debe ofrecer el inicio de sesión con WeChat, sino cómo configurarlo correctamente, de forma segura y de manera que genere datos de primera mano que realmente pueda utilizar. Eso es lo que vamos a cubrir hoy. Repasaremos el flujo de OAuth 2.0, los dos registros de plataforma que necesita, la decisión sobre el alcance (scope) que determina qué datos recopila, el mecanismo de aplicación en el lado de la red y las consideraciones de cumplimiento normativo que importan en 2026. --- TÉCNICA AL DETALLE (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 de inicio de sesión está alojada en un servidor de portal, ya sea local o en la nube. Al añadir el OAuth de WeChat, está introduciendo un proveedor de identidad de terceros en ese flujo. Esta es la secuencia. El invitado se conecta a su SSID. El punto de acceso o controlador inalámbrico detecta que el dispositivo no tiene sesión autenticada y redirige todo el tráfico HTTP a la URL de su Captive Portal. La página del portal se carga y presenta las opciones de inicio de sesión, incluido WeChat. El invitado pulsa en el inicio de sesión de WeChat. El servidor de su portal redirige el navegador al endpoint de autorización de WeChat, pasando su App ID, la URI de redirección, el tipo de respuesta de código y el alcance (scope). WeChat gestiona la autenticación por completo en sus propios servidores. Si el invitado ya ha iniciado sesión en WeChat en su navegador, ve una pantalla de consentimiento. Si utiliza el navegador integrado de WeChat, la experiencia puede ser silenciosa con el alcance snsapi_base, sin ninguna solicitud de consentimiento. A continuación, WeChat redirige de nuevo a la URI de redirección de su portal con un código de autorización temporal. El servidor de su portal intercambia ese código por un token de acceso, pasando su App ID, App Secret, el código y el tipo de concesión de código de autorización. WeChat devuelve un token de acceso, un token de actualización, el OpenID del usuario y el alcance concedido. Si solicitó el alcance snsapi_userinfo, puede realizar una segunda llamada a la API para recuperar el apodo, el avatar, el género y la ciudad del usuario. Ahora, los dos registros de plataforma. Aquí es donde fallan la mayoría de las implementaciones. WeChat tiene dos plataformas de desarrollo independientes. La plataforma abierta (WeChat Open Platform) gestiona aplicaciones de sitios web y aplicaciones móviles. La plataforma de cuentas oficiales (WeChat Official Accounts Platform) gestiona cuentas públicas, que es lo que la mayoría de los establecimientos realmente necesitan. Para un Captive Portal que atiende a invitados dentro del navegador integrado de WeChat, necesita una cuenta de servicio (Service Account) en la plataforma de cuentas oficiales. Una cuenta de suscripción (Subscription Account) no funcionará: no tiene permisos de autorización de páginas web de OAuth. Una cuenta de servicio sí los tiene y admite los alcances snsapi_base y snsapi_userinfo. Para un Captive Portal al que se accede desde un navegador móvil estándar fuera de WeChat (Chrome en Android, Safari en iOS), necesita una aplicación web (Website Application) registrada en la plataforma abierta. Esta utiliza el alcance snsapi_login y presenta un código QR que el usuario escanea con su aplicación WeChat. En la práctica, la mayoría de las implementaciones en establecimientos utilizan ambas. Un invitado en la WiFi de un hotel puede abrir el portal en Chrome, ver un código QR, escanearlo con WeChat y autenticarse. O puede seguir un enlace en el propio WeChat, aterrizar en el navegador integrado y autenticarse silenciosamente con snsapi_base. Hablemos de la selección del alcance (scope), porque este es un verdadero punto de decisión. snsapi_base devuelve solo el OpenID, un identificador único para ese usuario dentro de su cuenta oficial (Official Account). No requiere solicitud de consentimiento del usuario. La autenticación es invisible para el usuario. Esto es ideal para invitados recurrentes de los que ya tiene un perfil, o para establecimientos donde desea cero fricciones. snsapi_userinfo devuelve el OpenID más el apodo de WeChat del usuario, la foto de perfil, el género, la configuración de idioma y la ciudad. Requiere una pantalla de consentimiento explícito. La mayoría de los usuarios la aceptan, pero hay fricción. La elección correcta depende de su caso de uso. Para el registro de un invitado por primera vez en el que desea crear un perfil, utilice snsapi_userinfo y combínelo con una capa de consentimiento que cumpla con GDPR en la página de su portal. Para un invitado recurrente que ya ha dado su consentimiento y cuyo perfil ya posee, utilice snsapi_base para una reautenticación silenciosa. Ahora, el lado de la aplicación de red. Obtener un token OAuth demuestra la identidad, pero no abre la red automáticamente. Necesita un mecanismo para traducir una autenticación correcta en acceso a la red. Los dos enfoques estándar son RADIUS Change of Authorization, definido en RFC 3576, y la omisión de dirección MAC (MAC address bypass). Con RADIUS CoA, el servidor de su portal envía una solicitud CoA al controlador de red tras un OAuth correcto, 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 MAC bypass, el servidor del portal registra la dirección MAC del dispositivo como un cliente autorizado y el controlador lo permite. MAC bypass es más sencillo de implementar pero menos seguro, porque las direcciones MAC se pueden suparentar. La plataforma Guest WiFi de Purple gestiona ambos mecanismos. Una vez completado el OAuth de WeChat, 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 indicarle las cinco cosas que hacen que fallen las implementaciones de Captive Portal con OAuth de WeChat. Primero: la discrepancia en la URI de redirección. WeChat valida la URI de redirección contrastándola con el dominio autorizado que registró en la plataforma. Si el servidor de su portal utiliza un subdominio diferente, una ruta diferente o HTTP en lugar de HTTPS, el flujo OAuth falla con el error 40029 (código no válido). Registre cada variante de dominio que utilice, incluidos los entornos de prueba (staging). Segundo: el AppSecret en el lado del cliente. Su AppSecret nunca debe aparecer en el JavaScript del lado del cliente. Pertenece a su servidor. Si se expone, cualquiera puede suplantar su aplicación y llamar a las API de WeChat en su nombre. Tercero: la falta de protección CSRF. El parámetro state en la solicitud OAuth existe específicamente para evitar la falsificación de solicitudes en sitios cruzados (CSRF). Genere un valor de estado aleatorio criptográficamente, almacénelo en la sesión del usuario y valídelo cuando WeChat redirija de nuevo. Si omite esto, tendrá una vulnerabilidad real. Cuarto: la brecha de detección del navegador integrado. El navegador integrado de WeChat establece una cadena de agente de usuario específica que contiene MicroMessenger. Si su portal no detecta esto y ofrece el flujo OAuth correcto, los usuarios tendrán una experiencia rota o un error. Quinto: la alineación con GDPR y PIPL. Si atiende a visitantes europeos, se aplica GDPR. Si atiende a visitantes chinos, se aplica la Ley de Protección de Información Personal de China (PIPL). Ambas requieren una base jurídica para el tratamiento, una limitación clara de la finalidad y la minimización de datos. snsapi_base es más fácil de justificar bajo los principios de minimización de datos que snsapi_userinfo. Recopile lo que recopile, documente su base jurídica y su período de retención. --- PREGUNTAS Y RESPUESTAS RÁPIDAS (aproximadamente 1 minuto) ¿Puedo utilizar 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, incluida Purple, admiten múltiples métodos de autenticación en la misma página del portal. ¿Funciona el OAuth de WeChat 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 redirección. La propia aplicación WeChat gestiona la autenticación. ¿Qué ocurre si la API de WeChat no está disponible? Implemente una alternativa. 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 utilizar el OpenID como identificador de cliente persistente? Dentro de su cuenta oficial (Official Account), 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 OAuth de WeChat para Captive Portals es un ejercicio de registro en dos plataformas, una decisión de alcance (scope), una integración de aplicación de red y una revisión de cumplimiento normativo. Si hace bien esas cuatro cosas, tendrá un método de inicio de sesión que sirve a más de mil millones de visitantes potenciales con cero fricciones de contraseña. Los pasos prácticos: determine si sus visitantes encuentran el portal dentro del navegador integrado de WeChat o en un navegador móvil estándar. Decida el alcance (scope): snsapi_base para invitados recurrentes, snsapi_userinfo para el registro por primera vez con consentimiento. Confirme que el hardware de su red es compatible con RADIUS CoA. Revise su aviso de privacidad frente a GDPR y PIPL. Pruebe la URI de redirección, la validación del parámetro de estado y la detección del navegador integrado antes de la puesta en marcha. Si desea ver cómo gestiona Purple el OAuth de WeChat como parte de una plataforma más amplia de analítica y WiFi para invitados (Guest WiFi) —en 80 000 establecimientos y 440 millones de inicios de sesión en 2024—, visite purple.ai o hable con su equipo de cuentas. Gracias por su atención. --- FIN DEL GUION