Intégration de l'authentification WeChat WiFi : intégration du Captive Portal pour les clients de la région APAC
WeChat compte 1,41 milliard d'utilisateurs actifs mensuels, ce qui en fait la principale identité numérique des consommateurs chinois dans le monde. Ce guide explique comment intégrer l'authentification WeChat OAuth 2.0 dans les portails captifs d'entreprise pour les sites de la région APAC, en couvrant l'enregistrement de la plateforme, la sélection du périmètre, l'application du RADIUS Change of Authorisation et la conformité au double cadre réglementaire du GDPR et de la PIPL chinoise. Il s'adresse aux responsables informatiques, aux architectes réseau et aux directeurs d'exploitation de sites qui doivent agir ce trimestre.
Video overview
Écouter ce guide
Voir la transcription du podcast
Fait partie de notre série principale : Guide du Captive Portal →
Résumé analytique
Pour les sites d'entreprise opérant dans la région APAC, ou accueillant des touristes chinois à l'échelle mondiale, l'authentification WeChat WiFi n'est plus facultative. Avec 1,41 milliard d'utilisateurs actifs mensuels en 2025 (source : Tencent), WeChat est l'identité numérique principale des consommateurs chinois. Un visiteur qui se connecte à votre SSID et ne voit que des options de connexion par e-mail ou Facebook fait face à une friction immédiate. Il possède presque certainement WeChat. Il n'a presque certainement pas d'adresse e-mail locale configurée sur cet appareil.
Ce guide détaille comment intégrer l'authentification OAuth 2.0 de WeChat dans un captive portal. Nous couvrons les deux enregistrements de plateforme distincts requis par Tencent, le choix de la portée (scope) qui détermine les données de première partie que vous collectez, et le mécanisme de changement d'autorisation (CoA) RADIUS qui convertit un échange OAuth réussi en un accès réseau réel. Nous traitons également des exigences de conformité croisées du GDPR et de la loi chinoise sur la protection des informations personnelles (PIPL).
La plateforme Guest WiFi de Purple automatise la couche d'application réseau sur les équipements Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. Purple opère sur plus de 80 000 sites actifs et a enregistré 440 millions de connexions en 2024 (données internes de Purple).
Analyse technique approfondie
Le flux OAuth 2.0
Un Captive Portal (une passerelle d'authentification Web qui intercepte le trafic HTTP des appareils non authentifiés) redirige les visiteurs vers une page de connexion hébergée sur un serveur de portail, soit sur site, soit dans le cloud. L'ajout de WeChat OAuth insère l'infrastructure d'identité de Tencent dans ce flux.
La séquence se déroule comme suit. Le visiteur s'associe au SSID. Le contrôleur sans fil détecte l'absence de session authentifiée et redirige tout le trafic HTTP vers l'URL du Captive Portal. La page du portail se charge et présente les options de connexion, y compris WeChat. Le visiteur sélectionne WeChat. Le serveur du portail construit une redirection vers le point de terminaison d'autorisation de WeChat à l'adresse open.weixin.qq.com, en transmettant quatre paramètres : l'AppID, l'URI de redirection, le type de réponse défini sur code et la portée (scope) demandée.
WeChat authentifie l'utilisateur entièrement sur sa propre infrastructure. Si le visiteur est déjà connecté via le navigateur intégré à l'application WeChat, la portée snsapi_base permet une authentification silencieuse sans invite visible. WeChat redirige à nouveau vers l'URI de redirection enregistré du portail avec un code d'autorisation à courte durée de vie. Le serveur du portail échange ce code contre un jeton d'accès en appelant api.weixin.qq.com/sns/oauth2/access_token avec l'AppID, l'AppSecret, le code et le type d'octroi (grant type). WeChat renvoie un jeton d'accès, un jeton de rafraîchissement, l'OpenID de l'utilisateur et la portée accordée. Si snsapi_userinfo a été demandé, un second appel API vers api.weixin.qq.com/sns/userinfo récupère le pseudonyme, l'image de profil, le genre et la ville de l'utilisateur.
Enregistrement de la plateforme : la décision qui fait échouer la plupart des déploiements
Tencent exploite deux plateformes de développement distinctes, et choisir la mauvaise est la cause la plus fréquente d'échec des implémentations.
| Contexte d'accès | Enregistrement requis | URL de la plateforme | Portées prises en charge |
|---|---|---|---|
| Navigateur intégré WeChat | Compte de Service (Official Accounts Platform) | mp.weixin.qq.com | snsapi_base, snsapi_userinfo |
| Navigateur mobile standard (Chrome, Safari) | Application Site Web (Open Platform) | open.weixin.qq.com | snsapi_login (flux de code QR) |
Un compte d'abonnement (Subscription Account) sur l'Official Accounts Platform ne fonctionnera pas. Il ne dispose pas des autorisations d'autorisation de page Web OAuth. Seul un compte de service (Service Account) détient ces autorisations.
La plupart des déploiements d'entreprise dans l'Hôtellerie Hospitality et le Commerce de détail Retail implémentent les deux enregistrements. Un client d'un hôtel peut ouvrir le portail dans Chrome, scanner un code QR avec WeChat et s'authentifier via le flux Open Platform. Ou il peut suivre un lien à l'intérieur de WeChat lui-même, arriver sur le navigateur intégré à l'application et s'authentifier silencieusement via le flux Official Accounts. Les deux parcours doivent être gérés.
Sélection de la portée et collecte de données
Le périmètre OAuth est une véritable décision d'architecture, pas un détail de configuration. Il détermine les frictions que l'utilisateur rencontre et les données reçues par votre plateforme de WiFi Analytics.
snsapi_base renvoie uniquement l'OpenID - un identifiant unique et stable pour cet utilisateur au sein de votre Compte Officiel. Il ne nécessite aucune demande de consentement de l'utilisateur. L'authentification est invisible. Utilisez cette option pour les clients existants dont vous possédez déjà le profil, ou pour les environnements à fort trafic comme les stades et les hubs de transport où la vitesse de connexion est la priorité.
snsapi_userinfo renvoie l'OpenID ainsi que le pseudo, l'image de profil, le genre, la langue et la ville. Il déclenche un écran de consentement explicite. Utilisez cette option pour l'inscription des nouveaux clients afin de créer un profil de données de première partie, associé à une couche de consentement conforme à la PIPL et au GDPR sur la page du portail.
La règle pratique : utilisez snsapi_base pour la rapidité, snsapi_userinfo pour les données. Vous pouvez implémenter les deux en vérifiant si l'OpenID de l'utilisateur existe déjà dans votre base de données. Si c'est le cas, demandez snsapi_base. Sinon, demandez snsapi_userinfo.
Application réseau : RADIUS CoA et contournement MAC
Un jeton OAuth prouve l'identité. Il n'ouvre pas le réseau. Un mécanisme distinct doit traduire l'authentification réussie en un changement de politique réseau.
Le RADIUS Change of Authorisation (CoA), défini dans la RFC 3576, est l'approche standard. Une fois que le serveur du portail reçoit un jeton OAuth valide, il envoie une demande CoA au contrôleur sans fil. Le contrôleur met à jour la session, déplaçant l'appareil du VLAN de l'environnement captif (un segment de réseau restreint qui n'autorise que le trafic du portail) vers le VLAN invité complet. Cela fonctionne avec Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, et Fortinet.
Le contournement d'adresse MAC enregistre l'adresse MAC de l'appareil en tant que client autorisé après un OAuth réussi. Le contrôleur autorise ensuite le trafic provenant de cette adresse sans autre vérification. Il est plus simple à mettre en œuvre mais comporte deux risques : les adresses MAC peuvent être usurpées, et iOS 14 et Android 10 et versions ultérieures utilisent par défaut la randomisation des adresses MAC, ce qui interrompt le mécanisme lors de la reconconnexion.
Pour tout déploiement où la sécurité est importante, RADIUS CoA est le bon choix. Pour en savoir plus sur la sécurisation des réseaux d'invités, consultez What Is Secure WiFi: Essential Guide for Business 2026 et Enterprise WiFi Security: A Complete Guide for 2026.
Vous avez des questions sur votre configuration spécifique ?
Notre équipe collabore avec des exploitants de sites, des responsables informatiques et des ingénieurs réseau au sein de 80 000 sites. Réservez un appel de 20 minutes et nous vous montrerons comment d'autres professionnels comme vous ont résolu ce problème.
Guide d'implémentation
Liste de contrôle avant déploiement
Avant d'écrire une seule ligne de configuration, complétez ces cinq étapes.
Tout d'abord, déterminez le contexte d'accès. Examinez votre établissement et identifiez si les clients utiliseront le portail depuis le navigateur intégré à l'application WeChat, depuis un navigateur mobile standard, ou les deux. La réponse détermine vos exigences d'enregistrement sur la plateforme.
Deuxièmement, inscrivez-vous sur la bonne plateforme. Pour un accès via le navigateur intégré à l'application, créez un compte de service sur la WeChat Official Accounts Platform. Pour un accès standard via un navigateur, enregistrez une application web sur la WeChat Open Platform. Notez votre AppID et votre AppSecret pour chacune d'elles.
Troisièmement, configurez vos URI de redirection. Enregistrez chaque domaine et sous-domaine utilisé par votre portail, y compris les environnements de staging. WeChat impose une validation par correspondance exacte. Une non-correspondance renvoie l'erreur 40029.
Quatrièmement, implémentez l'échange de jetons côté serveur. L'AppSecret ne doit jamais apparaître dans le code côté client. Créez un point de terminaison côté serveur qui accepte le code d'autorisation, l'échange contre un jeton et renvoie uniquement les données dont votre portail a besoin.
Cinquièmement, implémentez le paramètre state pour la protection CSRF. Générez une valeur aléatoire sur le plan cryptographique, stockez-la dans la session de l'utilisateur, passez-la dans la requête OAuth et validez-la au retour.
Étapes de configuration pour Ruckus SmartZone
Pour les sites équipés de Ruckus SmartZone, la configuration du portail WeChat se trouve sous Services et Profils, puis Hotspots et Portals, puis l'onglet WeChat. Vous y configurez l'URL d'authentification (le point de terminaison de rappel WeChat de votre serveur de portail), la destination DNAT (le serveur qui gère les redirections des clients non authentifiés) et la période de grâce (la fenêtre pendant laquelle un utilisateur récemment déconnecté peut se reconnecter sans se réauthentifier, fixée par défaut à 60 minutes). Vous configurez également la liste blanche du walled garden pour autoriser le trafic vers les points de terminaison de l'API de WeChat pendant la phase d'authentification. Voir aussi le Step-by-Step Guide: Configuring Ruijie Wireless Controllers for Guest WiFi Captive Portals pour des modèles de configuration de contrôleurs comparables.
Détection du navigateur intégré à l'application
Le navigateur intégré de WeChat définit une chaîne d'agent utilisateur contenant MicroMessenger. Votre portail doit détecter cette chaîne et proposer le flux OAuth approprié. Si MicroMessenger est présent, utilisez le flux Official Accounts. S'il est absent, utilisez le flux de code QR Open Platform. Si cette détection n'est pas effectuée correctement, l'expérience utilisateur sera dégradée ou des erreurs d'authentification surviendront.
Bonnes pratiques
Minimisation des données et conformité au double cadre réglementaire
Le GDPR (applicable aux visiteurs européens) et la PIPL (applicable aux citoyens chinois) exigent tous deux une base légale pour le traitement des données personnelles, une limitation claire des finalités et la minimisation des données. La portée snsapi_base est plus facile à justifier au regard des principes de minimisation des données que snsapi_userinfo. Lorsque vous collectez des données démographiques via snsapi_userinfo, documentez votre base légale, votre durée de conservation et votre accord de traitement des données avec Tencent.
La PILP, en vigueur depuis novembre 2021, exige un consentement explicite pour les données personnelles sensibles et impose aux sous-traitants de données situés hors de Chine de respecter des normes de protection équivalentes. Si votre serveur de portail est hébergé en dehors de la Chine continentale, vous devez évaluer si les règles de transfert de données transfrontalier s'appliquent à l'OpenID WeChat et aux données de profil que vous recevez.
UnionID pour les déploiements multi-établissements
L'OpenID est unique par utilisateur et par compte officiel. Si vous gérez plusieurs comptes officiels sur différents établissements, un même visiteur aura des OpenID différents sur chacun d'eux. WeChat fournit un UnionID qui reste le même pour tous les comptes associés à un même enregistrement Open Platform. Pour les chaînes hôtelières, les groupes de vente au détail ou les gestionnaires d'aéroports exploitant plusieurs sites, il est recommandé d'implémenter la résolution d'identité basée sur l'UnionID dès le départ.
Renforcement de la sécurité
Stockez l'AppSecret dans une variable d'environnement ou un gestionnaire de secrets, jamais dans le code source. Renouvelez-le immédiatement si vous suspectez une exposition. Mettez en place une limitation de débit sur votre point de terminaison d'échange de jetons pour éviter les abus. Enregistrez toutes les erreurs OAuth dans les journaux, en particulier l'erreur 40029 (code invalide) et l'erreur 40163 (code expiré), car elles signalent soit une mauvaise configuration, soit une tentative d'intrusion active.
Pour une vision plus large de l'architecture de sécurité des réseaux invités, consultez Pourquoi les équipements WiFi grand public n'ont pas leur place sur votre réseau invité.
Études de cas
Chaîne d'hôtels de luxe, Singapour
Un hôtel de luxe de 350 chambres à Singapour, accueillant une clientèle d'affaires majoritairement chinoise, a implémenté l'authentification WeChat WiFi en parallèle de leur option de connexion par e-mail existante. Avant cette mise en œuvre, le personnel de la réception signalait en moyenne 15 plaintes de clients par jour concernant des difficultés de connexion au WiFi. Les clients chinois tentaient d'utiliser des adresses e-mail qu'ils n'avaient pas configurées sur leurs appareils mobiles.
L'hôtel a enregistré un compte de service sur la plateforme de comptes officiels WeChat ainsi qu'une application de site Web sur l'Open Platform. Ils ont configuré snsapi_userinfo pour les premières connexions et snsapi_base pour les clients de retour identifiés par leur adresse MAC. Le contrôleur HPE Aruba a été configuré pour RADIUS CoA afin de gérer l'évolution des sessions.
En l'espace de 30 jours, les plaintes liées à la connexion au WiFi invité sont tombées à moins de deux par jour. La base de données WiFi Analytics de l'hôtel s'est enrichie de 4 200 profils propriétaires vérifiés dès le premier mois, les données démographiques au niveau de la ville permettant des communications ciblées après le séjour.
Centre commercial international, Kuala Lumpur
Un centre commercial haut de gamme situé à Kuala Lumpur, comptant 12 millions d'utilisateurs WeChat rien qu'en Malaisie, avait besoin d'une expérience d'accès au WiFi correspondant aux attentes numériques de sa clientèle. Le centre commercial exploitait des points d'accès Cisco Meraki sur 180 000 mètres carrés de surface commerciale. Le déploiement a utilisé la plateforme de Guest WiFi de Purple en tant qu'overlay cloud, avec WeChat OAuth comme méthode d'authentification principale et le SMS OTP comme solution de repli. L'architecture matérielle agnostique de Purple a géré l'intégration RADIUS CoA avec Cisco Meraki sans nécessiter de développement personnalisé.
Le centre commercial a enregistré une augmentation de 34 % des démarrages de sessions WiFi au cours du premier trimestre suivant le déploiement, attribuée à la réduction des frictions lors de l'accès pour les utilisateurs de WeChat. Les données de première main collectées via les flux de consentement snsapi_userinfo ont permis à l'équipe marketing du centre commercial de segmenter les acheteurs par ville d'origine pour la diffusion de campagnes ciblées.
Dépannage et atténuation des risques
| Erreur | Cause | Résolution |
|---|---|---|
| 40029 code invalide | Non-correspondance de l'URI de redirection ou réutilisation du code | Vérifier que les URI enregistrées correspondent exactement ; les codes sont à usage unique |
| 40163 code expiré | Échange de jetons retardé au-delà de 5 minutes | Réduire le temps de traitement côté serveur ; implémenter une logique de tentative |
| Écran vide après l'authentification | RADIUS CoA non configuré ou en échec | Vérifier les paramètres CoA du contrôleur et les règles de pare-feu sur le port UDP 3799 |
| La randomisation MAC interrompt le flux des visiteurs récurrents | Randomisation MAC iOS/Android | Migrer vers un suivi de session basé sur OpenID ; éviter l'identification uniquement par adresse MAC |
| snsapi_userinfo renvoie des champs vides | L'utilisateur a configuré des restrictions de confidentialité sur WeChat | Gérer les champs nuls avec élégance ; ne pas exiger les données de profil pour l'accès |
ROI et impact commercial
L'intérêt commercial de l'authentification WiFi WeChat repose sur trois résultats mesurables.
Acquisition de données de première main. Chaque authentification snsapi_userinfo génère un profil visiteur vérifié avec des données démographiques. Pour un hôtel de 200 chambres fonctionnant à 70 % d'occupation avec 40 % de clients chinois, cela représente environ 20 000 nouveaux profils vérifiés par an, chacun lié à une identité WeChat qui permet un réengagement continu.
Réduction de la charge de support. Les frictions lors de la connexion sont la principale cause des appels au support pour le WiFi des visiteurs. Les établissements qui ajoutent l'authentification WeChat aux côtés des options existantes signalent systématiquement une réduction des demandes liées au WiFi à la réception, libérant du temps pour le personnel pour des interactions à plus forte valeur ajoutée.
Portée marketing. Les comptes officiels WeChat permettent aux établissements d'envoyer des notifications aux abonnés. Un visiteur qui s'authentifie via votre compte officiel peut être invité à s'y abonner, créant ainsi un canal de communication direct qui fonctionne au sein de l'écosystème de WeChat, où les consommateurs chinois passent en moyenne 82 minutes par jour (source : Walk the Chat).
L'abonnement Purple Engage va encore plus loin, en permettant l'envoi de messages automatisés après la visite, des déclencheurs de fidélité et des campagnes segmentées basées sur les données de première main collectées au moment de l'authentification WiFi.
Définitions clés
Captive Portal
Une passerelle d'authentification Web qui intercepte le trafic HTTP d'un appareil non authentifié et le redirige vers une page de connexion avant d'autoriser l'accès au réseau.
Le mécanisme par lequel l'authentification WiFi invité est présentée aux utilisateurs. WeChat OAuth est l'une des nombreuses méthodes d'authentification qu'un Captive Portal peut proposer.
OAuth 2.0
Un protocole d'autorisation standard du marché qui permet à une application tierce (le Captive Portal) d'obtenir un accès limité à un service Web (WeChat) au nom d'un utilisateur, sans que ce dernier n'ait à partager son mot de passe avec le tiers.
Le framework sous-jacent qui permet la connexion avec WeChat. Le portail ne voit jamais les identifiants WeChat de l'utilisateur - il reçoit uniquement un jeton confirmant que WeChat l'a authentifié.
RADIUS CoA
Change of Authorisation. Un mécanisme défini dans la norme RFC 3576 qui permet à un serveur RADIUS de modifier de manière dynamique les attributs d'autorisation de session d'un client réseau actif, comme le changement d'attribution de VLAN.
Le mécanisme d'application réseau qui convertit un échange WeChat OAuth réussi en un accès réseau effectif. Sans CoA, l'invité s'authentifie mais le contrôleur ne sait pas qu'il doit ouvrir le réseau.
OpenID
Un identifiant unique attribué par WeChat à un utilisateur spécifique pour un compte officiel ou une application Web spécifique. Il reste stable d'une session à l'autre mais diffère d'un compte à l'autre.
La clé principale utilisée pour identifier un invité dans votre base de données d'analyses WiFi. Utilisez plutôt UnionID si vous gérez plusieurs comptes officiels et avez besoin d'une résolution d'identité multicompte.
snsapi_base
Un scope WeChat OAuth qui permet une authentification transparente, renvoyant uniquement l'OpenID de l'utilisateur sans afficher de demande de consentement.
À utiliser pour les invités récurrents ou les environnements à fort trafic où la vitesse de connexion est la priorité. Ne renvoie aucune donnée démographique au-delà de l'OpenID.
snsapi_userinfo
Un scope WeChat OAuth qui renvoie l'OpenID, le pseudo, l'image de profil, le genre, la langue et la ville de l'utilisateur, nécessitant l'affichage d'un écran de consentement explicite de l'utilisateur.
À utiliser pour l'inscription initiale des invités afin de créer un profil de données propriétaires. Doit être associé à un parcours de consentement conforme au GDPR et à la PIPL.
PIPL
Personal Information Protection Law. La législation complète de la Chine sur la protection de la vie privée des données, en vigueur depuis novembre 2021, régissant la manière dont les données personnelles des citoyens chinois doivent être collectées, traitées et transférées.
S'applique à tout établissement qui collecte des données auprès de citoyens chinois via WeChat OAuth, quel que soit l'emplacement physique de cet établissement. Requiert un consentement explicite, une limitation des finalités et la minimisation des données.
AppSecret
Une clé cryptographique confidentielle émise par WeChat qui authentifie votre application lorsqu'elle appelle l'API d'échange de jetons de WeChat.
Doit être stocké uniquement côté serveur. Son exposition dans le code côté client permet à quiconque d'usurper l'identité de votre application et d'effectuer des appels API non autorisés vers WeChat.
VLAN
Virtual Local Area Network. Un segment de réseau logique qui isole le trafic au niveau de la couche de liaison de données, permettant à un seul réseau physique de transporter plusieurs flux de trafic isolés.
Utilisé dans les déploiements de Captive Portal pour séparer les appareils non authentifiés (VLAN walled garden) des invités authentifiés (VLAN invité). Le RADIUS CoA déplace un appareil d'un VLAN à l'autre une fois l'authentification réussie.
UnionID
Un identifiant WeChat qui reste cohérent pour un utilisateur donné sur l'ensemble des comptes officiels et des applications Web liés au même enregistrement sur l'Open Platform.
Indispensable pour les chaînes hôtelières, les groupes de distribution et les exploitants de sites multiples qui ont besoin de reconnaître le même invité à travers plusieurs établissements, chacun disposant de son propre compte officiel.
Exemples concrets
Un hôtel de luxe de 200 chambres à Singapour utilise des contrôleurs HPE Aruba et accueille un volume important de voyageurs d'affaires chinois. Ils souhaitent collecter des données démographiques auprès des nouveaux clients et s'assurer que les clients de retour se connectent automatiquement sans voir à nouveau le portail. Comment doivent-ils configurer l'intégration de WeChat OAuth ?
Étape 1 : Enregistrez un compte de service sur la plateforme WeChat Official Accounts (mp.weixin.qq.com) pour gérer les clients accédant au portail depuis le navigateur intégré à l'application WeChat. Enregistrez une application de site web sur la plateforme WeChat Open Platform (open.weixin.qq.com) pour les clients utilisant des navigateurs mobiles standard.
Étape 2 : Configurez le Captive Portal pour détecter la chaîne d'agent utilisateur MicroMessenger. Proposez le flux OAuth Official Accounts pour les utilisateurs du navigateur intégré à l'application et le flux de code QR Open Platform pour les utilisateurs de navigateurs standard.
Étape 3 : Pour les premières connexions (aucun OpenID existant dans la base de données), demandez le périmètre snsapi_userinfo. Présentez un écran de consentement conforme à la PIPL avant la redirection OAuth. Stockez l'OpenID, le pseudo, la ville et le genre renvoyés dans la base de données des profils clients.
Étape 4 : Pour les clients de retour (l'OpenID existe dans la base de données), demandez le périmètre snsapi_base. Cela permet de s'authentifier silencieusement, sans invite visible par l'utilisateur.
Étape 5 : Configurez le contrôleur HPE Aruba pour le RADIUS CoA sur le port UDP 3799. Une fois l'authentification OAuth réussie, le serveur du portail envoie une demande CoA pour faire passer l'appareil du VLAN restreint au VLAN invité.
Étape 6 : Mettez en œuvre la journalisation des adresses MAC en parallèle avec l'OpenID pour gérer la détection des clients de retour. Notez que la randomisation des adresses MAC nécessite l'OpenID comme identifiant principal, et non l'adresse MAC seule.
L'équipe informatique d'une chaîne de magasins signale un taux d'échec élevé pour les connexions WeChat WiFi dans trois centres commerciaux. Les utilisateurs s'authentifient dans WeChat mais sont renvoyés vers la page du portail avec une erreur. Les journaux du portail affichent l'erreur 40029. Quelle est la cause probable et comment la résoudre ?
L'erreur 40029 signifie que WeChat a rejeté le code d'autorisation lors de l'échange de jetons. Les deux causes les plus fréquentes sont une non-correspondance de l'URI de redirection et la réutilisation du code.
Étape 1 : Connectez-vous à la console développeur WeChat pour la plateforme Official Accounts et la plateforme Open Platform. Accédez aux paramètres OAuth et listez tous les URI de redirection enregistrés.
Étape 2 : Comparez-les aux URI de redirection réels que votre serveur de portail utilise en production sur les trois sites. Vérifiez les différences de sous-domaine (portal.brand.com vs brand.com), les différences de protocole (HTTP vs HTTPS) et les différences de chemin (/callback vs /wechat/callback).
Étape 3 : Enregistrez chaque variante dans la console WeChat. WeChat effectue une validation par correspondance exacte, et non par correspondance de préfixe.
Étape 4 : Si les URI correspondent, recherchez si votre serveur de portail tente de réutiliser des codes d'autorisation. Les codes WeChat sont à usage unique et expirent après cinq minutes. Si votre serveur réessaie l'échange de jetons avec le même code, il recevra l'erreur 40029 lors de la seconde tentative.
Étape 5 : Mettez en œuvre l'idempotence dans le point de terminaison d'échange de jetons pour éviter les requêtes en doublon.
Questions d'entraînement
Q1. Vous déployez un Captive Portal pour un stade d'une capacité de 60 000 personnes accueillant des événements internationaux avec une base importante de supporters chinois. La priorité est de connecter tous les participants dans les 15 premières minutes suivant l'ouverture des portes afin de réduire la congestion du réseau cellulaire. La collecte de données marketing est un objectif secondaire. Quel scope OAuth WeChat devez-vous configurer, et pourquoi ?
Conseil : Pensez à l'impact d'un écran de consentement affiché simultanément à 15 000 utilisateurs sur le serveur du portail.
Voir la réponse type
Configurez le scope snsapi_base. Cela permet une authentification silencieuse sans invite de consentement de l'utilisateur, offrant ainsi l'expérience d'intégration la plus rapide possible. À l'échelle d'un stade, un écran de consentement ajoute des frictions qui se multiplient à travers des milliers de connexions simultanées et peut provoquer des pics de charge sur le serveur du portail. Le scope snsapi_base ne renvoie que l'OpenID, ce qui est suffisant pour enregistrer la session et identifier les supporters de retour. Pour les nouveaux supporters dont vous souhaitez obtenir des données démographiques, vous pouvez proposer de compléter leur profil via un questionnaire post-connexion plutôt qu'au moment de l'authentification.
Q2. Un architecte réseau de votre équipe propose de stocker l'AppSecret WeChat dans le JavaScript côté client du Captive Portal pour réduire les allers-retours avec le serveur en effectuant l'appel d'échange de token directement depuis le navigateur. Expliquez pourquoi cette approche constitue une faille de sécurité critique et quelle est l'architecture correcte.
Conseil : Pensez à qui peut visualiser le code côté client et à ce que l'AppSecret permet de faire.
Voir la réponse type
Le stockage de l'AppSecret dans le JavaScript côté client l'expose à toute personne qui consulte la source de la page ou intercepte le trafic réseau. L'AppSecret authentifie votre application auprès de l'API de WeChat. Grâce à lui, un acteur malveillant peut usurper l'identité de votre application, appeler le point de terminaison d'échange de token de WeChat avec n'importe quel code d'autorisation valide, récupérer les OpenID et les données de profil des utilisateurs, et potentiellement épuiser vos limites de débit d'API. L'architecture correcte consiste à utiliser un point de terminaison d'échange de token côté serveur. Le navigateur reçoit le code d'autorisation de WeChat et le transmet à votre serveur. Votre serveur, en utilisant l'AppSecret stocké dans une variable d'environnement ou un gestionnaire de secrets, échange le code contre un token et ne renvoie que les données dont le portail a besoin. L'AppSecret ne quitte jamais votre serveur.
Q3. Votre établissement gère trois hôtels dans différentes villes, chacun disposant de son propre compte officiel WeChat. Un membre du programme de fidélité qui s'est authentifié dans les trois établissements possède trois OpenID différents dans votre base de données. Comment résolvez-vous cela en une seule identité client ?
Conseil : WeChat fournit un mécanisme de résolution d'identité multicompte qui nécessite une configuration spécifique de la plateforme.
Voir la réponse type
Implémentez le mécanisme UnionID de WeChat. Associez les trois comptes officiels au même enregistrement Open Platform sur open.weixin.qq.com. Une fois liés, WeChat renvoie un UnionID aux côtés de l'OpenID dans la réponse snsapi_userinfo. L'UnionID est identique pour un utilisateur donné sur tous les comptes liés au même enregistrement Open Platform. Migrez votre base de données pour utiliser l'UnionID comme identifiant client principal pour les dossiers multi-établissements, tout en conservant l'OpenID par compte pour les appels d'API spécifiques à chaque compte. Pour les clients qui se sont authentifiés avant la mise en œuvre de l'UnionID, déclenchez une réauthentification avec snsapi_userinfo lors de leur prochaine visite afin de capturer l'UnionID.
Q4. Après avoir déployé l'authentification WiFi WeChat dans un point de vente équipé de points d'accès Cisco Meraki, les clients signalent qu'ils réussissent la connexion WeChat mais sont renvoyés vers la page du portail et ne peuvent pas naviguer sur Internet. Les journaux du serveur du portail indiquent une récupération réussie du token. Quelle est la cause la plus probable et comment la diagnostiquer ?
Conseil : Le portail a vérifié l'identité. Qu'est-ce qui ne s'est pas encore produit ?
Voir la réponse type
La modification d'autorisation (CoA) RADIUS ne se finalise pas. Le serveur de portail a vérifié l'identité de l'invité via WeChat OAuth mais n'a pas réussi à demander au contrôleur Cisco Meraki de déplacer l'appareil du VLAN d'isolement (walled garden) vers le VLAN invité. Pour diagnostiquer, vérifiez : (1) si le contrôleur Meraki a activé la CoA RADIUS et si l'IP du serveur de portail est répertoriée comme un client CoA autorisé ; (2) si le port UDP 3799 est ouvert entre le serveur de portail et le contrôleur ; (3) les journaux du serveur de portail pour détecter des erreurs de requête CoA ou des expirations de délai ; et (4) si le secret partagé configuré des deux côtés correspond. Si la CoA n'est pas prise en charge dans votre niveau de licence Meraki, le contournement par adresse MAC est la solution de repli, bien qu'il comporte le risque de randomisation des adresses MAC mentionné dans le guide.
Continuer la lecture de cette série
Le portail captif Ubiquiti UniFi ne redirige pas : causes et correctifs
Ce guide isole un échec de redirection du portail captif UniFi en suivant dans l'ordre l'état de l'invité, la redirection, la route de pré-autorisation et l'autorisation du contrôleur. Il offre aux équipes informatiques des sites une méthode éprouvée pour résoudre la confusion entre réseau invité et Hotspot, les transferts vers un portail externe, les exigences actuelles de compte UniFi OS et les tests d'isolation DNS.
La page splash Cisco Meraki ne fonctionne pas : un organigramme de dépannage
Ce guide pratique de niveau 2 permet d'isoler l'endroit où un flux de splash Cisco Meraki a échoué : autorisation du client, initiation de la redirection HTTP, accessibilité du walled garden ou authentification RADIUS. Il offre aux équipes informatiques des sites un parcours de vérification contrôlé pour restaurer le WiFi invité sans modifier l'ensemble du parc de production.
Guide de configuration d'un réseau Guest WiFi d'entreprise : segmentation VLAN, sécurité et portails captifs
Ce guide technique explique aux équipes informatiques comment configurer un réseau Guest WiFi en tant que service d'accès internet contrôlé, en utilisant la segmentation VLAN, les politiques de pare-feu et un portail captif. Il montre également comment les formulaires d'inscription et les contrôles d'accès de Purple permettent de proposer une expérience visiteur fluide sans affaiblir la sécurité autour des systèmes du personnel, de paiement et opérationnels.
Vous avez des questions sur votre configuration spécifique ?
Notre équipe collabore avec des exploitants de sites, des responsables informatiques et des ingénieurs réseau au sein de 80 000 sites. Réservez un appel de 20 minutes et nous vous montrerons comment d'autres professionnels comme vous ont résolu ce problème.