Intégration de l'authentification WeChat avec les Captive Portals de WiFi invité
Ce guide explique comment intégrer l'authentification WeChat OAuth 2.0 dans les Captive Portals de WiFi invité d'entreprise. Il couvre les exigences d'enregistrement sur double plateforme, la sélection de la portée pour la capture de données de première partie, l'application réseau via RADIUS Change of Authorization, et la conformité avec le GDPR et la PIPL chinoise. Les exploitants de sites dans l'hôtellerie, le commerce de détail et l'événementiel y trouveront des étapes de mise en œuvre concrètes, des études de cas réelles et des conseils de renforcement de la sécurité pour déployer le WiFi invité avec connexion WeChat à grande échelle.
Écouter ce guide
Voir la transcription du podcast
Synthèse
Lorsqu'un visiteur chinois se connecte à votre réseau d'entreprise et fait face à un Captive Portal ne proposant que l'e-mail, Facebook ou un code d'accès, vous créez immédiatement une friction. WeChat compte 1,38 milliard d'utilisateurs actifs mensuels, selon les données 2024 de Tencent. L'intégration des fonctionnalités de connexion WeChat pour le WiFi invité n'est pas un simple confort d'accueil : c'est une exigence technique pour collecter des données de première main auprès de cette cible démographique, sans friction.
Ce guide détaille l'architecture technique pour intégrer l'authentification WeChat OAuth 2.0 aux Captive Portals. Il explique la double inscription sur plateforme requise pour prendre en charge à la fois les navigateurs mobiles standard et le navigateur intégré de WeChat, évalue les compromis entre les portées snsapi_base et snsapi_userinfo pour la collecte de données, et décrit comment appliquer l'accès réseau à l'aide du changement d'autorisation RADIUS (CoA) ou du contournement d'authentification MAC. Il couvre également les configurations de sécurité et les obligations de conformité (GDPR et PIPL chinoise) requises pour déployer cette solution à grande échelle sur les infrastructures Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet.
Analyse technique approfondie : architecture WeChat OAuth 2.0
Un Captive Portal intercepte le trafic HTTP d'un appareil non authentifié et le redirige vers une page de connexion hébergée sur un serveur de portail. L'ajout de l'authentification WeChat insère un fournisseur d'identité tiers dans ce flux à l'aide du protocole OAuth 2.0 - le même standard utilisé par Google, Microsoft Entra ID et Okta pour l'identité fédérée.
La séquence d'authentification fonctionne comme suit. L'invité se connecte au SSID. Le point d'accès ou le contrôleur sans fil détecte la session non authentifiée et redirige le trafic HTTP vers l'URL du Captive Portal. L'invité sélectionne la connexion WeChat sur la page du portail. Le serveur du portail redirige le navigateur vers le point de terminaison d'autorisation de WeChat à l'adresse open.weixin.qq.com, en transmettant l'AppID, l'URI de redirection, le type de réponse code et la portée demandée. WeChat gère l'authentification sur ses propres serveurs. Si l'invité utilise le navigateur intégré de WeChat avec la portée snsapi_base, l'authentification est transparente : aucune demande de consentement n'apparaît. S'il utilise snsapi_userinfo, WeChat affiche un écran de consentement. WeChat redirige ensuite vers l'URI de redirection du portail avec un code d'autorisation temporaire. Le serveur du portail échange ce code contre un jeton d'accès en appelant api.weixin.qq.com/sns/oauth2/access_token, en transmettant l'AppID, l'AppSecret, le code et un type d'attribution authorization_code. 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é accordé, le serveur effectue un second appel API pour récupérer le pseudo, l'avatar, le genre et la ville de l'utilisateur.
L'exigence de double inscription sur plateforme
La plupart des implémentations échouent lors de la phase d'inscription. WeChat exploite deux plateformes de développement distinctes, et les déploiements d'entreprise nécessitent généralement les deux.
| Plateforme | URL | Type de compte requis | Portée prise en charge | Contexte du navigateur |
|---|---|---|---|---|
| Official Accounts Platform | mp.weixin.qq.com | Service Account | snsapi_base, snsapi_userinfo | Navigateur intégré WeChat |
| Open Platform | open.weixin.qq.com | Website Application | snsapi_login | Navigateur mobile standard |
Pour les invités accédant au portail depuis le navigateur intégré de WeChat, vous avez besoin d'un Service Account sur la plateforme Official Accounts. Un compte d'abonnement ne fonctionnera pas : il ne dispose pas des autorisations d'autorisation de page web OAuth. Pour les invités accédant au portail depuis Chrome sur Android ou Safari sur iOS, vous avez besoin d'une Website Application sur la Open Platform, qui utilise la portée snsapi_login et présente un code QR que l'utilisateur doit scanner.
En pratique, la plupart des déploiements sur site utilisent les deux. Un invité dans un hôtel peut ouvrir le portail dans Chrome, voir un code QR, le scanner avec WeChat et s'authentifier. Ou il peut suivre un lien dans WeChat lui-même, arriver sur le navigateur intégré et s'authentifier de manière transparente avec snsapi_base.
Choix de la portée : collecte de données vs. friction
La portée que vous demandez détermine les données que vous collectez et la friction ressentie par l'invité. Il s'agit d'un véritable point de décision ayant des implications en matière de conformité.
snsapi_base ne renvoie que l'OpenID - un identifiant unique pour cet utilisateur au sein de votre Official Account. Il ne nécessite aucune demande de consentement de l'utilisateur. L'authentification est invisible pour l'invité. Utilisez cette option pour les invités réguliers dont vous possédez déjà le profil, ou lorsque vous privilégiez un accès sans friction. Selon les principes de minimisation des données du GDPR et de la PIPL, snsapi_base est plus facile à justifier.
snsapi_userinfo renvoie l'OpenID ainsi que le pseudo, la photo de profil, le genre et la ville de l'utilisateur. Il nécessite un écran de consentement explicite. Utilisez cette option pour l'inscription d'un nouvel invité lorsque vous devez créer un profil, associée à une couche de consentement conforme sur votre page de portail.
UnionID pour les déploiements multi-propriétés
L'OpenID est unique à la combinaison d'un utilisateur et d'un Official Account spécifique. Un groupe hôtelier possédant 20 établissements, chacun ayant son propre Official Account, verra 20 OpenID différents pour le même invité. L'UnionID résout ce problème. Il s'agit d'un identifiant unique représentant un utilisateur sur l'ensemble des Official Accounts et des applications liés au même compte Open Platform. Associez vos Official Accounts à votre compte Open Platform, et l'UnionID sera renvoyé dans la réponse OAuth. C'est la base de lareconnaissance des clients sur l'ensemble des établissements.
Guide d'implémentation
Mécanismes d'application réseau
L'obtention d'un jeton OAuth prouve l'identité. Elle n'ouvre pas le réseau. Vous devez signaler au contrôleur d'autoriser le trafic.
Le RADIUS Change of Authorization (CoA), défini dans la RFC 3576, est l'approche d'entreprise recommandée. Après une authentification OAuth réussie, le serveur du portail envoie une requête CoA au contrôleur réseau. Le contrôleur déplace l'appareil du VLAN de pré-authentification vers le VLAN invité. Cela fonctionne avec Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet.
Le MAC Authentication Bypass (MAB) enregistre l'adresse MAC de l'appareil en tant que client autorisé dans la base de données RADIUS. Le contrôleur autorise l'accès en se basant sur cette adresse MAC. Le MAB est plus simple à implémenter mais peu fiable : les appareils iOS et Android modernes randomisent les adresses MAC par défaut, ce qui rompt l'association de session lors de la reconnexion.
La plateforme Guest WiFi de Purple automatise cette transition. Une fois l'authentification OAuth WeChat terminée, l'overlay cloud de Purple envoie le signal CoA ou MAB approprié au matériel sous-jacent, éliminant ainsi toute configuration manuelle de VLAN.
Configuration de la sécurité
Trois configurations sont non négociables.
- Protéger l'AppSecret. L'
AppSecretne doit jamais apparaître dans le JavaScript côté client. Il doit rester sur votre serveur. S'il est exposé, des attaquants peuvent usurper l'identité de votre application et appeler les API WeChat en votre nom. - Implémenter une protection CSRF. Générez une valeur
statede manière cryptographique et aléatoire, stockez-la dans la session de l'utilisateur et validez-la lorsque WeChat effectue la redirection de retour. Cela empêche les attaques de contrefaçon de requête intersite telles que définies dans la RFC 6749. - Enregistrer toutes les variantes d'URI de redirection. WeChat valide l'URI de redirection par rapport à votre domaine enregistré. Enregistrez chaque sous-domaine et variante de chemin que vous utilisez, y compris les environnements de staging, pour éviter l'erreur 40029 (code invalide).
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 router le trafic en conséquence : flux de compte officiel pour le navigateur intégré, flux de code QR Open Platform pour les navigateurs standards. L'absence de cette détection entraîne des expériences utilisateur dégradées ou des erreurs d'authentification.
Bonnes pratiques et conformité
Conformité GDPR
Si vous accueillez des visiteurs européens ou si vous opérez en Europe, le GDPR s'applique aux données que vous collectez via l'authentification OAuth WeChat. Vous devez établir une base légale pour le traitement - généralement le consentement ou les intérêts légitimes. Vous devez fournir une notice de confidentialité claire sur le Captive Portal avant l'authentification. Vous devez respecter les demandes d'accès et de suppression des personnes concernées. Pour un cadre de conformité détaillé, consultez The Compliance Playbook: GDPR and Guest WiFi Data Privacy .
Conformité PIPL
La loi chinoise sur la protection des informations personnelles (PIPL) s'applique lorsque vous traitez les données personnelles de citoyens chinois. Tout comme le GDPR, la PIPL exige une limitation claire des finalités, la minimisation des données et une base légale documentée. snsapi_base est plus facile à justifier dans le cadre de la minimisation des données que snsapi_userinfo. Quelle que soit votre collecte, documentez votre base légale et votre période de conservation avant la mise en production.
Segmentation réseau
Isolez le trafic WiFi invité de votre réseau d'entreprise en utilisant la segmentation VLAN. Les invités authentifiés via WeChat doivent être dirigés vers un VLAN invité dédié avec un accès Internet uniquement - aucun accès aux systèmes internes. Cela s'aligne sur les exigences PCI DSS pour l'isolation de l'environnement des données de titulaires de carte et sur les pratiques générales de sécurité d'entreprise. Pour en savoir plus sur l'architecture de segmentation, consultez Bandwidth Management: A Practical Guide for 2026 .
Authentification de secours
Si l'API de WeChat est indisponible, votre portail doit rediriger vers une méthode de connexion alternative. Ne laissez pas les invités devant un écran vide. Une solution de secours par e-mail ou SMS garantit la continuité du service. Ceci est particulièrement important pour les établissements des secteurs du Transport et de la Santé où la connectivité est une obligation de service.
Cas clients réels
Hôtellerie : groupe hôtelier de luxe
Un hôtel de luxe de 400 chambres à Londres accueille une proportion importante de clients originaires de Chine continentale. Leur Captive Portal existant exigeait une adresse e-mail et une vérification par SMS. Les numéros de mobile chinois ne reçoivent fréquemment pas les SMS des fournisseurs européens, et de nombreux clients n'ont pas d'e-mail local configuré sur leur appareil. Le résultat était un taux d'abandon de 60 % sur le portail.
L'hôtel a enregistré un compte de service sur la plateforme de comptes officiels et une application Web sur l'Open Platform. Le portail détecte l'agent utilisateur MicroMessenger et déclenche snsapi_base pour les utilisateurs du navigateur intégré - les connectant en moins de trois secondes sans écran de consentement. Les clients arrivant via Chrome ou Safari voient un code QR. Lors des séjours suivants, le même OpenID est reconnu et le client est ré-authentifié de manière transparente. Le CRM de l'hôtel enregistre la nouvelle visite, permettant des communications ciblées avant l'arrivée. Pour en savoir plus sur le déploiement du WiFi dans le secteur de l'hôtellerie, consultez Hospitality .
Commerce de détail : analyses de centre commercial
Un grand centre commercial souhaite collecter des données démographiques auprès des acheteurs chinois afin d'orienter la composition des enseignes et les décisions marketing. Ils ont besoin de la ville d'origine, du genre et de la fréquence des visites. snsapi_base est insuffisant - ils ont besoin de snsapi_userinfo. Le portail demande l'accès complet aux informations utilisateur. L'invité voit un écran de consentement WeChat et appuie sur Autoriser. La plateforme d'analyse du centre commercial, intégrée à la solution WiFi Analytics de Purple, reçoit un flux de données démographiques vérifiées. Le samedi après-midi, 40 % des utilisateurs du WiFi proviennent d'une région spécifique. Ces données directy indique quelles marques approcher pour des événements éphémères. Pour en savoir plus sur les déploiements WiFi dans le commerce de détail, consultez Retail .
Dépannage et atténuation des risques
Les cinq modes de défaillance les plus courants dans les déploiements de Captive Portal avec OAuth WeChat sont les suivants.
Incohérence de l'URI de redirection (erreur 40029). WeChat valide l'URI de redirection par rapport au domaine enregistré. Toute différence de sous-domaine, de chemin ou de protocole fait échouer l'échange de code. Enregistrez chaque variante, y compris les environnements de staging.
Exposition de l'AppSecret. L'intégration de l'AppSecret dans le code côté client est l'erreur de sécurité la plus grave. Déplacez toute la logique d'échange de jetons vers le serveur.
Absence de protection CSRF. L'omission de la validation du paramètre state rend le portail vulnérable aux attaques de type cross-site request forgery. Générez une valeur cryptographiquement aléatoire par session et validez-la lors du rappel (callback).
Échec de la détection du navigateur intégré. Ne pas détecter MicroMessenger dans l'user agent signifie que les utilisateurs du navigateur intégré reçoivent le mauvais flux OAuth, ce qui génère des erreurs.
La randomisation des adresses MAC interrompt les sessions MAB. Les systèmes d'exploitation mobiles modernes randomisent les adresses MAC. Les visiteurs utilisant une authentification basée sur le MAB perdront leur session lors de la reconnexion. Passez au RADIUS CoA pour une gestion de session fiable. Pour obtenir des conseils sur la configuration WiFi sécurisée, consultez What Is Secure WiFi: Essential Guide for Business 2026 .
ROI et impact commercial
Le déploiement de la fonctionnalité de connexion WiFi invité via WeChat a trois impacts mesurables.
Augmentation des taux d'authentification. L'élimination du point de friction lié à l'échec de la vérification par SMS et de l'obligation de saisir une adresse e-mail augmente le pourcentage de visiteurs chinois qui se connectent avec succès. Un taux d'abandon de 60 % est une référence réaliste pour les portails sans support WeChat.
Qualité des données de première partie. Les profils authentifiés via WeChat incluent un OpenID vérifié et, avec snsapi_userinfo, des attributs démographiques provenant directement de la plateforme sociale. Ces données alimentent les plateformes d'analyse pour mener des campagnes marketing ciblées sans dépendre des cookies tiers.
Réduction des coûts de support. Une connexion sans friction réduit les appels au service d'accueil et au support informatique de la part des clients internationaux rencontrant des problèmes de connexion.
Purple opère dans plus de 80 000 sites et a traité 440 millions de connexions en 2024 (données internes Purple). La plateforme est certifiée ISO 27001, conforme au GDPR et à la CCPA, et maintient une disponibilité de 99,999 %. Pour les établissements des secteurs Retail et Hospitality , l'authentification WeChat transforme le réseau d'un centre de coûts en un canal fiable d'acquisition de données de première partie.
Définitions clés
Captive portal
Une page web qui intercepte le trafic HTTP d'un appareil non authentifié et exige que l'utilisateur interagisse avec elle avant de lui accorder l'accès au réseau.
L'interface principale où l'option de connexion WeChat est présentée à l'invité. Le serveur du portail héberge cette page et orchestre le flux OAuth.
OAuth 2.0
Un protocole d'autorisation standard de l'industrie (RFC 6749) qui permet à une application tierce d'obtenir un accès limité à un service HTTP au nom d'un utilisateur.
Le protocole sous-jacent utilisé par WeChat pour transmettre les jetons d'authentification au serveur du portail sans exposer les identifiants de l'utilisateur. Le même protocole est utilisé par Microsoft Entra ID, Okta et Google Workspace.
OpenID
Un identifiant alphanumérique unique attribué à un utilisateur WeChat spécifique pour un compte officiel spécifique.
Utilisé comme clé primaire pour identifier les invités de retour dans la base de données d'analyse WiFi. Varie selon le compte officiel - utilisez l'UnionID pour une reconnaissance multi-sites.
UnionID
Un identifiant WeChat unique représentant un utilisateur sur l'ensemble des comptes officiels et des applications liés au même compte de plateforme ouverte.
Indispensable pour les groupes hôteliers, les chaînes de vente au détail et les exploitants de stades disposant de plusieurs sites qui doivent reconnaître le même invité sur l'ensemble de leur parc.
RADIUS CoA (Change of Authorization)
Une extension du protocole RADIUS (RFC 3576) qui permet à un serveur RADIUS de modifier dynamiquement les attributs d'autorisation d'une session active.
La méthode sécurisée utilisée pour déplacer l'appareil d'un invité d'un VLAN de pré-authentification isolé vers le VLAN Internet actif après une connexion WeChat réussie. Pris en charge par Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet.
snsapi_base
Une portée OAuth WeChat qui renvoie uniquement l'OpenID de l'utilisateur et ne nécessite aucune invite de consentement de sa part.
La portée recommandée pour la réauthentification des invités de retour. Plus facile à justifier au regard des principes de minimisation des données du GDPR et de la PIPL.
snsapi_userinfo
Une portée OAuth WeChat qui renvoie l'OpenID, le pseudonyme, l'avatar, le genre et la ville de l'utilisateur, et nécessite un écran de consentement explicite.
Utilisé pour l'enregistrement initial des invités lorsque des données démographiques sont requises pour l'analyse. Nécessite une base légale documentée en vertu du GDPR et de la PIPL.
PIPL (Personal Information Protection Law)
La législation complète de la Chine sur la confidentialité des données, entrée en vigueur en novembre 2021, régissant le traitement des informations personnelles des personnes physiques situées en Chine.
S'applique lorsque les sites traitent les données de citoyens chinois via WeChat OAuth. Exige un consentement clair, une limitation des finalités, la minimisation des données et un mécanisme de suppression.
AppSecret
Une clé cryptographique confidentielle émise par WeChat lors de l'enregistrement de l'application, utilisée pour authentifier les appels API provenant du serveur du portail.
Doit être stocké exclusivement côté serveur. Son exposition dans le JavaScript côté client permet à des attaquants d'usurper l'identité de l'application et d'appeler les API WeChat de manière malveillante.
Exemples concrets
Un hôtel de luxe de 400 chambres à Londres enregistre un taux d'abandon de 60 % sur son portail parmi les clients originaires de Chine continentale. Le portail actuel exige une vérification par e-mail et SMS. Le directeur informatique doit mettre en œuvre l'authentification WeChat tout en maintenant la conformité au GDPR et la sécurité du réseau.
Étape 1 : Enregistrer un compte de service sur la plateforme de comptes officiels WeChat (mp.weixin.qq.com) et une application de site Web sur la plateforme ouverte WeChat (open.weixin.qq.com). Étape 2 : Configurer le portail pour détecter la chaîne d'agent utilisateur MicroMessenger. Si elle est détectée, déclencher le flux OAuth snsapi_base pour une authentification silencieuse. Si elle n'est pas détectée, présenter le flux par code QR. Étape 3 : Ajouter une notice de confidentialité conforme au GDPR et une case à cocher de consentement sur la page du portail avant que le bouton de connexion WeChat ne devienne actif. La notice doit préciser : les données collectées (OpenID uniquement), la finalité (accès au WiFi invité et reconnaissance des visites de retour) et la durée de conservation. Étape 4 : Après l'échange réussi du jeton OAuth, le serveur du portail émet une demande RADIUS CoA vers le contrôleur Cisco Meraki, déplaçant l'appareil de l'invité du VLAN de pré-authentification vers le VLAN invité segmenté. Étape 5 : Stocker l'OpenID en l'associant à l'adresse MAC de l'appareil dans la base de données des invités. Lors des visites ultérieures, l'OpenID de retour déclenche une réauthentification silencieuse.
Un centre commercial souhaite capturer le genre et la ville des acheteurs chinois via le WiFi invité pour alimenter sa plateforme d'analyse. Il utilise actuellement le MAC Authentication Bypass pour son portail existant fonctionnant sur du matériel HPE Aruba.
Étape 1 : Enregistrer un compte de service sur la plateforme de comptes officiels WeChat. Étape 2 : Configurer le portail pour utiliser la portée snsapi_userinfo afin de récupérer le genre et la ville. Étape 3 : Ajouter un écran de consentement clair expliquant l'échange de valeur : WiFi gratuit en échange de l'accès aux données de profil. Le consentement doit être explicite et granulaire en vertu du GDPR et de la PIPL. Étape 4 : Après l'authentification, le serveur du portail enregistre l'adresse MAC de l'appareil dans la base de données RADIUS. Le contrôleur HPE Aruba autorise l'accès via MAB. Étape 5 : Documenter la base légale (consentement), la finalité (analyse du site et marketing) et la durée de conservation (24 mois) dans un registre de traitement des données. Fournir un mécanisme de suppression des données.
Questions d'entraînement
Q1. Vous déployez un Captive Portal dans un stade. Vous souhaitez que les abonnés de retour qui se sont déjà authentifiés se connectent automatiquement sans voir d'écran de connexion lors de leurs visites ultérieures. Quelle portée OAuth WeChat devez-vous implémenter pour le flux de réauthentification, et pourquoi ?
Conseil : Déterminez quelle portée permet une authentification silencieuse sans demander le consentement de l'utilisateur à chaque visite.
Voir la réponse type
Utilisez snsapi_base. Cette portée renvoie uniquement l'OpenID de l'utilisateur et ne nécessite aucune invite de consentement, ce qui permet une réauthentification silencieuse. Lors de la première visite, vous stockez l'OpenID dans le profil du supporter. Lors des visites suivantes, le portail détecte l'OpenID de retour via snsapi_base, confirme la correspondance et émet un RADIUS CoA pour accorder l'accès - le tout sans que le supporter ne voie d'écran de connexion. Cela s'aligne également sur les principes de minimisation des données du GDPR, car vous ne collectez pas de données supplémentaires au-delà de ce qui est nécessaire pour la fonction d'authentification.
Q2. Lors des tests, votre portail redirige avec succès vers WeChat, l'utilisateur donne son consentement et WeChat redirige vers votre portail. Cependant, les journaux du serveur du portail affichent l'erreur OAuth 40029 (code invalide). Quelle est l'erreur de configuration la plus probable et comment la résoudre ?
Conseil : WeChat valide strictement la destination vers laquelle il envoie le code d'autorisation par rapport à une liste enregistrée.
Voir la réponse type
La cause la plus probable est une incompatibilité de l'URI de redirection. WeChat valide l'URI de redirection de la requête OAuth par rapport au domaine autorisé enregistré sur la plateforme. Si le serveur du portail utilise un sous-domaine différent, un chemin différent ou HTTP au lieu de HTTPS, l'échange de code échoue avec l'erreur 40029. Résolution : connectez-vous à la plateforme de développement WeChat, accédez aux paramètres de votre compte de service ou de votre application de site Web, et ajoutez chaque variante d'URI de redirection que vous utilisez - y compris les sous-domaines de pré-production, les différents chemins et les versions HTTPS. Assurez-vous que le paramètre redirect_uri de votre requête OAuth correspond exactement à l'un des URI enregistrés, y compris l'encodage de l'URL.
Q3. Un responsable informatique propose d'intégrer l'AppSecret WeChat dans le JavaScript frontal du Captive Portal afin d'accélérer le processus d'échange de jetons directement depuis le navigateur client. Pourquoi devez-vous rejeter cette proposition et quelle est l'architecture correcte ?
Conseil : Pensez aux implications de sécurité liées à l'exposition de clés cryptographiques dans un code accessible publiquement.
Voir la réponse type
Rejetez cette proposition. L'AppSecret est une clé cryptographique confidentielle. L'intégrer dans le JavaScript côté client l'expose à quiconque consulte le code source de la page ou intercepte le trafic réseau. Un attaquant pourrait extraire l'AppSecret et usurper l'identité de l'application, appelant les API WeChat au nom du site, accédant aux données des utilisateurs et compromettant potentiellement l'ensemble du compte officiel. L'architecture correcte : la page du portail côté client reçoit le code d'autorisation de WeChat et le transmet au serveur du portail via un appel API côté serveur. Le serveur du portail conserve l'AppSecret dans une variable d'environnement sécurisée et effectue l'échange de jetons avec l'API de WeChat. L'AppSecret ne quitte jamais le serveur.
Q4. Un groupe hôtelier possédant 15 établissements en Europe souhaite créer un profil client unifié qui reconnaît lorsqu'un même client chinois séjourne dans différents établissements. Chaque établissement possède son propre compte officiel WeChat. Quel identifiant WeChat doivent-ils utiliser et quelle configuration est requise ?
Conseil : L'OpenID est propre à chaque compte. Il existe un identifiant différent conçu pour la reconnaissance inter-comptes.
Voir la réponse type
Utilisez l'UnionID. L'OpenID change pour chaque compte officiel, de sorte qu'un même client aura 15 OpenID différents sur 15 comptes. L'UnionID est un identifiant stable représentant un utilisateur sur l'ensemble des comptes officiels et des applications liés au même compte de plateforme ouverte. Configuration requise : lier les 15 comptes officiels à un seul compte de plateforme ouverte WeChat. Une fois liés, l'UnionID est renvoyé dans la réponse OAuth lorsque l'utilisateur a autorisé au moins l'un des comptes liés. Utilisez l'UnionID comme clé primaire dans le CRM client pour créer des profils multi-sites et reconnaître les invités de retour, quel que soit l'établissement qu'ils visitent.
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.