Comment configurer l'authentification OAuth WeChat pour les Captive Portals

COMMENT CONFIGURER L'AUTHENTIFICATION OAUTH WECHAT POUR LES PORTALS CAPTIFS Une fiche technique Purple - Environ 10 minutes --- INTRODUCTION ET CONTEXTE (environ 1 minute) Bienvenue. Si vous êtes responsable du WiFi invité dans un hôtel, une chaîne de magasins, un stade ou un centre de conférence accueillant des visiteurs chinois, cette fiche technique vous est destinée. WeChat compte 1,38 milliard d'utilisateurs actifs mensuels, selon les données 2024 de Tencent. La grande majorité se trouve en Chine, mais la plateforme dispose également d'une empreinte internationale significative : quatre millions d'utilisateurs aux États-Unis, 12 millions en Malaisie, et des chiffres en croissance en Asie du Sud-Est, en Europe et au Moyen-Orient. Lorsqu'un client chinois se connecte à votre WiFi et voit une page de connexion proposant uniquement l'e-mail, Facebook ou un code coupon, il est immédiatement confronté à une friction. Il se peut qu'il n'ait pas d'adresse e-mail locale configurée sur cet appareil. En revanche, il dispose presque certainement de WeChat. La question n'est donc pas de savoir si vous devez proposer la connexion WeChat, mais comment la configurer correctement, de manière sécurisée et afin de générer des données de première partie exploitables. C'est ce que nous allons aborder aujourd'hui. Nous allons détailler le flux OAuth 2.0, les deux enregistrements de plateforme requis, le choix de la portée (scope) qui détermine les données collectées, le mécanisme d'application côté réseau et les considérations de conformité essentielles en 2026. --- ANALYSE TECHNIQUE APPROFONDIE (environ 5 minutes) Commençons par l'architecture. Un Captive Portal intercepte le trafic HTTP d'un appareil non authentifié et le redirige vers une page de connexion. Cette page de connexion est hébergée sur un serveur de portail, soit sur site, soit dans le cloud. Lorsque vous ajoutez l'authentification OAuth WeChat, vous insérez un fournisseur d'identité tiers dans ce flux. Voici la séquence. L'invité se connecte à votre SSID. L'access point ou le contrôleur sans fil détecte que l'appareil n'a pas de session authentifiée et redirige tout le trafic HTTP vers l'URL de votre Captive Portal. La page du portail se charge et présente les options de connexion, y compris WeChat. L'invité appuie sur la connexion WeChat. Votre serveur de portail redirige le navigateur vers le point de terminaison d'autorisation de WeChat à l'adresse open.weixin.qq.com, en transmettant votre AppID, l'URI de redirection, le type de réponse (code) et la portée (scope). WeChat gère l'authentification entièrement sur ses propres serveurs. Si l'invité est déjà connecté à WeChat dans son navigateur, un écran de consentement s'affiche. S'il utilise le navigateur intégré à l'application WeChat, l'expérience peut être transparente avec la portée snsapi_base, sans aucune demande de consentement. WeChat redirige ensuite vers l'URI de redirection de votre portail avec un code d'autorisation temporaire. Votre serveur de portail échange ce code contre un jeton d'accès (access token) en appelant api.weixin.qq.com/sns/oauth2/access_token, en transmettant votre AppID, votre AppSecret, le code et le type d'octroi (grant type) 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 vous avez demandé la portée snsapi_userinfo, vous pouvez alors effectuer un second appel API pour récupérer le pseudo, l'avatar, le genre et la ville de l'utilisateur.Passons maintenant aux deux enregistrements de plateforme. C'est là que la plupart des implémentations échouent. WeChat dispose de deux plateformes de développement distinctes. La WeChat Open Platform (open.weixin.qq.com) gère les applications web et les applications mobiles. La WeChat Official Accounts Platform (mp.weixin.qq.com) gère les comptes publics — ce dont la plupart des établissements ont réellement besoin. Pour un Captive Portal destiné aux visiteurs utilisant le navigateur intégré de l'application WeChat, vous avez besoin d'un Service Account sur la plateforme Official Accounts. Un Subscription Account ne fonctionnera pas, car il ne dispose pas des autorisations d'authentification de page web OAuth. Un Service Account en dispose et prend en charge les portées snsapi_base et snsapi_userinfo. Pour un Captive Portal accessible depuis un navigateur mobile standard en dehors de WeChat (Chrome sur Android, Safari sur iOS), vous devez enregistrer une Website Application sur l'Open Platform. Celle-ci utilise la portée snsapi_login et présente un code QR que l'utilisateur scanne avec son application WeChat. En pratique, la plupart des déploiements sur site utilisent les deux. Un visiteur connecté au WiFi d'un hôtel peut ouvrir le portail dans Chrome, voir un code QR, le scanner avec WeChat et s'authentifier. Il peut également suivre un lien directement dans WeChat, arriver sur le navigateur intégré et s'authentifier de manière transparente avec snsapi_base. Abordons maintenant le choix de la portée (scope), car il s'agit d'une décision stratégique. snsapi_base renvoie uniquement l'OpenID, un identifiant unique pour cet utilisateur au sein de votre Official Account. Elle ne nécessite aucune demande de consentement de l'utilisateur. L'authentification est invisible pour ce dernier. C'est la solution idéale pour les visiteurs récurrents dont vous possédez déjà le profil, ou pour les établissements qui souhaitent éliminer toute friction au détriment de la collecte de nouvelles données. snsapi_userinfo renvoie l'OpenID ainsi que le pseudo WeChat de l'utilisateur, sa photo de profil, son genre, ses paramètres de langue et sa ville. Elle nécessite un écran de consentement explicite. L'utilisateur voit s'afficher un message lui demandant s'il autorise votre Official Account à accéder à ses informations. La plupart des utilisateurs acceptent, mais cela ajoute une étape. Le bon choix dépend de votre cas d'usage. Pour l'enregistrement d'un nouveau visiteur dont vous souhaitez créer le profil, utilisez snsapi_userinfo et associez-le à une interface de consentement conforme au GDPR sur votre page de portail. Pour un visiteur récurrent qui a déjà donné son consentement et dont vous possédez déjà le profil, utilisez snsapi_base pour une réauthentification transparente. Enfin, l'aspect contrôle du réseau. L'obtention d'un jeton OAuth prouve l'identité, mais elle n'ouvre pas automatiquement le réseau. Vous devez disposer d'un mécanisme pour convertir une authentification réussie en un accès réseau.Les deux approches standard sont le RADIUS Change of Authorisation (CoA), défini dans la RFC 3576, et le contournement par adresse MAC (MAC address bypass). Avec le RADIUS CoA, votre serveur de portail envoie une requête CoA au contrôleur réseau après la réussite de l'OAuth, et le contrôleur déplace l'appareil du VLAN non authentifié vers le VLAN invité. Cela fonctionne avec Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist et la plupart des contrôleurs de classe entreprise. Avec le contournement MAC, le serveur de portail enregistre l'adresse MAC de l'appareil en tant que client autorisé, et le contrôleur l'autorise. Le contournement MAC est plus simple à implémenter mais moins sécurisé, car les adresses MAC peuvent être usurpées. La plateforme Guest WiFi de Purple gère ces deux mécanismes. Une fois l'OAuth WeChat terminé, l'overlay cloud de Purple envoie le signal approprié au matériel sous-jacent, qu'il s'agisse de Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme ou Fortinet. L'opérateur du site n'a pas besoin de gérer cette traduction manuellement. --- RECOMMANDATIONS D'IMPLÉMENTATION ET PIÈGES À ÉVITER (environ 2 minutes) Voici les cinq facteurs qui provoquent l'échec des implémentations de Captive Portal avec OAuth WeChat. Premièrement : l'incohérence de l'URI de redirection. WeChat valide l'URI de redirection par rapport au domaine autorisé que vous avez enregistré sur la plateforme. Si votre serveur de portail utilise un sous-domaine différent, un chemin différent ou du HTTP au lieu du HTTPS, le flux OAuth échoue avec l'erreur 40029 - code invalide. Enregistrez chaque variante de domaine que vous utilisez, y compris les environnements de staging. Deuxièmement : l'AppSecret côté client. Votre AppSecret ne doit jamais apparaître dans le JavaScript côté client ni dans le binaire d'une application mobile. Sa place est sur votre serveur. S'il est exposé, n'importe qui peut usurper l'identité de votre application et appeler les API de WeChat en votre nom. Troisièmement : l'absence de protection CSRF. Le paramètre d'état (state) dans la requête OAuth existe spécifiquement pour empêcher la falsification de requête intersite (CSRF). Générez une valeur d'état aléatoire de manière cryptographique, stockez-la dans la session de l'utilisateur et validez-la lorsque WeChat redirige l'utilisateur. Si vous ignorez cette étape, vous vous exposez à une réelle vulnérabilité. Quatrièmement : le défaut de détection du navigateur intégré (in-app). Le navigateur intégré de WeChat définit une chaîne d'agent utilisateur (user agent) spécifique contenant "MicroMessenger". Si votre portail ne détecte pas cela et ne propose pas le flux OAuth correct (flux Official Account pour le navigateur intégré, flux QR Open Platform pour les navigateurs standards), les utilisateurs se retrouveront face à une expérience dysfonctionnelle ou à une erreur. Cinquièmement : l'alignement avec le GDPR et la PIPL. Si vous accueillez des visiteurs européens, le GDPR s'applique aux données que vous collectez via l'OAuth WeChat. Si vous accueillez des visiteurs chinois, la loi chinoise sur la protection des informations personnelles (PIPL) s'applique à la manière dont vous traitez leurs données. Les deux réglementations exigent une base légale pour le traitement, une limitation claire des finalités et la minimisation des données. Le paramètre snsapi_base est plus facile à justifier au titre des principes de minimisation des données que snsapi_userinfo. Quel que soit votre choix de collecte, documentez votre base légale et votre durée de conservation. --- QUESTIONS-RÉPONSES RAPIDES (environ 1 minute) Question : Puis-je utiliser la connexion WeChat sur un portail qui propose également la connexion par e-mail et par SMS ? Oui. La plupart des plateformes de portail d'entreprise, y compris Purple, prennent en charge plusieurs méthodes d'authentification sur la même page de portail. WeChat apparaît comme une option parmi d'autres. Question : L'OAuth WeChat fonctionne-t-il sur iOS ? Oui, mais avec une nuance. Le framework App Tracking Transparency d'Apple n'affecte pas les flux OAuth côté serveur. La connexion WeChat dans Safari sur iOS fonctionne via le flux de code QR ou le flux de redirection. L'application WeChat elle-même gère l'authentification. Question : Que se passe-t-il si l'API de WeChat est indisponible ? Votre portail doit implémenter une solution de repli. Si l'appel de l'API WeChat expire ou renvoie une erreur, redirigez l'utilisateur vers une autre méthode de connexion. Ne le laissez pas devant un écran vide. Question : Puis-je utiliser l'OpenID comme identifiant client persistant ? Au sein de votre compte officiel, oui. L'OpenID est stable pour un utilisateur donné et un compte officiel donné. Si vous possédez plusieurs comptes officiels, le même utilisateur aura des OpenID différents pour chacun d'eux. Pour la résolution d'identité multi-comptes, WeChat fournit un UnionID, ce qui nécessite que vos comptes soient liés sur la plateforme ouverte. --- RÉSUMÉ ET PROCHAINES ÉTAPES (environ 1 minute) En résumé. L'authentification OAuth WeChat pour les portails captifs est un exercice d'enregistrement sur deux plateformes, une décision de portée (scope), une intégration de l'application du réseau et un examen de la conformité. Réussissez ces quatre étapes et vous disposerez d'une méthode de connexion qui dessert plus d'un milliard de visiteurs potentiels sans aucune friction liée aux mots de passe. Les prochaines étapes pratiques sont les suivantes. Tout d'abord, déterminez si vos visiteurs accèdent au portail depuis le navigateur intégré de WeChat ou depuis un navigateur mobile standard ; cela détermine l'enregistrement de plateforme dont vous avez besoin. Deuxièmement, décidez de la portée (scope) : snsapi_base pour les clients récurrents, snsapi_userinfo pour un premier enregistrement avec consentement. Troisièmement, confirmez que votre matériel réseau prend en charge RADIUS CoA ou configurez le contournement MAC comme alternative. Quatrièmement, examinez votre avis de confidentialité et votre flux de consentement par rapport aux exigences du GDPR et de la PIPL. Cinquièmement, testez l'URI de redirection, la validation du paramètre d'état et la détection du navigateur intégré à l'application avant de lancer la mise en production. Si vous souhaitez découvrir comment Purple gère l'OAuth WeChat dans le cadre d'une plateforme plus large de Guest WiFi et d'analyse — sur 80 000 sites et 440 millions de connexions en 2024 — visitez purple.ai ou contactez votre équipe de compte. Merci pour votre écoute. --- FIN DU SCRIPT