Intégration de l'authentification WeChat avec les portails captifs pour WiFi invités
Ce guide explique comment intégrer l'authentification OAuth 2.0 de WeChat dans les portails captifs de WiFi invités 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 du réseau via le changement d'autorisation RADIUS (CoA), et la conformité avec le GDPR et la loi chinoise PIPL. Les gestionnaires de sites dans l'hôtellerie, le commerce de détail et l'événementiel y trouveront des étapes de déploiement concrètes, des études de cas réelles et des conseils de sécurisation pour déployer le WiFi invités avec connexion WeChat à grande échelle.
Écouter ce guide
Voir la transcription du podcast
Résumé
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 des codes d'accès, vous créez une friction immédiate. Selon les données 2024 de Tencent, WeChat compte 1,38 milliard d'utilisateurs actifs mensuels. Intégrer la connexion WeChat avec le WiFi invité n'est pas une simple commodité d'accueil ; c'est une exigence technique pour capturer des données de première main auprès de ce groupe démographique sans friction.
Ce guide détaille l'architecture technique de l'intégration de l'authentification WeChat OAuth 2.0 avec les portails captifs. Il explique le double enregistrement de plateforme requis pour prendre en charge les navigateurs mobiles standard ainsi que le navigateur intégré à WeChat, évalue les compromis entre les portées snsapi_base et snsapi_userinfo pour la collecte de données, et décrit comment l'accès réseau est appliqué à l'aide de RADIUS Change of Authorization (CoA) ou MAC Authentication Bypass. Il couvre également les configurations de sécurité et les directives de conformité - GDPR et la loi chinoise sur la protection des informations personnelles (PIPL) - requises pour les déploiements à 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 des appareils non authentifiés et les redirige vers une page de destination 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.
Le flux d'authentification fonctionne de la manière suivante : Un visiteur 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. Le visiteur sélectionne la connexion WeChat sur la page du Portail. Le serveur du Portail redirige le navigateur vers le point de terminaison d'autorisation WeChat à l'adresse open.weixin.qq.com, en transmettant l' AppID, l'URI de redirection, le type de réponse code et le Scope demandé. WeChat gère l'authentification sur ses propres serveurs. Si le visiteur utilise le navigateur intégré de WeChat avec le Scope snsapi_base, l'authentification est silencieuse - aucune invite de consentement d'autorisation n'apparaît. Si snsapi_userinfo est utilisé, WeChat affiche une page de consentement d'autorisation. 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 Access Token en effectuant un appel API vers api.weixin.qq.com/sns/oauth2/access_token avec l' AppID, l' AppSecret, le code et un type d'octroi de authorization_code. WeChat renvoie l'Access Token, le Refresh Token, l'OpenID de l'utilisateur et le Scope accordé. Si snsapi_userinfo a été accordé, le serveur lance un second appel API pour récupérer le pseudo, la photo de profil, le genre et la ville de l'utilisateur.
Exigences de double enregistrement de plateforme
La plupart des implémentations échouent lors de la phase d'enregistrement. 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 | Scopes pris en charge | Environnement de navigateur |
|---|---|---|---|---|
| Official Accounts Platform | mp.weixin.qq.com | Compte de Service | snsapi_base, snsapi_userinfo | Navigateur intégré WeChat |
| Open Platform | open.weixin.qq.com | Application Web | snsapi_login | Navigateurs mobiles standards |
Pour les visiteurs accédant au Portail via le navigateur intégré WeChat, vous avez besoin d'un Compte de Service sur la Official Accounts Platform. Les comptes d'abonnement ne fonctionneront pas - ils ne disposent pas des autorisations d'autorisation de page web OAuth. Pour les visiteurs accédant au Portail depuis Chrome sur Android ou Safari sur iOS, vous avez besoin d'une Application Web sur la Open Platform, qui utilise le Scope snsapi_login et affiche un code QR que l'utilisateur doit scanner.
En pratique, la plupart des déploiements sur site utilisent les deux. Un client d'hôtel peut ouvrir le Portail dans Chrome, voir un code QR, le scanner avec WeChat et s'authentifier. Ou il peut appuyer sur un lien directement dans WeChat, accéder au navigateur intégré et s'authentifier silencieusement via snsapi_base.
Sélection du Scope : Collecte de données vs. Friction utilisateur
Le scope que vous demandez détermine les données que vous collectez et la friction que le visiteur subit. Il s'agit d'un point de décision pratique ayant des implications en matière de conformité.
snsapi_base ne renvoie que l'OpenID - l'identifiant unique de cet utilisateur au sein de votre Compte Officiel. Il ne nécessite aucune demande de consentement de l'utilisateur. L'authentification est transparente pour le visiteur. Idéal pour les visiteurs récurrents dont vous possédez déjà le profil, ou lorsque vous privilégiez un accès fluide. Selon les principes de minimisation des données de la GDPR et de la PIPL, snsapi_base est beaucoup 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 une page d'autorisation de consentement explicite. Idéal pour l'enregistrement d'un premier visiteur lorsque vous devez créer un profil, associé à un bandeau de consentement conforme sur votre page de Captive Portal.
UnionID pour les déploiements multi-sites
Un OpenID est propre à l'association d'un utilisateur et d'un Compte Officiel spécifique. Un groupe hôtelier de 20 établissements, chacun gérant son propre Compte Officiel, verrait 20 OpenID différents pour le même visiteur. L'UnionID résout ce problème. Il s'agit d'un identifiant unique qui représente un utilisateur sur tous les Comptes Officiels et applications liés au même compte Open Platform. Liez vos Comptes Officiels à votre compte Open Platform, et l'UnionID sera renvoyé dans la réponse OAuth. C'est la base de la reconnaissance des visiteurs sur plusieurs sites.
Guide d'implémentation
Mécanismes d'application réseau
L'obtention d'un jeton OAuth prouve uniquement 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 norme RFC 3576) est la méthode recommandée pour les entreprises. Après une validation OAuth réussie, le serveur du Captive Portal envoie une demande CoA au contrôleur réseau. Le contrôleur bascule l'appareil du VLAN de pré-authentification vers le VLAN invité. Cela s'applique à Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks 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 sur la base de cette adresse MAC. Le MAB est plus facile à mettre en œuvre mais moins fiable : les appareils récents iOS et Android randomisent les adresses MAC par défaut, ce qui interrompt l'association de session lors de la reconconnexion.
La plateforme de Guest WiFi de Purple automatise cette transition. Une temps que l'authentification WeChat OAuth est terminée, le réseau cloud superposé de Purple envoie le signal CoA ou MAB approprié au matériel sous-jacent, éliminant ainsi les tracas de la configuration manuelle du VLAN.
Configuration de la sécurité
Les trois configurations suivantes ne sont pas négociables.
- Protégez l'AppSecret. L'
AppSecretne doit jamais apparaître dans le JavaScript côté client. Il doit rester sur votre serveur. S'il est compromis, des attaquants peuvent usurper l'identité de votre application et appeler l'API WeChat en votre nom. - Mettez en œuvre la protection CSRF. Générez une valeur d'état (
state) aléatoire de manière cryptographique, stockez-la dans la session utilisateur et validez-la au retour de la redirection WeChat. Cela permet d'éviter les attaques de contrefaçon de requête intersite définies dans la norme RFC 6749. - Enregistrez toutes les variations 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 les erreurs 40029 (code invalide).
Détection du navigateur intégré à l'application
Le navigateur intégré de WeChat définit une chaîne user-agent contenant MicroMessenger. Votre Captive Portal doit détecter cette chaîne et orienter le flux en conséquence : le navigateur intégré utilise le flux Official Account, tandis que les navigateurs standard utilisent le flux de code QR Open Platform. Ne pas détecter cette chaîne entraîne une expérience utilisateur dégradée ou des erreurs d'authentification.
Bonnes pratiques et conformité
Conformité GDPR
Si vous servez des visiteurs européens ou si vous opérez en Europe, le GDPR s'applique aux données que vous collectez via WeChat OAuth. Vous devez établir une base de traitement conforme - généralement le consentement ou l'intérêt légitime. Avant que l'authentification n'ait lieu, vous devez fournir une notice de confidentialité claire sur le Captive Portal. Vous devez répondre aux demandes d'accès et de suppression des données. Pour un cadre de conformité détaillé, reportez-vous au Compliance Playbook: GDPR and Guest WiFi Data Privacy .
Conformité PIPL
Lorsque vous traitez les données personnelles de citoyens chinois, la loi chinoise sur la protection des informations personnelles (PIPL) s'applique. Tout comme le GDPR, la PIPL exige une limitation explicite des finalités, la minimisation des données et une base légale écrite. Selon le principe de minimisation des données, snsapi_base est beaucoup plus facile à justifier que snsapi_userinfo. Quelles que soient les données que vous collectez, documentez votre base légale et vos périodes de conservation avant la mise en production.
Isolation du réseau
Utilisez la segmentation VLAN pour isoler le trafic WiFi invité de votre réseau d'entreprise. Les invités authentifiés via WeChat doivent être placés sur un VLAN invité dédié avec un accès uniquement à Internet - aucun accès aux systèmes internes. Cela s'aligne sur les exigences PCI-DSS concernant l'isolation de l'environnement des données de titulaires de cartes et sur les pratiques générales de sécurité de l'entreprise. Pour en savoir plus sur l'architecture d'isolation, reportez-vous au guide Bandwidth Management: A Practical Guide for 2026 .
Authentification de secours (Fallback)
Si l'API de WeChat est indisponible, votre portail doit rediriger vers une méthode de connexion alternative. Ne laissez pas les invités face à un écran blanc. Proposer des solutions de secours par e-mail ou SMS garantit la continuité du service. C'est particulièrement crucial dans les environnements de Transport et de Healthcare , où la connectivité réseau est une obligation de service.
Cas pratiques réels
Hôtellerie : Groupe hôtelier de luxe
Un hôtel de luxe de 400 chambres à Londres accueillait un nombre important de clients en provenance de Chine continentale. Leur Captive Portal d'origine exigeait une adresse e-mail et une vérification par SMS. Les numéros de mobile chinois ne recevaient fréquemment pas les SMS des opérateurs européens, et de nombreux clients n'avaient pas de compte e-mail natif configuré sur leurs appareils. Cela a conduit à des taux d'abandon du portail atteignant 60 %.
L'hôtel a enregistré un compte de service sur la plateforme Official Accounts et une application de site web sur la plateforme ouverte. Le portail a détecté l'agent utilisateur MicroMessenger et a déclenché snsapi_base pour les utilisateurs de navigateurs intégrés - les connectant en moins de trois secondes sans aucune invite d'autorisation. Les clients sur Chrome ou Safari se sont vu présenter un code QR. Lors des visites suivantes, le système reconnaissait le même OpenID et authentifiait silencieusement le client sans lui demander ses identifiants. Le CRM de l'hôtel a enregistré le retour du client, permettant une communication ciblée avant l'arrivée. Pour en savoir plus sur le déploiement du WiFi dans l'hôtellerie, consultez Hospitality .
Commerce de détail : Analyses pour centres commerciaux
Un grand centre commercial souhaitait obtenir des informations démographiques sur les consommateurs chinois afin d'orienter l'offre de boutiques et les stratégies marketing. Il devait comprendre la ville d'origine, le genre et la fréquence des visites. Ici, snsapi_base était insuffisant - ils avaient besoin de snsapi_userinfo. Le portail a demandé la portée complète des informations utilisateur. Les clients ont vu l'invite d'autorisation WeChat et ont cliqué sur autoriser. La plateforme d'analyse du centre commercial, intégrée à la solution WiFi Analytics de Purple, a reçu un flux de données démographiques vérifiées. Le samedi après-midi, 40 % des utilisateurs du WiFi provenaient d'une région spécifique. Ces données ont directement influencé le choix des marques contactées pour des activations éphémères. Pour en savoir plus sur les déploiements de 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 WeChat OAuth sur Captive Portal sont :
Incompatibilité d'URI de redirection (Erreur 40029). WeChat valide l'URI de redirection par rapport au domaine enregistré. Toute incompatibilité de sous-domaine, de chemin ou de protocole entraînera l'échec de l'échange de code. Enregistrez toutes les variantes, 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 critique. Veuillez déplacer toute la logique d'échange de jetons vers le côté serveur.
Protection CSRF manquante. Négliger la validation du paramètre state rend le portail vulnérable aux attaques de type Cross-Site Request Forgery. Générez une valeur aléatoire cryptographique par session et validez-la lors du rappel.
Échec de détection du navigateur intégré. Le fait de ne pas détecter MicroMessenger dans l'agent utilisateur signifie que les utilisateurs de navigateurs intégrés se verront proposer le mauvais flux OAuth, ce qui entraînera des erreurs.La randomisation des adresses MAC interrompt les sessions MAB. Les systèmes d'exploitation mobiles modernes randomisent les adresses MAC. Les invités s'appuyant sur l'application MAB perdront leur session lors de la reconnexion. Passez à RADIUS CoA pour une gestion de session fiable. Pour obtenir des conseils sur la configuration WiFi sécurisée, consultez What is Secure WiFi: The 2026 Enterprise Essential Guide .
ROI et impact commercial
Le déploiement de la connexion WeChat pour le WiFi invité offre trois impacts mesurables.
Amélioration des taux d'authentification. L'élimination des points de défaillance de la vérification par SMS et des exigences de saisie d'e-mail augmente la proportion de visiteurs chinois qui se connectent avec succès. Pour les Captive Portals sans support WeChat, un taux d'abandon de 60 % est une référence réaliste.
Qualité des données de première partie. Les profils vérifiés par WeChat incluent un OpenID validé et, via snsapi_userinfo, un accès direct aux attributs démographiques de la plateforme sociale. Ces données peuvent être injectées dans des plateformes d'analyse pour mener des campagnes marketing ciblées sans dépendre de cookies tiers.
Réduction des frais de support. Une connexion fluide réduit le volume d'appels vers la réception et le personnel de support informatique pour résoudre les problèmes de connexion des visiteurs internationaux.
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 aux réglementations GDPR et CCPA, et maintient une disponibilité de 99,999 %. Pour les sites des secteurs du Retail et de l' Hospitality , l'authentification WeChat transforme le réseau d'un centre de coûts en un canal robuste de capture de données de première partie.
Définitions clés
Portail captif
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 que WeChat utilise pour transmettre les jetons d'authentification au serveur du portail sans exposer les identifiants de l'utilisateur. Le même protocole que celui 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 visiteurs récurrents dans la base de données d'analyses WiFi. Varie selon le compte officiel - utilisez UnionID pour une reconnaissance multi-établissements.
UnionID
Un identifiant WeChat unique représentant un utilisateur sur tous les comptes officiels et applications liés au même compte Open Platform.
Indispensable pour les groupes hôteliers, les chaînes de magasins et les exploitants de stades disposant de plusieurs sites qui doivent reconnaître le même visiteur 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 visiteur d'un VLAN de pré-authentification isolé vers le VLAN internet actif après une connexion réussie à WeChat. Pris en charge par Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet.
snsapi_base
Un périmètre WeChat OAuth qui renvoie uniquement l'OpenID de l'utilisateur et ne nécessite aucune demande de consentement de sa part.
Le périmètre recommandé pour la ré-authentification des visiteurs récurrents. Plus facile à justifier dans le cadre des principes de minimisation des données du GDPR et de la PIPL.
snsapi_userinfo
Un périmètre WeChat OAuth qui renvoie l'OpenID, le pseudo, l'avatar, le genre et la ville de l'utilisateur, et nécessite un écran de consentement explicite.
Utilisé pour l'inscription d'un visiteur pour la première fois lorsque des données démographiques sont requises pour les analyses. Nécessite une base juridique 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 établissements traitent des données de citoyens chinois via WeChat OAuth. Nécessite un consentement clair, une limitation des finalités, la minimisation des données et un mécanisme de suppression.
AppSecret
Une clé cryptographique confidentielle délivrée par WeChat lors de l'enregistrement de l'application, utilisée pour autoriser les appels API depuis le serveur du portail.
Doit être stocké exclusivement côté serveur. L'exposition dans le JavaScript côté client permet à des attaquants d'usurper l'identité de l'application et d'appeler des API WeChat de manière malveillante.
Exemples concrets
Un hôtel de luxe de 400 chambres à Londres enregistre un taux d'abandon du portail de 60 % parmi ses clients originaires de Chine continentale. Le portail actuel nécessite une vérification par e-mail et SMS. Le directeur informatique doit mettre en œuvre l'authentification WeChat tout en maintenant la conformité avec le 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 transparente. Si elle n'est pas détectée, présenter le flux avec code QR. Étape 3 : Ajouter une politique 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. L'avis doit préciser : les données collectées (OpenID uniquement), la finalité (accès au WiFi invités et reconnaissance lors des visites ultérieures), et la durée de conservation. Étape 4 : Après un échange de jeton OAuth réussi, le serveur du portail émet une demande RADIUS CoA au contrôleur Cisco Meraki, déplaçant l'appareil de l'invité du VLAN de pré-authentification vers le VLAN invités segmenté. Étape 5 : Enregistrer l'OpenID associé à l'adresse MAC de l'appareil dans la base de données des invités. Lors des visites suivantes, le retour de l'OpenID déclenche une ré-authentification transparente.
Un centre commercial souhaite capturer le genre et la ville des clients chinois via le WiFi invités afin d'alimenter sa plateforme d'analyse de données. Ils utilisent actuellement le contournement d'authentification MAC (MAB) pour leur portail existant qui fonctionne 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 : un accès 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 à l'année qui se sont déjà authentifiés se connectent automatiquement sans voir d'écran de connexion lors de leurs visites ultérieures. Quel périmètre WeChat OAuth devez-vous implémenter pour le flux de ré-authentification, et pourquoi ?
Conseil : Réfléchissez au périmètre qui permet une authentification silencieuse sans demander le consentement de l'utilisateur à chaque visite.
Voir la réponse type
Utilisez snsapi_base. Ce périmètre renvoie uniquement l'OpenID de l'utilisateur et ne requiert aucune demande de consentement, permettant ainsi 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 récurrent 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 avec 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, puis WeChat redirige vers votre portail. Cependant, les journaux du serveur du portail affichent l'erreur OAuth 40029 (code non valide). 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 un décalage de l'URI de redirection. WeChat valide l'URI de redirection dans la requête OAuth par rapport au domaine autorisé enregistré sur la plateforme. Si le serveur du Captive Portal 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 Service Account ou Website Application, et ajoutez chaque variante d'URI de redirection que vous utilisez - y compris les sous-domaines de staging, les différents chemins et les versions HTTPS. Assurez-vous que le paramètre redirect_uri de votre requête OAuth correspond exactement à l'une des URI enregistrées, 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 du 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 au public.
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 peut extraire l'AppSecret et usurper l'identité de l'application, en appelant les API WeChat pour le compte de l'établissement, en accédant aux données des utilisateurs et en compromettant potentiellement l'ensemble du Official Account. 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 WeChat Official Account. 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 le UnionID. L'OpenID change pour chaque Official Account, de sorte que le même client aura 15 OpenID différents pour 15 comptes. Le UnionID est un identifiant stable représentant un utilisateur pour l'ensemble des Official Accounts et des applications liés au même compte Open Platform. Configuration requise : liez les 15 Official Accounts à un seul compte WeChat Open Platform. Une fois liés, le UnionID est renvoyé dans la réponse OAuth lorsque l'utilisateur a autorisé au moins l'un des comptes liés. Utilisez le UnionID comme clé primaire dans le CRM client pour créer des profils multi-établissements et reconnaître les clients fidèles, quel que soit l'établissement qu'ils visitent.
Continuer la lecture de cette série
Captive Portal pour Ruijie : configurez-le avec le WiFi invité Purple
Découvrez comment le WiFi invité cloud de Purple se superpose aux points d'accès Ruijie RG Series en utilisant l'authentification web et RADIUS, configuré en ligne de commande, et où trouver les étapes exactes de configuration.
Conception de Captive Portals B2B : Collecter le Nom Enregistré et les Données de l'Entreprise
Ce guide fournit aux responsables informatiques et aux exploitants de sites un cadre technique indépendant des fournisseurs pour concevoir des Captive Portals B2B. Il détaille comment structurer les champs d'inscription pour capturer le nom enregistré et les données de l'entreprise, garantissant des taux de complétion élevés tout en maintenant la conformité GDPR et en développant une intelligence au niveau des comptes.
Architecture de Captive Portal : Sécurité, redirection et bonnes pratiques
Une référence technique définitive sur l'architecture de captive portal d'entreprise. Ce guide détaille l'isolation réseau, la redirection DNS, l'authentification RADIUS et la conformité en matière de sécurité pour les responsables informatiques déployant des réseaux WiFi invités sécurisés et riches en données.