Intégration de l'authentification WeChat WiFi : Parcours d'inscription sur le Captive Portal pour les clients APAC
WeChat compte 1,41 milliard d'utilisateurs actifs mensuels, ce qui en fait l'identité numérique principale 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 de la portée, l'application du RADIUS Change of Authorisation, et la double conformité avec le GDPR et 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.
Écouter ce guide
Voir la transcription du podcast
Synthèse
Pour les établissements 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 client 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 WeChat OAuth 2.0 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 traduit un échange OAuth réussi en un accès réseau réel. Nous abordons également les 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 matériels 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 clients 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 client 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 client 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 l'invité est déjà connecté via le navigateur intégré de WeChat, le scope snsapi_base permet une authentification silencieuse sans invite visible. WeChat redirige vers l'URI de redirection enregistrée du portail avec un code d'autorisation à durée de vie courte. 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'attribution. WeChat renvoie un jeton d'accès, un jeton de rafraîchissement, l'OpenID de l'utilisateur et le scope accordé. Si snsapi_userinfo a été demandé, un second appel API vers api.weixin.qq.com/sns/userinfo récupère le pseudo de l'utilisateur, sa photo de profil, son genre et sa ville.
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 d'implémentation.
| Contexte d'accès | Enregistrement requis | URL de la plateforme | Scopes pris 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 Web (Open Platform) | open.weixin.qq.com | snsapi_login (flux de code QR) |
Un compte d'abonnement (Subscription Account) sur la plateforme Official Accounts ne fonctionnera pas. Il ne dispose pas des autorisations d'authentification 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 et le Commerce de détail 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, atterrir dans le navigateur intégré et s'authentifier silencieusement via le flux Official Accounts. Les deux parcours doivent être pris en charge.
Sélection du scope et collecte de données
Le scope OAuth est une véritable décision d'architecture, pas un simple détail de configuration. Il détermine la friction subie par l'utilisateur et les données que votre plateforme de WiFi Analytics reçoit.
snsapi_base ne renvoie que l'OpenID - un identifiant unique et stable pour cet utilisateur au sein de votre compte officiel. Il ne nécessite aucune invite de consentement de l'utilisateur. L'authentification est invisible. Utilisez cette option pour les clients de retour dont vous possédez déjà le profil, ou pour les environnements à fort trafic tels que 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, le paramètre de langue et la ville. Il déclenche un écran de consentement explicite. Utilisez-le lors de la première inscription d'un visiteur pour 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 Captive Portal.
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. Si ce n'est pas le cas, 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 requête CoA au contrôleur sans fil. Le contrôleur met à jour la session, déplaçant l'appareil du VLAN walled garden (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 à implémenter mais comporte deux risques : les adresses MAC peuvent être usurpées, et iOS 14 ainsi qu'Android 10 et versions ultérieures utilisent par défaut la randomisation des adresses MAC, ce qui rompt 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 invités, consultez What Is Secure WiFi: Essential Guide for Business 2026 et Enterprise WiFi Security: A Complete Guide for 2026 .
Guide d'implémentation
Liste de contrôle avant déploiement
Avant d'écrire la moindre ligne de configuration, effectuez ces cinq étapes.
Premièrement, déterminez le contexte d'accès. Analysez votre site et identifiez si les invités accèderont au portail depuis le navigateur intégré de 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é, créez un compte de service sur la plateforme WeChat Official Accounts. Pour un accès via un navigateur standard, enregistrez une application de site Web sur la plateforme WeChat Open. Notez votre AppID et votre AppSecret pour chacun.
Troisièmement, configurez vos URI de redirection. Enregistrez chaque domaine et sous-domaine utilisé par votre portail, y compris les environnements de staging. WeChat applique 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 ne renvoie que les données dont votre portail a besoin.
Cinquièmement, implémentez le paramètre state pour la protection contre les attaques CSRF. Générez une valeur cryptographiquement aléatoire, stockez-la dans la session de l'utilisateur, transmettez-la dans la requête OAuth et validez-la au retour.
Étapes de configuration pour Ruckus SmartZone
Pour les sites utilisant 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ôleur 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. Tout échec de détection correcte entraîne des expériences dégradées ou des erreurs d'authentification.
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 PIPL, en vigueur depuis novembre 2021, exige un consentement explicite pour les informations personnelles sensibles et impose aux sous-traitants de données situés hors de Chine de mettre en œuvre des normes de protection équivalentes. Si votre serveur de portail est situé 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-sites
L'OpenID est unique par utilisateur et par Official Account. Si vous gérez plusieurs Official Accounts sur différents sites, le même visiteur aura des OpenID différents pour chacun d'eux. WeChat fournit un UnionID qui reste cohérent pour tous les comptes liés au même enregistrement Open Platform. Pour les chaînes hôtelières, les groupes de vente au détail ou les opérateurs aéroportuaires gérant plusieurs sites, implémentez 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 soupçonnez une exposition. Implémentez une limitation de débit sur votre point de terminaison d'échange de jetons pour éviter les abus. Enregistrez toutes les erreurs OAuth, en particulier la 40029 (code invalide) et la 40163 (code expiré), car elles indiquent 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 Why Consumer WiFi Gear Doesn't Belong on Your Guest Network .
Case studies
Chaîne d'hôtels de luxe, Singapour
Un hôtel de luxe de 350 chambres à Singapour, accueillant principalement une clientèle d'affaires chinoise, a implémenté l'authentification WeChat WiFi en parallèle de leur option de connexion par e-mail existante. Avant l'implémentation, 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 de voyage.
L'hôtel a enregistré un compte de service sur la plateforme WeChat Official Accounts et une application web sur la plateforme Open. Ils ont configuré snsapi_userinfo pour les premières connexions et snsapi_base pour les clients récurrents identifiés par leur adresse MAC. Le contrôleur HPE Aruba a été configuré pour le RADIUS CoA afin de gérer la promotion de session.
En 30 jours, les plaintes liées à la connexion WiFi des clients 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 de première partie vérifiés dès le premier mois, les données démographiques à l'échelle de la ville permettant des communications ciblées après le séjour.
Centre commercial international, Kuala Lumpur
Un centre commercial haut de gamme à Kuala Lumpur, comptant 12 millions d'utilisateurs de WeChat rien qu'en Malaisie, avait besoin d'une expérience d'accès 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 Guest WiFi de Purple comme surcouche cloud, avec WeChat OAuth comme méthode d'authentification principale et le SMS OTP comme solution de secours. L'architecture indépendante du matériel 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 ouvertures de sessions WiFi au cours du premier trimestre suivant le déploiement, attribuée à la réduction des frictions d'accès pour les utilisateurs de WeChat. Les données de première partie 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.
Troubleshooting and risk mitigation
| Erreur | Cause | Résolution |
|---|---|---|
| 40029 code invalide | Incohérence de l'URI de redirection ou réutilisation du code | Vérifiez que les URI enregistrées correspondent exactement ; les codes sont à usage unique |
| 40163 code expired | Échange de jeton 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 parcours du visiteur récurrent | Randomisation MAC iOS/Android | Migrer vers un suivi de session basé sur OpenID ; éviter l'identification uniquement par MAC |
| snsapi_userinfo renvoie des champs vides | L'utilisateur a configuré des restrictions de confidentialité WeChat | Gérer les champs nuls de manière fluide ; ne pas exiger les données de profil pour l'accès |
ROI et impact commercial
L'intérêt commercial de l'authentification WeChat WiFi repose sur trois résultats mesurables.
Acquisition de données de première partie. Chaque authentification snsapi_userinfo génère un profil invité vérifié avec des données démographiques. Pour un hôtel de 200 chambres fonctionnant à un taux d'occupation de 70 % 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 le principal moteur des appels d'assistance WiFi des clients. Les établissements qui ajoutent l'authentification WeChat aux options existantes signalent systématiquement une réduction des demandes d'assistance WiFi à la réception, libérant ainsi du temps pour le personnel pour des interactions à plus forte valeur ajoutée.
Portée marketing. Les comptes officiels WeChat permettent aux établissements de pousser des notifications aux abonnés. Un client qui s'authentifie via votre compte officiel peut être invité à le suivre, 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).
Le forfait Engage de Purple va encore plus loin, en permettant des 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 partie 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'accorder l'accès au réseau.
Le mécanisme par lequel l'authentification au 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 de l'industrie 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 celui-ci ne partage son mot de passe avec le tiers.
Le framework sous-jacent qui permet la connexion 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 RFC 3576 qui permet à un serveur RADIUS de modifier dynamiquement 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 traduit un échange WeChat OAuth réussi en un accès réseau réel. 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 est 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é multi-comptes.
snsapi_base
Un scope WeChat OAuth qui permet une authentification silencieuse, renvoyant uniquement l'OpenID de l'utilisateur sans afficher de demande de consentement.
À utiliser pour les invités récurrents ou les environnements à haut débit 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 de l'utilisateur, son pseudo, sa photo de profil, son genre, sa langue et sa ville, nécessitant un écran de consentement explicite de l'utilisateur.
À utiliser pour l'enregistrement initial des invités afin de créer un profil de données de première partie. Doit être associé à une couche de consentement conforme au GDPR et à la PIPL.
PIPL
Personal Information Protection Law. La législation complète de la Chine sur la confidentialité 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'endroit où se trouve l'établissement. Nécessite un consentement explicite, une limitation des finalités et une 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. Une exposition dans le code côté client permet à n'importe qui d'usurper l'identité de votre application et de passer des appels API non autorisés à 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é). RADIUS CoA déplace un appareil entre les VLAN lors d'une authentification réussie.
UnionID
Un identifiant WeChat qui reste cohérent pour un utilisateur donné sur tous les comptes officiels et applications web liés au même enregistrement Open Platform.
Indispensable pour les chaînes hôtelières, les groupes de vente au détail et les exploitants multi-sites qui doivent reconnaître le même invité sur plusieurs établissements, chacun ayant 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 Captive Portal. Comment doivent-ils configurer l'intégration WeChat OAuth ?
Étape 1 : Enregistrez un compte de service sur la plateforme de comptes officiels WeChat (mp.weixin.qq.com) pour gérer les clients accédant au portail via le navigateur intégré de WeChat. Enregistrez une application de site Web sur la plateforme ouverte WeChat (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 des comptes officiels pour les utilisateurs du navigateur intégré et le flux de code QR de la plateforme ouverte 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. Enregistrez 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 une authentification silencieuse sans invite visible par l'utilisateur.
Étape 5 : Configurez le contrôleur HPE Aruba pour le RADIUS CoA sur le port UDP 3799. Après un OAuth réussi, le serveur du portail envoie une requête CoA pour faire passer l'appareil du VLAN walled garden au VLAN invité.
Étape 6 : Implémentez la journalisation des adresses MAC aux côtés de l'OpenID pour gérer la détection des clients de retour. Notez que la randomisation 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 WiFi WeChat dans trois centres commerciaux. Les utilisateurs s'authentifient dans WeChat mais sont redirigé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 courantes sont une incompatibilité de l'URI de redirection et la réutilisation du code.
Étape 1 : Connectez-vous à la console développeur WeChat pour la plateforme de comptes officiels et la plateforme ouverte. Accédez aux paramètres OAuth et listez tous les URI de redirection enregistrés.
Étape 2 : Comparez-les avec les URI de redirection réels que votre serveur de portail utilise en production sur les trois sites. Recherchez les différences de sous-domaine (portal.brand.com vs brand.com), de protocole (HTTP vs HTTPS) et 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, vérifiez si votre serveur de portail tente de réutiliser les 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 deuxième tentative.
Étape 5 : Implémentez l'idempotence dans le point de terminaison d'échange de jetons pour éviter les requêtes en double.
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 importante base de fans 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 WeChat OAuth devez-vous configurer, et pourquoi ?
Conseil : Considérez l'impact d'un écran de consentement affiché à 15 000 utilisateurs simultanés sur un serveur de Captive Portal.
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 de connexion la plus rapide possible. À l'échelle d'un stade, un écran de consentement ajoute une friction qui se multiplie sur des milliers de connexions simultanées et peut provoquer des pics de charge sur le serveur du Captive Portal. Le scope snsapi_base ne renvoie que l'OpenID, ce qui est suffisant pour enregistrer la session et identifier les fans qui reviennent. Pour les nouveaux fans dont vous souhaitez obtenir des données démographiques, vous pouvez les inviter à remplir leur profil via une enquête post-connexion plutôt qu'au niveau de la barrière d'authentification.
Q2. Un architecte réseau de votre équipe propose de stocker l'AppSecret WeChat dans le JavaScript côté client du Captive Portal afin de réduire les allers-retours avec le serveur en effectuant l'appel d'échange de jetons directement depuis le navigateur. Expliquez pourquoi cette approche constitue une faille de sécurité critique et quelle est l'architecture correcte.
Conseil : Considérez qui peut voir le code côté client et ce que l'AppSecret lui 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 le code source de la page ou intercepte le trafic réseau. L'AppSecret authentifie votre application auprès de l'API de WeChat. Avec celui-ci, un acteur malveillant peut usurper l'identité de votre application, appeler le point de terminaison d'échange de jetons 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 est un point de terminaison d'échange de jetons 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 jeton 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é de client ?
Conseil : WeChat fournit un mécanisme de résolution d'identité multi-comptes 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 associés, WeChat renvoie un UnionID aux côtés de l'OpenID dans la réponse snsapi_userinfo. L'UnionID est cohérent pour un utilisateur donné sur tous les comptes associés au même enregistrement Open Platform. Migrez votre base de données pour utiliser l'UnionID comme identifiant principal du client pour les enregistrements 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 pour capturer l'UnionID.
Q4. Après avoir déployé l'authentification WeChat WiFi sur un site de vente au détail é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 jeton. 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
Le RADIUS Change of Authorisation (CoA) ne se finalise pas. Le serveur du portail a vérifié l'identité du client via WeChat OAuth mais n'a pas réussi à donner l'instruction au contrôleur Cisco Meraki de déplacer l'appareil du VLAN walled garden vers le VLAN invité. Diagnostiquez en vérifiant : (1) si le contrôleur Meraki a activé le RADIUS CoA et si l'IP du serveur du portail est répertoriée comme un client CoA autorisé ; (2) si le port UDP 3799 est ouvert entre le serveur du portail et le contrôleur ; (3) les journaux du serveur du portail pour détecter des erreurs ou des expirations de requêtes CoA ; et (4) si le secret partagé configuré des deux côtés correspond. Si le CoA n'est pas pris 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 MAC mentionné dans le guide.
Continuer la lecture de cette série
How to Set Up a Captive Portal on Starlink: A Guide for Remote & Maritime Venues
Ce guide explique comment contourner le matériel Starlink natif et intégrer un Captive Portal géré dans le cloud à l'aide d'équipements de routage d'entreprise. Vous apprendrez à surmonter la limitation du CGNAT, à appliquer la segmentation VLAN, à gérer les contraintes de bande passante par satellite et à garantir la conformité réglementaire.
Bonnes pratiques du Captive Portal : conception pour une conversion élevée et la conformité
Ce guide technique offre aux responsables informatiques, architectes réseau et directeurs d'exploitation de sites un plan complet pour déployer des captive portals équilibrant sécurité réseau et taux de conversion élevé. Il couvre l'ensemble de l'architecture, de la segmentation VLAN et l'authentification RADIUS à la conception de consentements conformes au GDPR et à la sélection des méthodes d'authentification. Issu de l'expérience opérationnelle de Purple sur plus de 80 000 sites et 440 millions de connexions en 2024, chaque recommandation est ancrée dans des données de déploiement réelles.
Comment optimiser les Captive Portals pour une sécurité réseau maximale et une conversion utilisateur optimale
Ce guide fournit un plan technique complet pour optimiser les Captive Portals au sein des entreprises, couvrant l'architecture de segmentation réseau, la sélection des méthodes d'authentification, la conception de formulaires de consentement conformes au GDPR et l'optimisation de la conversion. Il s'adresse aux responsables informatiques, architectes réseau et CTO d'hôtels, de chaînes de magasins, de stades et d'organisations du secteur public qui doivent concilier la sécurité réseau et la collecte de données de première partie. Purple gère l'infrastructure de Captive Portals de plus de 80 000 sites avec 440 millions de connexions en 2024, et les cadres présentés ici reflètent cette expérience opérationnelle.