Comment configurer l'authentification OAuth WeChat pour les portails captifs

COMMENT CONFIGURER L'AUTHENTIFICATION OAUTH WECHAT POUR LES PORTALS CAPTIFS Une fiche technique de Purple - Environ 10 Minutes --- INTRODUCTION ET CONTEXTE (environ 1 minute) Bienvenue. Si vous êtes responsable du WiFi pour invités dans un hôtel, une chaîne de vente au détail, 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 de Tencent pour 2024. 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 dans toute l'Asie du Sud-Est, l'Europe et le Moyen-Orient. Lorsqu'un visiteur chinois se connecte à votre WiFi et voit une page de connexion proposant uniquement l'e-mail, Facebook ou un code de bon d'achat, il est confronté à un obstacle immédiat. 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 plutôt comment la configurer correctement, de manière sécurisée et afin de générer des données de première partie que vous pouvez réellement utiliser. C'est ce que nous allons aborder aujourd'hui. Nous allons passer en revue le flux OAuth 2.0, les deux enregistrements de plateforme nécessaires, le choix de la portée qui détermine les données que vous collectez, le mécanisme d'application côté réseau et les considérations de conformité importantes en 2026. --- ZOOM TECHNIQUE (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 WeChat OAuth, vous insérez un fournisseur d'identité tiers dans ce flux. Voici la séquence. L'invité se connecte à votre SSID. Le point d'accès 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. WeChat gère l'authentification entièrement sur ses propres serveurs. Si l'invité est déjà connecté à WeChat dans son navigateur, il voit un écran de consentement. S'il utilise le navigateur intégré à l'application WeChat, l'expérience peut être transparente avec la portée snsapi_base - sans aucun écran 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 en appelant api.weixin.qq.com/sns/oauth2/access_token, en transmettant votre AppID, AppSecret, le code et le type d'attribution d'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 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.Maintenant, les deux enregistrements de plateforme. C'est ici que la plupart des implémentations échouent. WeChat dispose de deux plateformes de développement distinctes. La WeChat Open Platform sur open.weixin.qq.com gère les applications de sites web et les applications mobiles. La WeChat Official Accounts Platform sur 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 invités via le navigateur intégré de WeChat, vous avez besoin d'un compte de service (Service Account) sur la Official Accounts Platform. Un compte d'abonnement (Subscription Account) ne fonctionnera pas - il ne dispose pas des autorisations d'autorisation de page web OAuth. Un compte de service les possède 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 avez besoin d'une application de site web enregistrée 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 invité sur le WiFi 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, atterrir dans le navigateur intégré et s'authentifier silencieusement avec snsapi_base. Parlons du choix de la portée, car c'est un véritable point de décision. snsapi_base renvoie uniquement l'OpenID - un identifiant unique pour cet utilisateur au sein de votre compte officiel. Il ne nécessite aucune demande de consentement de l'utilisateur. L'authentification est invisible pour l'utilisateur. C'est l'idéal pour les invités récurrents dont vous avez déjà établi le profil, ou pour les établissements où vous souhaitez une friction nulle au prix de zéro nouvelle donnée. snsapi_userinfo renvoie l'OpenID plus le pseudonyme WeChat de l'utilisateur, sa photo de profil, son genre, ses paramètres de langue et sa ville. Il nécessite un écran de consentement explicite. L'utilisateur voit une invite lui demandant s'il autorise votre compte officiel à accéder à ses informations. La plupart des utilisateurs acceptent, mais cela crée une friction. Le bon choix dépend de votre cas d'usage. Pour l'enregistrement d'un nouvel invité dont vous souhaitez créer le profil, utilisez snsapi_userinfo et associez-le à une couche de consentement conforme au GDPR sur votre page de portail. Pour un invité 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 silencieuse. Maintenant, passons à l'application réseau. L'obtention d'un jeton OAuth prouve l'identité, mais n'ouvre pas automatiquement le réseau. Vous avez besoin d'un mécanisme pour traduire une authentification réussie en accès réseau. Les deux approches standard sont le RADIUS Change of Authorisation (CoA), défini dans la RFC 3576, et le contournement d'adresse MAC (MAC bypass). Avec RADIUS CoA, votre serveur de portail envoie une requête CoA au contrôleur réseau après une authentification OAuth réussie, 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 à mettre en œuvre mais moins sécurisé, car les adresses MAC peuvent être usurpées. La plateforme Guest WiFi de Purple prend en charge ces deux mécanismes. Une fois l'authentification OAuth WeChat terminée, 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 Networks ou Fortinet. L'exploitant du site n'a pas besoin de gérer cette traduction manuellement. - - - RECOMMANDATIONS DE MISE EN ŒUVRE ET PIÈGES À ÉVITER (environ 2 minutes) Voici les cinq facteurs qui provoquent l'échec des implémentations de portails captifs avec authentification OAuth WeChat. Premier point : 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 HTTP au lieu de 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ème point : l'AppSecret côté client. Votre AppSecret ne doit jamais apparaître dans le JavaScript côté client ou 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ème point : 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êtes intersites. 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. Ignorez cette étape et vous aurez une véritable vulnérabilité. Quatrième point : l'absence de détection du navigateur intégré. Le navigateur intégré de WeChat définit une chaîne d'agent utilisateur spécifique contenant "MicroMessenger". Si votre portail ne détecte pas cela et ne propose pas le bon flux OAuth - le flux Official Account pour le navigateur intégré, le flux QR Open Platform pour les navigateurs standard - les utilisateurs se retrouveront face à une expérience dégradée ou une erreur. Cinquième point : la conformité GDPR et PIPL. Si vous accueillez des visiteurs européens, le GDPR s'applique aux données que vous collectez via l'authentification 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. snsapi_base est plus facile à justifier selon les principes de minimisation des données que snsapi_userinfo. Quel que soit votre choix de collecte, documentez votre base juridique 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 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'authentification WeChat OAuth fonctionne-t-elle 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 mettre en œuvre une solution de repli. Si l'appel API WeChat expire ou renvoie une erreur, redirigez l'utilisateur vers une méthode de connexion alternative. Ne le laissez pas devant un écran vide. Question : Puis-je utiliser l'OpenID comme identifiant client persistant ? Au sein de votre compte officiel (Official Account), 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 l'Open Platform. - RÉSUMÉ ET PROCHAINES ÉTAPES (environ 1 minute) Pour résumer. L'authentification WeChat OAuth pour les Captive Portals est un exercice d'enregistrement sur deux plateformes, une décision de portée (scope), une intégration d'application réseau et un examen de conformité. Maîtrisez ces quatre aspects et vous disposerez d'une méthode de connexion qui s'adresse à plus d'un milliard de visiteurs potentiels sans aucune friction liée aux mots de passe. Les étapes pratiques suivantes sont les suivantes. Tout d'abord, déterminez si vos visiteurs accèdent au portail depuis le navigateur intégré à l'application 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 - snsapi_base pour les clients récurrents, snsapi_userinfo pour un premier enregistrement avec consentement. Troisièmement, confirmez que votre équipement réseau prend en charge le RADIUS CoA ou configurez le bypass MAC comme alternative. Quatrièmement, examinez votre politique de confidentialité et votre flux de consentement au regard des exigences du GDPR et de la PIPL. Cinquièmement, testez l'URI de redirection, la validation du paramètre d'état (state) et la détection du navigateur intégré à l'application avant de déployer. Si vous souhaitez voir comment Purple gère le WeChat OAuth dans le cadre d'une plateforme plus large de WiFi invité et d'analyses - sur 80 000 sites et 440 millions de connexions en 2024 - visitez purple.ai ou contactez votre équipe commerciale. Merci pour votre écoute. - FIN DU SCRIPT