Integrating WeChat Authentication with Guest WiFi Captive Portals
Ce guide explique comment intégrer l'authentification WeChat OAuth 2.0 dans les Captive Portals WiFi invités d'entreprise. Il couvre les exigences d'enregistrement sur double plateforme, la sélection de la portée (scope) pour la capture de données de première partie (first-party), l'application réseau via RADIUS Change of Authorization, et la conformité avec le GDPR et la PIPL chinoise. Les exploitants de sites dans les secteurs de l'hôtellerie, du commerce de détail et de 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 la connexion WeChat sur le WiFi invité à grande échelle.
Écouter ce guide
Voir la transcription du podcast
Résumé exécutif
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 promotionnel, vous créez une friction immédiate. WeChat compte 1,38 milliard d'utilisateurs actifs mensuels, selon les données 2024 de Tencent. L'intégration de fonctionnalités de connexion WeChat sur le WiFi invité n'est pas un simple confort d'accueil : c'est une exigence technique pour capturer des données de première partie (first-party) auprès de cette population sans friction.
Ce guide détaille l'architecture technique pour intégrer l'authentification WeChat OAuth 2.0 dans les Captive Portals. Il explique l'enregistrement sur double plateforme requis pour prendre en charge à la fois les navigateurs mobiles standard et le navigateur intégré (in-app) de WeChat, évalue les compromis entre les portées (scopes) snsapi_base et snsapi_userinfo pour la collecte de données, et décrit comment appliquer l'accès réseau à l'aide de RADIUS Change of Authorization (CoA) ou du contournement d'authentification MAC (MAC authentication bypass). Il couvre également les configurations de sécurité et les obligations de conformité — GDPR et PIPL chinoise — nécessaires 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 (scope) 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 silencieuse : aucune invite de consentement n'apparaît. S'il utilise snsapi_userinfo, WeChat présente 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 (access token) 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 (refresh token), l'OpenID de l'utilisateur et la portée accordée. Si la portée snsapi_userinfo a été accordée, 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 d'enregistrement sur double plateforme
La plupart des implémentations échouent lors de l'étape 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 | Portée (scope) prise en charge | Contexte du navigateur |
|---|---|---|---|---|
| Official Accounts Platform | mp.weixin.qq.com | Compte de service (Service Account) | snsapi_base, snsapi_userinfo | Navigateur intégré WeChat |
| Open Platform | open.weixin.qq.com | Application de site web (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 Compte de service (Service Account) sur l'Official Accounts Platform. Un compte d'abonnement (Subscription Account) 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 Application de site web (Website Application) sur l'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 client d'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 silencieusement avec snsapi_base.
Sélection de la portée (scope) : capture 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 compte officiel (Official Account). Il ne nécessite aucune invite de consentement de l'utilisateur. L'authentification est invisible pour l'invité. Utilisez cette option pour les invités récurrents dont vous possédez déjà le profil, ou lorsque vous donnez la priorité à 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 de l'utilisateur, sa photo de profil, son genre et sa ville. Il nécessite un écran de consentement explicite. Utilisez cette option pour l'enregistrement des nouveaux invités 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-établissements
L'OpenID est unique à la combinaison d'un utilisateur et d'un compte officiel (Official Account) spécifique. Un groupe hôtelier comptant 20 établissements, chacun disposant de son propre compte officiel, 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 tous les comptes officiels et applications liés au même compte Open Platform. Associez vos comptes officiels à votre compte Open Platform, et l'UnionID sera renvoyé dans la réponse OAuth. C'est la base de la crreconnaissance multi-sites des clients.
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.
RADIUS Change of Authorization (CoA), défini dans la RFC 3576, est l'approche d'entreprise recommandée. Après un OAuth réussi, 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.
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 fonction de cette 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 traduction. Une fois l'authentification OAuth de WeChat terminée, la surcouche cloud de Purple envoie le signal CoA ou MAB approprié au matériel sous-jacent, éliminant ainsi la configuration manuelle du 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
statecryptographiquement aléatoire, stockez-la dans la session de l'utilisateur et validez-la lorsque WeChat redirige l'utilisateur. Cela empêche les attaques de type cross-site request forgery (CSRF) 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é (in-app)
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 acheminer le trafic en conséquence : flux Official Account pour le navigateur intégré, flux de code QR Open Platform pour les navigateurs standard. L'absence de détection entraîne des expériences dégradées ou des erreurs d'authentification.
Bonnes pratiques et conformité
Conformité GDPR
Si vous accueillez des visiteurs européens ou opérez en Europe, le GDPR s'applique aux données que vous collectez via WeChat OAuth. 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 un avis de confidentialité clair sur le Captive Portal avant l'authentification. Vous devez respecter les demandes d'accès et de suppression des données des personnes concernées. Pour un cadre de conformité détaillé, consultez Le guide de la conformité : GDPR et confidentialité des données Guest WiFi .
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. Quel que soit ce que vous collectez, documentez votre base légale et votre période de conservation avant la mise en service.
Segmentation du réseau
Isolez le trafic WiFi invité de votre réseau d'entreprise à l'aide de la segmentation VLAN. Les invités authentifiés via WeChat doivent être redirigé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 cartes de paiement et sur les pratiques générales de sécurité d'entreprise. Pour en savoir plus sur l'architecture de segmentation, consultez Gestion de la bande passante : un guide pratique pour 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é. C'est particulièrement important pour les établissements dans les secteurs des Transports et de la Santé où la connectivité est une obligation de service.
Études de cas 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 souvent 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 (Service Account) sur la plateforme de comptes officiels (Official Accounts Platform) et une application de site Web (Website Application) 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é silencieusement. Le CRM de l'hôtel enregistre la visite de retour, 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 Hôtellerie .
Commerce de détail : analyses pour centres commerciaux
Un grand centre commercial souhaite capturer les données démographiques des acheteurs chinois afin d'orienter la répartition des locataires 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 à userinfo. L'invité voit un écran de consentement WeChat et appuie sur Autoriser. La plateforme d'analyse du centre commercial, intégrée à 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 directpermet de savoir quelles marques approcher pour des événements éphémères. Pour en savoir plus sur les déploiements WiFi dans le secteur du commerce de détail, consultez Commerce de détail .
Résolution des problèmes et atténuation des risques
Les cinq modes de défaillance les plus courants dans les déploiements de Captive Portal WeChat OAuth sont les suivants.
Incohérence de l'URI de redirection (erreur 40029). WeChat valide l'URI de redirection par rapport au domaine enregistré. Toute incohérence de sous-domaine, de chemin ou de protocole entraîne l'échec de 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. Transférez 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 aléatoire de manière cryptographique par session et validez-la lors du rappel (callback).
Échec de la détection du navigateur intégré (in-app). Ne pas détecter MicroMessenger dans l'agent utilisateur (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 perturbe les sessions MAB. Les systèmes d'exploitation mobiles modernes randomisent les adresses MAC. Les utilisateurs invités utilisant une authentification basée sur le MAB perdront leur session lors de la reconconnexion. Passez à RADIUS CoA pour une gestion de session fiable. Pour obtenir des conseils sur la configuration sécurisée du WiFi, consultez Qu'est-ce qu'un WiFi sécurisé : Guide essentiel pour les entreprises 2026 .
ROI et impact commercial
Le déploiement de la fonctionnalité de WiFi invité avec connexion WeChat a trois impacts mesurables.
Augmentation des taux d'authentification. L'élimination du point de défaillance 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 base de référence réaliste pour les portails sans support WeChat.
Qualité des données de première partie (first-party). 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 de marketing ciblé sans dépendre des cookies tiers.
Réduction des coûts de support. Une connexion fluide réduit les appels d'assistance à la réception et au service informatique de la part des clients internationaux qui rencontrent des problèmes de connexion.
Purple est présent dans plus de 80 000 sites et a traité 440 millions de connexions en 2024 (données internes de 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 du Commerce de détail et de l' Hôtellerie , 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
A web page that intercepts HTTP traffic from an unauthenticated device and requires the user to interact with it before network access is granted.
The primary interface where the WeChat login option is presented to the guest. The portal server hosts this page and orchestrates the OAuth flow.
OAuth 2.0
An industry-standard authorisation protocol (RFC 6749) that allows a third-party application to obtain limited access to an HTTP service on behalf of a user.
The underlying protocol WeChat uses to pass authentication tokens to the portal server without exposing user credentials. The same protocol used by Microsoft Entra ID, Okta, and Google Workspace.
OpenID
A unique alphanumeric identifier assigned to a specific WeChat user for a specific Official Account.
Used as the primary key to identify returning guests in the WiFi analytics database. Changes per Official Account - use UnionID for cross-property recognition.
UnionID
A single WeChat identifier representing a user across all Official Accounts and apps linked to the same Open Platform account.
Essential for hotel groups, retail chains, and stadium operators with multiple venues who need to recognise the same guest across their entire estate.
RADIUS CoA (Change of Authorization)
An extension to the RADIUS protocol (RFC 3576) that allows a RADIUS server to dynamically change the authorisation attributes of an active session.
The secure method used to move a guest device from an isolated pre-authentication VLAN to the active internet VLAN after successful WeChat login. Supported by Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet.
snsapi_base
A WeChat OAuth scope that returns only the user's OpenID and requires no consent prompt from the user.
The recommended scope for returning guest re-authentication. Easier to justify under GDPR and PIPL data minimisation principles.
snsapi_userinfo
A WeChat OAuth scope that returns the user's OpenID, nickname, avatar, gender, and city, and requires an explicit consent screen.
Used for first-time guest registration where demographic data is required for analytics. Requires documented lawful basis under GDPR and PIPL.
PIPL (Personal Information Protection Law)
China's comprehensive data privacy legislation, effective November 2021, regulating the processing of personal information of natural persons located in China.
Applies when venues process data from Chinese citizens via WeChat OAuth. Requires clear consent, purpose limitation, data minimisation, and a deletion mechanism.
AppSecret
A confidential cryptographic key issued by WeChat during application registration, used to authenticate API calls from the portal server.
Must be stored exclusively on the server side. Exposure in client-side JavaScript allows attackers to impersonate the application and call WeChat APIs maliciously.
Exemples concrets
A 400-room luxury hotel in London has a 60% portal drop-off rate among guests from mainland China. The current portal requires email and SMS verification. The IT Director needs to implement WeChat authentication while maintaining GDPR compliance and network security.
Step 1: Register a Service Account on the WeChat Official Accounts Platform (mp.weixin.qq.com) and a Website Application on the WeChat Open Platform (open.weixin.qq.com). Step 2: Configure the portal to detect the MicroMessenger user agent string. If detected, trigger the snsapi_base OAuth flow for silent authentication. If not detected, present the QR code flow. Step 3: Add a GDPR-compliant privacy notice and consent checkbox to the portal page before the WeChat login button becomes active. The notice must state: data collected (OpenID only), purpose (guest WiFi access and return visit recognition), and retention period. Step 4: After successful OAuth token exchange, the portal server issues a RADIUS CoA request to the Cisco Meraki controller, moving the guest device from the pre-auth VLAN to the segmented guest VLAN. Step 5: Store the OpenID against the device MAC address in the guest database. On subsequent visits, the returning OpenID triggers silent re-authentication.
A retail mall wants to capture gender and city data from Chinese shoppers via guest WiFi to feed into their analytics platform. They currently use MAC Authentication Bypass for their existing portal running on HPE Aruba hardware.
Step 1: Register a Service Account on the WeChat Official Accounts Platform. Step 2: Configure the portal to use snsapi_userinfo scope to retrieve gender and city. Step 3: Add a clear consent screen explaining the value exchange: free WiFi in return for profile data access. The consent must be explicit and granular under both GDPR and PIPL. Step 4: After authentication, the portal server registers the device's MAC address in the RADIUS database. The HPE Aruba controller permits access via MAB. Step 5: Document the lawful basis (consent), purpose (venue analytics and marketing), and retention period (24 months) in a data processing register. Provide a data deletion mechanism.
Questions d'entraînement
Q1. You are deploying a captive portal at a stadium. You want returning season ticket holders who have previously authenticated to connect automatically without seeing a login screen on subsequent visits. Which WeChat OAuth scope should you implement for the re-authentication flow, and why?
Conseil : Consider which scope allows for silent authentication without prompting the user for consent on each visit.
Voir la réponse type
Use snsapi_base. This scope returns only the user's OpenID and requires no consent prompt, enabling silent re-authentication. On the first visit, you store the OpenID against the fan's profile. On subsequent visits, the portal detects the returning OpenID via snsapi_base, confirms the match, and issues a RADIUS CoA to grant access - all without the fan seeing a login screen. This also aligns with GDPR data minimisation principles, as you are not collecting additional data beyond what is needed for the authentication function.
Q2. During testing, your portal successfully redirects to WeChat, the user grants consent, and WeChat redirects back to your portal. However, the portal server logs show OAuth error 40029 (invalid code). What is the most likely configuration error, and how do you resolve it?
Conseil : WeChat strictly validates the destination it sends the authorisation code to against a registered list.
Voir la réponse type
The most likely cause is a redirect URI mismatch. WeChat validates the redirect URI in the OAuth request against the authorised domain registered on the platform. If the portal server uses a different subdomain, a different path, or HTTP instead of HTTPS, the code exchange fails with error 40029. Resolution: log into the WeChat developer platform, navigate to your Service Account or Website Application settings, and add every redirect URI variant you use - including staging subdomains, different paths, and HTTPS versions. Ensure the redirect_uri parameter in your OAuth request exactly matches one of the registered URIs, including URL encoding.
Q3. An IT manager proposes embedding the WeChat AppSecret in the captive portal's front-end JavaScript to speed up the token exchange process directly from the client browser. Why must you reject this proposal, and what is the correct architecture?
Conseil : Consider the security implications of exposing cryptographic keys in publicly accessible code.
Voir la réponse type
Reject this proposal. The AppSecret is a confidential cryptographic key. Embedding it in client-side JavaScript exposes it to anyone who views the page source or intercepts network traffic. An attacker can extract the AppSecret and impersonate the application, calling WeChat APIs on the venue's behalf, accessing user data, and potentially compromising the entire Official Account. The correct architecture: the client-side portal page receives the authorisation code from WeChat and forwards it to the portal server via a server-side API call. The portal server holds the AppSecret in a secure environment variable and performs the token exchange with WeChat's API. The AppSecret never leaves the server.
Q4. A hotel group with 15 properties across Europe wants to build a unified guest profile that recognises when the same Chinese guest stays at different properties. Each property has its own WeChat Official Account. What WeChat identifier should they use, and what configuration is required?
Conseil : The OpenID is account-specific. There is a different identifier designed for cross-account recognition.
Voir la réponse type
Use the UnionID. The OpenID changes per Official Account, so the same guest will have 15 different OpenIDs across 15 accounts. The UnionID is a stable identifier representing a user across all Official Accounts and apps linked to the same Open Platform account. Configuration required: link all 15 Official Accounts to a single WeChat Open Platform account. Once linked, the UnionID is returned in the OAuth response when the user has authorised at least one of the linked accounts. Use the UnionID as the primary key in the guest CRM to build cross-property profiles and recognise returning guests regardless of which property they visit.
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 en détail 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 satellite et à garantir la conformité réglementaire.
Gestion du WiFi pour les clients d'hôtels : Intégration du PMS, des portails et des normes de marque
Ce guide technique détaille comment concevoir des réseaux WiFi hôteliers de classe entreprise, en se concentrant sur la segmentation VLAN, l'intégration PMS pour la gestion automatisée des sessions et l'optimisation du Captive Portal pour une collecte de données conforme au GDPR.
Captive Portal Best Practices: Designing for High Conversion and Compliance
Ce guide technique offre aux responsables informatiques, architectes réseau et directeurs de l'exploitation des sites un modèle complet pour déployer des Captive Portals qui concilient sécurité réseau et taux de conversion élevé. Il couvre l'intégralité 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 s'appuie sur des données de déploiement réelles.