Integrating WeChat WiFi Authentication: Captive Portal Onboarding for APAC Customers

WeChat hat 1,41 Milliarden monatlich aktive Nutzer und ist damit die primäre digitale Identität für chinesische Verbraucher weltweit. Dieser Leitfaden erklärt, wie Sie die WeChat OAuth 2.0-Authentifizierung in Captive Portals von Unternehmen für APAC-Standorte integrieren. Er behandelt die Plattformregistrierung, die Auswahl des Scopes, die Durchsetzung von RADIUS Change of Authorisation sowie die Einhaltung des dualen Frameworks aus GDPR und Chinas PIPL. Er richtet sich an IT-Manager, Netzwerkarchitekten und Leiter des Standortbetriebs, die in diesem Quartal handeln müssen.

📖 9 Min. Lesezeit📝 2,130 Wörter🔧 2 ausgearbeitete Beispiele❓ 4 Übungsfragen📚 10 Schlüsseldefinitionen

Diesen Leitfaden anhören

Podcast-Transkript ansehen

KONFIGURATION DER WECHAT OAUTH-AUTHENTIFIZIERUNG FÜR CAPTIVE PORTALS
Ein technisches Briefing von Purple - ca. 10 Minuten

EINFÜHRUNG UND KONTEXT (ca. 1 Minute)

Herzlich willkommen. Wenn Sie für das Gäste-WiFi in einem Hotel, einer Einzelhandelskette, einem Stadion oder einem Konferenzzentrum verantwortlich sind, das chinesische Besucher bedient, ist dieses Briefing genau das Richtige für Sie.

Laut eigenen Angaben von Tencent verzeichnet WeChat im Jahr 2025 monatlich 1,41 Milliarden aktive Nutzer. Die überwiegende Mehrheit befindet sich in China, aber die Plattform verfügt auch über eine beachtliche internationale Präsenz. Malaysia zählt 12 Millionen WeChat-Nutzer. Japan hat 5,5 Millionen. Südkorea 5 Millionen. Und die Zahlen in Südostasien, dem Nahen Osten und Europa steigen kontinuierlich.

Wenn sich ein chinesischer Gast mit Ihrem WiFi verbindet und eine Anmeldeseite sieht, die nur E-Mail, Facebook oder einen Gutscheincode anbietet, stößt er sofort auf Barrieren. Möglicherweise ist auf dem Gerät keine lokale E-Mail-Adresse eingerichtet. Aber sie haben mit an Sicherheit grenzender Wahrscheinlichkeit WeChat. Die Frage ist also nicht, ob Sie einen WeChat-Login anbieten sollten. Es geht darum, wie Sie ihn korrekt, sicher und so konfigurieren, dass Sie nutzbare First-Party-Daten generieren.

Genau darum geht es heute. Wir gehen den OAuth 2.0-Ablauf durch, die beiden erforderlichen Plattform-Registrierungen, die Scope-Entscheidung, die bestimmt, welche Daten Sie erfassen, den netzwerkseitigen Durchsetzungsmechanismus sowie die Compliance-Aspekte, die im Jahr 2026 von Bedeutung sind.

TECHNISCHER DEEP-DIVE (ca. 5 Minuten)

Beginnen wir mit der Architektur. Ein Captive Portal fängt den HTTP-Traffic von einem nicht authentifizierten Gerät ab und leitet ihn auf eine Anmeldeseite weiter. Diese Anmeldeseite wird auf einem Portalserver gehostet, entweder lokal oder in der Cloud. Wenn Sie WeChat-OAuth hinzufügen, binden Sie einen Drittanbieter-Identitätsanbieter in diesen Ablauf ein.

Der Ablauf sieht wie folgt aus: Der Gast verbindet sich mit Ihrer SSID. Der Access Point oder Wireless Controller erkennt, dass das Gerät keine authentifizierte Sitzung hat, und leitet den gesamten HTTP-Traffic an Ihre Captive Portal-URL weiter. Die Portalseite lädt und zeigt die Anmeldeoptionen an, einschließlich WeChat. Der Gast tippt auf den WeChat-Login. Ihr Portalserver leitet den Browser an den Autorisierungsendpunkt von WeChat weiter und übergibt dabei Ihre AppID, die Redirect-URI, den Antworttyp „code“ und den Scope.

WeChat wickelt die Authentifizierung vollständig auf den eigenen Servern ab. Wenn der Gast bereits in seinem Browser bei WeChat angemeldet ist, sieht er einen Zustimmungsbildschirm. Wenn er den In-App-Browser von WeChat nutzt, kann der Vorgang mit dem Scope „snsapi_base“ geräuschlos ablaufen, d. h. ohne jegliche Zustimmungsaufforderung. WeChat leitet dann mit einem temporären Autorisierungscode zurück an die Redirect-URI Ihres Portals. Ihr Portalserver tauscht diesen Code durch einen Aufruf der WeChat-API gegen ein Access-Token aus. WeChat gibt ein Access-Token, ein Refresh-Token, die OpenID des Nutzers und den gewährten Scope zurück. Wenn Sie den Scope „snsapi_userinfo“ angefordert haben, können Sie in einem zweiten API-Aufruf den Spitznamen, das Profilbild, das Geschlecht und die Stadt des Nutzers abrufen.

Nun zu den beiden Plattform-Registrierungen. Hier treten bei den meisten Implementierungen die Fehler auf.

WeChat hat zwei separate Entwicklerplattformen. Die WeChat Open Platform verwaltet Website-Anwendungen und mobile Apps. Die WeChat Official Accounts Platform verwaltet öffentliche Konten, was die meisten Standorte tatsächlich benötigen.

Für ein Captive Portal, das Gästen innerhalb des WeChat-In-App-Browsers angezeigt wird, benötigen Sie ein Service-Konto auf der Official Accounts Platform. Ein Abonnement-Konto funktioniert nicht. Dieses verfügt nicht über die Berechtigungen zur OAuth-Webseiten-Autorisierung. Ein Service-Konto hingegen schon und es unterstützt sowohl den Scope snsapi base als auch snsapi userinfo.

Für ein Captive Portal, auf das über einen Standard-Mobilbrowser außerhalb von WeChat zugegriffen wird, wie z. B. Chrome auf Android oder Safari auf iOS, benötigen Sie eine auf der Open Platform registrierte Website-Anwendung. Diese nutzt den Scope snsapi login und zeigt einen QR-Code an, den der Benutzer mit seiner WeChat-App scannt.

In der Praxis nutzen die meisten Standort-Installationen beides. Ein Gast in einem Hotel öffnet das Portal möglicherweise in Chrome, sieht einen QR-Code, scannt ihn mit WeChat und authentifiziert sich. Oder er folgt einem Link direkt in WeChat, landet im In-App-Browser und authentifiziert sich geräuschlos über snsapi base.

Lassen Sie uns über die Auswahl des Scopes sprechen, da dies eine echte Entscheidung darstellt.

Der Scope snsapi base gibt nur die OpenID zurück. Dies ist eine eindeutige Kennung für diesen Benutzer innerhalb Ihres Official Accounts. Es ist keine Zustimmung des Benutzers erforderlich. Die Authentifizierung ist für den Benutzer unsichtbar. Dies ist ideal für wiederkehrende Gäste, von denen Sie bereits ein Profil haben, oder für Standorte, an denen Sie keinerlei Reibungsverluste auf Kosten neuer Daten wünschen.

Der Scope snsapi userinfo gibt die OpenID sowie den WeChat-Spitznamen, das Profilbild, das Geschlecht, die Spracheinstellung und die Stadt des Benutzers zurück. Dies erfordert einen expliziten Zustimmungsbildschirm. Der Benutzer sieht eine Aufforderung mit der Frage, ob er Ihrem Official Account den Zugriff auf seine Informationen gestattet. Die meisten Benutzer akzeptieren dies, aber es entsteht ein Reibungspunkt.

Die richtige Wahl hängt von Ihrem Anwendungsfall ab. Für die Erstregistrierung eines Gastes, bei der Sie ein Profil erstellen möchten, verwenden Sie snsapi userinfo und kombinieren Sie dies mit einer GDPR-konformen Zustimmungsebene auf Ihrer Portal-Seite. Für einen wiederkehrenden Gast, der bereits zugestimmt hat und dessen Profil Sie bereits besitzen, verwenden Sie snsapi base für eine geräuschlose erneute Authentifizierung.

Nun zur Seite der Netzwerkdurchsetzung. Der Erhalt eines OAuth-Tokens beweist die Identität, öffnet aber nicht automatisch das Netzwerk. Sie benötigen einen Mechanismus, um eine erfolgreiche Authentifizierung in einen Netzwerkzugriff zu übersetzen.

Die beiden Standardansätze sind RADIUS Change of Authorisation, definiert in RFC 3576, und MAC-Adressen-Bypass. Bei RADIUS CoA sendet Ihr Portal-Server nach erfolgreichem OAuth eine CoA-Anfrage an den Netzwerk-Controller, und der Controller verschiebt das Gerät aus dem unauthentifizierten VLAN in das Gäste-VLAN. Dies funktioniert mit Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet.

Mit dem MAC-Bypass registriert der Portal-Server die MAC-Adresse des Geräts als autorisierten Client, und der Controller lässt sie zu. Der MAC-Bypass ist einfacher zu implementieren, aber weniger sicher, da MAC-Adressen gefälscht werden können und moderne Smartphones zunehmend eine MAC-Adressen-Randomisierung verwenden, was den Mechanismus bei einer erneuten Verbindung unterbricht.

Die Guest WiFi-Plattform von Purple unterstützt beide Mechanismen. Nach Abschluss des WeChat-OAuth sendet das Cloud-Overlay von Purple das entsprechende Signal an die zugrunde liegende Hardware. Der Betreiber des Veranstaltungsorts muss diese Übersetzung nicht manuell verwalten.

EMPFEHLUNGEN FÜR DIE IMPLEMENTIERUNG UND FALLSTRICKE (ca. 2 Minuten)

Hier sind die fünf Gründe, warum Implementierungen von WeChat-OAuth-Captive Portals scheitern.

Erstens: Abweichung bei der Redirect-URI. WeChat validiert die Redirect-URI mit der autorisierten Domain, die Sie auf der Plattform registriert haben. Wenn Ihr Portal-Server eine andere Subdomain, einen anderen Pfad oder HTTP anstelle von HTTPS verwendet, schlägt der OAuth-Flow mit dem Fehler 40029 fehl, was einen ungültigen Code bedeutet. Registrieren Sie jede von Ihnen verwendete Domain-Variante, einschließlich Staging-Umgebungen.

Zweitens: Das AppSecret auf der Client-Seite. Ihr AppSecret darf niemals im clientseitigen JavaScript oder in einer mobilen App-Binärdatei erscheinen. Es gehört auf Ihren Server. Wenn es offengelegt wird, kann jeder Ihre Anwendung imitieren und WeChat-APIs in Ihrem Namen aufrufen.

Drittens: Fehlender CSRF-Schutz. Der State-Parameter in der OAuth-Anfrage existiert speziell zur Verhinderung von Cross-Site-Request-Forgery. Generieren Sie einen kryptografisch zufälligen State-Wert, speichern Sie ihn in der Sitzung des Benutzers und validieren Sie ihn, wenn WeChat zurückleitet. Wenn Sie dies überspringen, haben Sie eine echte Sicherheitslücke.

Viertens: Die Lücke bei der Erkennung von In-App-Browsern. Der In-App-Browser von WeChat setzt einen spezifischen User-Agent-String, der „MicroMessenger“ enthält. Wenn Ihr Portal dies nicht erkennt und den korrekten OAuth-Flow bereitstellt, erhalten Benutzer eine fehlerhafte Benutzererfahrung oder eine Fehlermeldung.

Fünftens: Abstimmung mit GDPR und PIPL. Wenn Sie europäische Besucher bedienen, gilt die GDPR für die Daten, die Sie über WeChat-OAuth erfassen. Wenn Sie chinesische Besucher bedienen, gilt das chinesische Gesetz zum Schutz persönlicher Daten (Personal Information Protection Law, bekannt als PIPL) für die Verarbeitung ihrer Daten. Beide erfordern eine Rechtsgrundlage für die Verarbeitung, eine klare Zweckbindung und Datenminimierung. Der Bereich „snsapi_base“ ist unter den Grundsätzen der Datenminimierung leichter zu rechtfertigen als „snsapi_userinfo“. Was auch immer Sie erfassen, dokumentieren Sie Ihre Rechtsgrundlage und Ihre Aufbewahrungsfrist.

SCHNELLE FRAGEN UND ANTWORTEN (ca. 1 Minute)

Frage: Kann ich den WeChat-Login auf einem Portal verwenden, das auch E-Mail- und SMS-Login anbietet?
Ja. Die meisten Enterprise-Portal-Plattformen, einschließlich Purple, unterstützen mehrere Authentifizierungsmethoden auf derselben Portalseite. WeChat wird als eine Option neben anderen angezeigt.

Frage: Funktioniert WeChat-OAuth auf iOS?
Ja, aber mit einer Nuance. Das App-Tracking-Transparency-Framework von Apple hat keinen Einfluss auf serverseitige OAuth-Flows. Der WeChat-Login in Safari auf iOS funktioniert über den QR-Code-Flow oder den Redirect-Flow. Die WeChat-App selbst übernimmt die Authentifizierung.
Frage: Was passiert, wenn die API von WeChat nicht verfügbar ist?
Ihr Portal sollte einen Fallback implementieren. Wenn der WeChat-API-Aufruf ein Timeout aufweist oder einen Fehler zurückgibt, leiten Sie den Benutzer zu einer alternativen Anmeldemethode weiter. Lassen Sie ihn nicht vor einem leeren Bildschirm stehen.

Frage: Kann ich die OpenID als dauerhafte Kundenkennung verwenden?
Innerhalb Ihres Official Accounts: Ja. Die OpenID ist für einen bestimmten Benutzer und einen bestimmten Official Account stabil. Wenn Sie mehrere Official Accounts haben, hat derselbe Benutzer in diesen Konten unterschiedliche OpenIDs. Für die kontoübergreifende Identitätsauflösung stellt WeChat eine UnionID bereit, wofür Ihre Konten auf der Open Platform verknüpft sein müssen.

ZUSAMMENFASSUNG UND NÄCHSTE SCHRITTE (ca. 1 Minute)

Zusammenfassend lässt sich sagen: Die WeChat-OAuth-Authentifizierung für Captive Portals ist eine Registrierung auf zwei Plattformen, eine Entscheidung über den Scope, eine Integration der Netzwerkdurchsetzung und eine Compliance-Prüfung. Wenn Sie diese vier Punkte richtig umsetzen, erhalten Sie eine Anmeldemethode, die über eine Milliarde potenzieller Besucher ohne Passwort-Hürden bedient.

Die praktischen nächsten Schritte sind folgende: Bestimmen Sie erstens, ob Ihre Besucher auf das Portal innerhalb des WeChat-In-App-Browsers oder in einem Standard-Mobilbrowser stoßen. Das entscheidet, welche Plattformregistrierung Sie benötigen. Entscheiden Sie zweitens über den Scope. Verwenden Sie „snsapi_base“ für wiederkehrende Gäste und „snsapi_userinfo“ für die Erstregistrierung mit Einwilligung. Bestätigen Sie drittens, dass Ihre Netzwerkhardware RADIUS CoA unterstützt, oder konfigurieren Sie alternativ einen MAC-Bypass. Überprüfen Sie viertens Ihre Datenschutzerklärung und den Einwilligungs-Flow im Hinblick auf die Anforderungen der GDPR und des PIPL. Testen Sie fünftens den Redirect-URI, die Validierung des State-Parameters und die Erkennung des In-App-Browsers, bevor Sie live gehen.

Wenn Sie sehen möchten, wie Purple WeChat-OAuth als Teil einer umfassenderen Guest-WiFi- und Analyseplattform an 80.000 Standorten und bei 440 Millionen Logins im Jahr 2024 handhabt, besuchen Sie purple.ai oder sprechen Sie mit Ihrem Account-Team.

Vielen Dank fürs Zuhören.

Wichtigste Erkenntnisse

✓WeChat hat 1,41 Milliarden monatlich aktive Nutzer (Tencent, 2025) und ist damit die primäre digitale Identität für chinesische Verbraucher. Standorte, die Gäste aus der APAC-Region bedienen, können es sich nicht leisten, diese Option bei der Anmeldung über ihr Captive Portal wegzulassen.
✓Es sind zwei Plattform-Registrierungen erforderlich: ein Service Account auf der Official Accounts Platform für den Zugriff über den In-App-Browser und eine Website Application auf der Open Platform für den Zugriff über Standard-Browser. Die Verwendung des falschen Registrierungstyps ist der häufigste Fehler bei der Implementierung.
✓Die Auswahl des Scopes ist eine echte Architekturentscheidung. Nutzen Sie snsapi_base für eine lautlose, reibungslose Authentifizierung, die nur eine OpenID zurückgibt. Nutzen Sie snsapi_userinfo, um demografische Daten zu erfassen, und akzeptieren Sie dabei die Hürde eines Zustimmungsbildschirms.
✓OAuth beweist die Identität, öffnet aber nicht das Netzwerk. RADIUS Change of Authorisation (RFC 3576) ist der Mechanismus, der einen erfolgreichen Token-Austausch in eine VLAN-Freigabe übersetzt. Ohne diesen Mechanismus bleiben authentifizierte Gäste blockiert.
✓Das AppSecret darf nur serverseitig gespeichert werden. Eine Offenlegung im clientseitigen Code ermöglicht die Identitätstäuschung Ihrer Anwendung und den unbefugten Zugriff auf die API von WeChat.
✓Sowohl die GDPR als auch das PIPL gelten für Daten, die über WeChat OAuth erfasst werden. Dokumentieren Sie Ihre Rechtsgrundlage, implementieren Sie Datenminimierung und stellen Sie sicher, dass Ihre Einwilligungsebene konform ist, bevor Sie live gehen.
✓Implementieren Sie bei Bereitstellungen an mehreren Standorten von Anfang an die UnionID von WeChat. OpenIDs unterscheiden sich je nach Official Account; die UnionID bietet eine konsistente Gästebild-Identität über alle verknüpften Konten hinweg.

Executive Summary

Für Unternehmen, die Standorte in der APAC-Region betreiben oder weltweit chinesische Touristen bedienen, ist die WeChat-WiFi-Authentifizierung längst keine Option mehr, sondern ein Muss. Mit 1,41 Milliarden monatlich aktiven Nutzern im Jahr 2025 (Quelle: Tencent) ist WeChat die primäre digitale Identität für chinesische Verbraucher. Ein Gast, der sich mit Ihrer SSID verbindet und nur Optionen für E-Mail- oder Facebook-Logins sieht, stößt sofort auf Barrieren. Diese Gäste haben fast sicher WeChat. Sie haben fast sicher keine lokale E-Mail-Adresse auf diesem Gerät konfiguriert.

Dieser Leitfaden beschreibt im Detail, wie Sie WeChat OAuth 2.0 in ein Captive Portal integrieren. Wir behandeln die zwei verschiedenen Plattform-Registrierungen, die Tencent verlangt, die Entscheidung über den Berechtigungsumfang (Scope), die bestimmt, welche First-Party-Daten Sie erfassen, und den RADIUS Change of Authorisation (CoA)-Mechanismus, der einen erfolgreichen OAuth-Austausch in tatsächlichen Netzwerkzugriff übersetzt. Zudem gehen wir auf die sich überschneidenden Compliance-Anforderungen der GDPR und des chinesischen Gesetzes zum Schutz persönlicher Daten (PIPL) ein.

Die Guest WiFi -Plattform von Purple automatisiert die Durchsetzungsebene im Netzwerk über Hardware von Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet hinweg. Purple ist an über 80.000 Live-Standorten im Einsatz und verzeichnete im Jahr 2024 440 Millionen Logins (interne Daten von Purple).

Technischer Deep-Dive

Der OAuth 2.0-Flow

Ein Captive Portal (ein webbasiertes Authentifizierungs-Gateway, das den HTTP-Traffic von nicht authentifizierten Geräten abfängt) leitet Gäste auf eine Login-Seite weiter, die auf einem Portal-Server gehostet wird – entweder lokal oder in der Cloud. Durch das Hinzufügen von WeChat OAuth wird die Identitätsinfrastruktur von Tencent in diesen Flow integriert.

Der Ablauf stellt sich wie folgt dar: Der Gast verbindet sich mit der SSID. Der Wireless-Controller erkennt das Fehlen einer authentifizierten Sitzung und leitet den gesamten HTTP-Traffic an die URL des Captive Portals weiter. Die Portal-Seite lädt und zeigt Login-Optionen an, einschließlich WeChat. Der Gast wählt WeChat aus. Der Portal-Server erstellt eine Weiterleitung zum Autorisierungs-Endpunkt von WeChat unter open.weixin.qq.com und übergibt dabei vier Parameter: die AppID, die Redirect-URI, den auf code gesetzten Response-Typ und den angeforderten Scope.

WeChat authentifiziert den Benutzer vollständig auf seiner eigenen Infrastruktur. Wenn der Gast bereits über den WeChat-In-App-Browser angemeldet ist, ermöglicht der snsapi_base-Scope eine stille Authentifizierung ohne sichtbare Aufforderung. WeChat leitet zurück zur registrierten Redirect-URI des Portals mit einem kurzlebigen Autorisierungscode. Der Portal-Server tauscht diesen Code gegen ein Access-Token aus, indem er api.weixin.qq.com/sns/oauth2/access_token mit der AppID, dem AppSecret, dem Code und dem Grant-Typ aufruft. WeChat gibt ein Access-Token, ein Refresh-Token, die OpenID des Benutzers und den erteilten Scope zurück. Wenn snsapi_userinfo angefordert wurde, ruft ein zweiter API-Aufruf an api.weixin.qq.com/sns/userinfo den Spitznamen, das Profilbild, das Geschlecht und die Stadt des Benutzers ab.

Plattform-Registrierung: Die Entscheidung, an der die meisten Implementierungen scheitern

Tencent betreibt zwei separate Entwicklerplattformen, und die Auswahl der falschen Plattform ist die häufigste Ursache für fehlgeschlagene Implementierungen.

Zugriffskontext	Erforderliche Registrierung	Plattform-URL	Unterstützte Scopes
WeChat-In-App-Browser	Service Account (Official Accounts Platform)	mp.weixin.qq.com	snsapi_base, snsapi_userinfo
Standard-Mobilbrowser (Chrome, Safari)	Website Application (Open Platform)	open.weixin.qq.com	snsapi_login (QR-Code-Flow)

Ein Subscription Account auf der Official Accounts Platform funktioniert nicht. Ihm fehlen die Berechtigungen für die OAuth-Webseiten-Autorisierung. Nur ein Service Account verfügt über diese Berechtigungen.

Die meisten Enterprise-Implementierungen im Bereich Hospitality und Retail setzen beide Registrierungen um. Ein Gast in einem Hotel öffnet das Portal möglicherweise in Chrome, scannt einen QR-Code mit WeChat und authentifiziert sich über den Open Platform-Flow. Oder er folgt einem Link innerhalb von WeChat selbst, landet im In-App-Browser und authentifiziert sich geräuschlos über den Official Accounts-Flow. Beide Pfade müssen unterstützt werden.

Scope-Auswahl und Datenerfassung

Der OAuth-Scope ist eine echte Architekturentscheidung, kein bloßes Konfigurationsdetail. Er bestimmt die Reibung, die der Benutzer erfährt, und die Daten, die Ihre WiFi Analytics -Plattform erhält.

snsapi_base gibt nur die OpenID zurück – eine stabile, eindeutige Kennung für diesen Benutzer innerhalb Ihres Official Accounts. Es ist keine Zustimmung des Benutzers erforderlich. Die Authentifizierung erfolgt unsichtbar. Verwenden Sie dies für wiederkehrende Gäste, deren Profile Sie bereits besitzen, oder für Umgebungen mit hohem Durchsatz wie Stadien und Verkehrsknotenpunkte, bei denen die Verbindungsgeschwindigkeit im Vordergrund steht.

snsapi_userinfo liefert die OpenID sowie Spitznamen, Profilbild, Geschlecht, Spracheinstellung und Stadt. Dies löst einen expliziten Zustimmungsbildschirm aus. Verwenden Sie dies für die Erstregistrierung von Gästen, um ein First-Party-Datenprofil zu erstellen, kombiniert mit einer PIPL-konformen und GDPR-konformen Einwilligungsebene auf der Captive Portal-Seite.

Die praktische Regel: Nutzen Sie snsapi_base für Schnelligkeit, snsapi_userinfo für Daten. Sie können beides implementieren, indem Sie prüfen, ob die OpenID des Nutzers bereits in Ihrer Datenbank existiert. Wenn ja, fordern Sie snsapi_base an. Wenn nein, fordern Sie snsapi_userinfo an.

Netzwerk-Durchsetzung: RADIUS CoA und MAC-Bypass

Ein OAuth-Token beweist die Identität. Es öffnet nicht das Netzwerk. Ein separater Mechanismus muss die erfolgreiche Authentifizierung in eine Änderung der Netzwerkrichtlinie übersetzen.

RADIUS Change of Authorisation (CoA), definiert in RFC 3576, ist der Standardansatz. Nachdem der Portal-Server ein gültiges OAuth-Token erhalten hat, sendet er eine CoA-Anfrage an den Wireless-Controller. Der Controller aktualisiert die Sitzung und verschiebt das Gerät aus dem Walled-Garden-VLAN (einem eingeschränkten Netzwerksegment, das nur Portal-Traffic zulässt) in das vollständige Gäste-VLAN. Dies funktioniert mit Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet.

MAC-Adressen-Bypass registriert die MAC-Adresse des Geräts nach erfolgreichem OAuth als autorisierten Client. Der Controller erlaubt dann den Datenverkehr von dieser Adresse ohne weitere Abfrage. Dies ist einfacher zu implementieren, birgt jedoch zwei Risiken: MAC-Adressen können gefälscht werden, und ab iOS 14 sowie Android 10 wird standardmäßig eine MAC-Adressen-Randomisierung verwendet, was den Mechanismus bei einer erneuten Verbindung unterbricht.

Für jede Bereitstellung, bei der Sicherheit eine Rolle spielt, ist RADIUS CoA die richtige Wahl. Weitere Informationen zur Absicherung von Gästenetzwerken finden Sie unter What Is Secure WiFi: Essential Guide for Business 2026 und Enterprise WiFi Security: A Complete Guide for 2026 .

Implementierungsleitfaden

Checkliste vor der Bereitstellung

Bevor Sie eine einzige Zeile Konfiguration schreiben, führen Sie diese fünf Schritte aus.

Bestimmen Sie erstens den Zugriffskontext. Analysieren Sie Ihren Standort und stellen Sie fest, ob Gäste das Portal innerhalb des WeChat-In-App-Browsers, in einem Standard-Mobilbrowser oder in beiden aufrufen. Die Antwort bestimmt Ihre Anforderungen an die Plattformregistrierung.

Registrieren Sie sich zweitens auf der richtigen Plattform. Für den Zugriff über den In-App-Browser erstellen Sie ein Service-Konto auf der WeChat Official Accounts Platform. Für den Zugriff über Standard-Browser registrieren Sie eine Website-Anwendung auf der WeChat Open Platform. Notieren Sie sich jeweils Ihre AppID und Ihr AppSecret.

Konfigurieren Sie drittens Ihre Redirect-URIs. Registrieren Sie jede Domain und Subdomain, die Ihr Portal verwendet, einschließlich Staging-Umgebungen. WeChat erzwingt eine exakte Übereinstimmungsprüfung. Eine Abweichung führt zum Fehler 40029.

Implementieren Sie viertens den serverseitigen Token-Austausch. Das AppSecret darf niemals im clientseitigen Code erscheinen. Erstellen Sie einen serverseitigen Endpunkt, der den Autorisierungscode entgegennimmt, ihn gegen ein Token austauscht und nur die Daten zurückgibt, die Ihr Portal benötigt.

Fünftens: Implementieren Sie den Parameter state für den CSRF-Schutz. Generieren Sie einen kryptografisch zufälligen Wert, speichern Sie diesen in der Sitzung des Benutzers, übergeben Sie ihn in der OAuth-Anfrage und validieren Sie ihn bei der Rückkehr.

Konfigurationsschritte für Ruckus SmartZone

Für Standorte, die Ruckus SmartZone nutzen, befindet sich die WeChat-Portal-Konfiguration unter „Services and Profiles“, dann „Hotspots and Portals“ und schließlich auf dem Reiter „WeChat“. Hier konfigurieren Sie die Authentifizierungs-URL (den WeChat-Callback-Endpunkt Ihres Portal-Servers), das DNAT-Ziel (den Server, der die Weiterleitung nicht authentifizierter Clients verarbeitet) und die Grace Period (das Zeitfenster, in dem sich ein kürzlich getrennter Benutzer ohne erneute Authentifizierung wieder verbinden kann, standardmäßig 60 Minuten). Zudem konfigurieren Sie die Walled-Garden-Whitelist, um den Datenverkehr zu den API-Endpunkten von WeChat während der Authentifizierungsphase zuzulassen. Siehe auch den Step-by-Step Guide: Configuring Ruijie Wireless Controllers for Guest WiFi Captive Portals für vergleichbare Controller-Konfigurationsmuster.

Erkennung von In-App-Browsern

Der In-App-Browser von WeChat setzt einen User-Agent-String, der MicroMessenger enthält. Ihr Portal muss diesen String erkennen und den entsprechenden OAuth-Flow bereitstellen. Wenn MicroMessenger vorhanden ist, nutzen Sie den Official Accounts Flow. Falls nicht, nutzen Sie den Open Platform QR-Code-Flow. Eine fehlerhafte Erkennung führt zu einer fehlerhaften Benutzererfahrung oder Authentifizierungsfehlern.

Best Practices

Datenminimierung und Einhaltung von dualen Richtlinien

Sowohl die GDPR (anwendbar auf europäische Besucher) als auch das PIPL (anwendbar auf chinesische Staatsbürger) erfordern eine Rechtsgrundlage für die Verarbeitung personenbezogener Daten, eine klare Zweckbindung und Datenminimierung. Der Scope snsapi_base lässt sich unter den Grundsätzen der Datenminimierung leichter rechtfertigen als snsapi_userinfo. Wenn Sie demografische Daten über snsapi_userinfo erfassen, dokumentieren Sie Ihre Rechtsgrundlage, Ihre Aufbewahrungsfrist und Ihre Datenverarbeitungsvereinbarung mit Tencent.

Das seit November 2021 geltende PIPL erfordert eine ausdrückliche Zustimmung für sensible personenbezogene Daten und schreibt vor, dass Datenverarbeiter außerhalb Chinas gleichwertige Schutzstandards implementieren. Wenn sich Ihr Portal-Server außerhalb des chinesischen Festlands befindet, müssen Sie prüfen, ob die Regeln für den grenzüberschreitenden Datentransfer auf die von Ihnen empfangenen WeChat-OpenID- und Profildaten anwendbar sind.

UnionID für Bereitstellungen an mehreren Standorten

Die OpenID ist pro Benutzer und Official Account eindeutig. Wenn Sie mehrere Official Accounts an verschiedenen Standorten betreiben, hat derselbe Gast in jedem Account eine andere OpenID. WeChat stellt eine UnionID bereit, die über alle Konten hinweg konsistent bleibt, die mit derselben Open Platform-Registrierung verknüpft sind. Für Hotelketten, Einzelhandelsgruppen oder Flughafenbetreiber, die mehrere Standorte verwalten, sollten Sie von Anfang an eine UnionID-basierte Identitätsauflösung implementieren.

Sicherheits-Härtung

Speichern Sie das AppSecret in einer Umgebungsvariablen oder einem Secrets Manager, niemals im Quellcode. Rotieren Sie es sofort, wenn Sie einen Missbrauch vermuten. Implementieren Sie ein Rate Limiting für Ihren Token-Austausch-Endpunkt, um Missbrauch zu verhindern. Protokollieren Sie alle OAuth-Fehler, insbesondere 40029 (ungültiger Code) und 40163 (Code abgelaufen), da diese entweder auf eine Fehlkonfiguration oder auf aktive Angriffsversuche hinweisen.

Für einen umfassenderen Überblick über die Sicherheitsarchitektur von Gästenetzwerken lesen Sie Why Consumer WiFi Gear Doesn't Belong on Your Guest Network .

Fallstudien

Luxushotelkette, Singapur

Ein Luxushotel mit 350 Zimmern in Singapur, das überwiegend chinesische Geschäftsreisende beherbergt, implementierte die WeChat-WiFi-Authentifizierung neben der bestehenden Option zur Anmeldung per E-Mail. Vor der Implementierung meldete das Personal an der Rezeption durchschnittlich 15 Gästebeschwerden pro Tag über Probleme beim WiFi-Login. Chinesische Gäste versuchten, E-Mail-Adressen zu verwenden, die sie auf ihren Reisegeräten nicht konfiguriert hatten.

Das Hotel registrierte ein Service-Konto auf der WeChat Official Accounts Platform und eine Website-Anwendung auf der Open Platform. Sie konfigurierten snsapi_userinfo für Erstverbindungen und snsapi_base für wiederkehrende Gäste, die anhand ihrer MAC-Adresse identifiziert wurden. Der HPE Aruba Controller wurde für RADIUS CoA konfiguriert, um die Sitzungs-Promotion zu verarbeiten.

Innerhalb von 30 Tagen sanken die Beschwerden über den WiFi-Login von Gästen auf unter zwei pro Tag. Die WiFi Analytics -Datenbank des Hotels wuchs im ersten Monat um 4.200 verifizierte First-Party-Profile, wobei demografische Daten auf Stadtebene eine zielgerichtete Kommunikation nach dem Aufenthalt ermöglichten.

Internationales Einkaufszentrum, Kuala Lumpur

Ein Premium-Einkaufszentrum in Kuala Lumpur mit 12 Millionen WeChat-Nutzern allein in Malaysia benötigte ein WiFi-Onboarding-Erlebnis, das den digitalen Erwartungen seiner Kunden entsprach. Das Einkaufszentrum betrieb Cisco Meraki Access Points auf einer Verkaufsfläche von 180.000 Quadratmetern.

Die Bereitstellung nutzte die Guest WiFi -Plattform von Purple als Cloud-Overlay, mit WeChat OAuth als primärer Authentifizierungsmethode und SMS OTP als Fallback. Die hardwareunabhängige Architektur von Purple übernahm die RADIUS CoA-Integration mit Cisco Meraki, ohne dass eine kundenspezifische Entwicklung erforderlich war.

Das Einkaufszentrum verzeichnete im ersten Quartal nach der Bereitstellung einen Anstieg der WiFi-Sitzungsstarts um 34 %, was auf die geringeren Hürden beim Onboarding für WeChat-Nutzer zurückzuführen ist. Die über snsapi_userinfo-Einwilligungs-Flows gesammelten First-Party-Daten ermöglichten es dem Marketingteam des Einkaufszentrums, Käufer nach ihrer Heimatstadt zu segmentieren, um zielgerichtete Kampagnen bereitzustellen.

Fehlerbehebung und Risikominderung

Fehler	Ursache	Lösung
40029 invalid code	Redirect-URI-Fehlpassung oder Code-Wiederverwendung	Überprüfen Sie, ob die registrierten URIs exakt übereinstimmen; Codes sind nur zur einmaligen Verwendung bestimmt
40163 code expired	Token-Austausch um mehr als 5 Minuten verzögert	Verarbeitungszeit auf Server-Seite reduzieren; Retry-Logik implementieren
Leerer Bildschirm nach Authentifizierung	RADIUS CoA nicht konfiguriert oder fehlerhaft	CoA-Einstellungen des Controllers und Firewall-Regeln auf UDP-Port 3799 prüfen
MAC-Randomisierung unterbricht den Flow für wiederkehrende Gäste	iOS/Android MAC-Randomisierung	Zu OpenID-basiertem Session-Tracking migrieren; reine MAC-Identifikation vermeiden
snsapi_userinfo gibt leere Felder zurück	Benutzer hat WeChat-Datenschutzeinstellungen aktiviert	Null-Felder elegant verarbeiten; Profildaten nicht als Voraussetzung für den Zugang verlangen

ROI und geschäftliche Auswirkungen

Der Business Case für die WeChat WiFi-Authentifizierung basiert auf drei messbaren Ergebnissen.

Erfassung von First-Party-Daten. Jede snsapi_userinfo-Authentifizierung generiert ein verifiziertes Gästeprofil mit demografischen Daten. Für ein Hotel mit 200 Zimmern bei einer Auslastung von 70 % und 40 % chinesischen Gästen entspricht dies etwa 20.000 neuen verifizierten Profilen pro Jahr, die jeweils mit einer WeChat-Identität verknüpft sind, die eine kontinuierliche Wiederansprache unterstützt.

Reduzierter Support-Aufwand. Reibungsverluste beim Login sind der Hauptgrund für Support-Anrufe von Gästen zum WiFi. Standorte, die die WeChat-Authentifizierung zusätzlich zu den bestehenden Optionen anbieten, berichten konsistent von einer Reduzierung der WiFi-bezogenen Anfragen an der Rezeption, wodurch Personalzeit für wertvollere Interaktionen frei wird.

Marketing-Reichweite. WeChat Official Accounts ermöglichen es Standorten, Push-Benachrichtigungen an Follower zu senden. Ein Gast, der sich über Ihren Official Account authentifiziert, kann dazu aufgefordert werden, diesem zu folgen. Dadurch entsteht ein direkter Kommunikationskanal innerhalb des WeChat-Ökosystems, in dem chinesische Verbraucher durchschnittlich 82 Minuten pro Tag verbringen (Quelle: Walk the Chat).

Der Engage-Tarif von Purple geht noch einen Schritt weiter und ermöglicht automatisierte Nachrichten nach dem Besuch, Loyalty-Trigger und segmentierte Kampagnen auf Basis der First-Party-Daten, die zum Zeitpunkt der WiFi-Authentifizierung erfasst wurden.

Schlüsseldefinitionen

Captive Portal

Ein webbasiertes Authentifizierungs-Gateway, das den HTTP-Verkehr von einem nicht authentifizierten Gerät abfängt und auf eine Anmeldeseite umleitet, bevor der Netzwerkzugriff gewährt wird.

Der Mechanismus, über den die Gäste-WiFi-Authentifizierung für Benutzer bereitgestellt wird. WeChat OAuth ist eine von mehreren Authentifizierungsmethoden, die ein Captive Portal anbieten kann.

OAuth 2.0

Ein branchenübliches Autorisierungsprotokoll, das es einer Drittanbieter-Anwendung (dem Captive Portal) ermöglicht, im Namen eines Benutzers eingeschränkten Zugriff auf einen Webdienst (WeChat) zu erhalten, ohne dass der Benutzer sein Passwort an den Drittanbieter weitergeben muss.

Das zugrunde liegende Framework, das die WeChat-Anmeldung ermöglicht. Das Portal sieht die WeChat-Anmeldedaten des Benutzers zu keinem Zeitpunkt; es erhält lediglich ein Token, das bestätigt, dass WeChat den Benutzer authentifiziert hat.

RADIUS CoA

Change of Authorisation. Ein in RFC 3576 definierter Mechanismus, der es einem RADIUS-Server ermöglicht, die Sitzungsautorisierungsattribute eines aktiven Netzwerk-Clients dynamisch zu ändern, wie beispielsweise die VLAN-Zuweisung.

Der Netzwerk-Erzwingungsmechanismus, der einen erfolgreichen WeChat OAuth-Austausch in tatsächlichen Netzwerkzugriff übersetzt. Ohne CoA authentifiziert sich der Gast zwar, aber der Controller weiß nicht, dass er das Netzwerk öffnen muss.

OpenID

Eine eindeutige Kennung, die von WeChat einem bestimmten Benutzer für ein bestimmtes offizielles Konto oder eine Website-Anwendung zugewiesen wird. Sie bleibt über Sitzungen hinweg stabil, unterscheidet sich jedoch von Konto zu Konto.

Der Primärschlüssel zur Identifizierung eines Gastes in Ihrer WiFi-Analysedatenbank. Verwenden Sie stattdessen die UnionID, wenn Sie mehrere offizielle Konten betreiben und eine kontoübergreifende Identitätsauflösung benötigen.

snsapi_base

Ein WeChat OAuth-Bereich (Scope), der eine stille Authentifizierung ermöglicht und nur die OpenID des Benutzers zurückgibt, ohne eine Einverständniserklärung anzuzeigen.

Für wiederkehrende Gäste oder Umgebungen mit hohem Durchsatz, in denen die Verbindungsgeschwindigkeit Priorität hat. Gibt außer der OpenID keine demografischen Daten zurück.

snsapi_userinfo

Ein WeChat OAuth-Bereich (Scope), der die OpenID, den Spitznamen, das Profilbild, das Geschlecht, die Sprache und die Stadt des Benutzers zurückgibt und einen expliziten Zustimmungsbildschirm des Benutzers erfordert.

Für die Erstregistrierung von Gästen zur Erstellung eines First-Party-Datenprofils. Muss mit einer GDPR- und PIPL-konformen Einwilligungsebene kombiniert werden.

PIPL

Personal Information Protection Law. Chinas umfassende Datenschutzgesetzgebung, die seit November 2021 in Kraft ist und regelt, wie personenbezogene Daten chinesischer Bürger erhoben, verarbeitet und übertragen werden dürfen.

Gilt für jeden Standort, der Daten von chinesischen Bürgern über WeChat OAuth sammelt, unabhängig vom Standort des Veranstaltungsortes. Erfordert eine ausdrückliche Zustimmung, Zweckbindung und Datenminimierung.

AppSecret

Ein vertraulicher kryptografischer Schlüssel, der von WeChat ausgestellt wird und Ihre Anwendung authentifiziert, wenn sie die Token-Exchange-API von WeChat aufruft.

Darf nur serverseitig gespeichert werden. Eine Offenlegung im clientseitigen Code ermöglicht es Dritten, sich als Ihre Anwendung auszugeben und unbefugte API-Aufrufe an WeChat zu senden.

VLAN

Virtual Local Area Network. Ein logisches Netzwerksegment, das den Datenverkehr auf der Sicherungsschicht isoliert, sodass ein einziges physisches Netzwerk mehrere isolierte Datenströme übertragen kann.

Wird in Captive Portal-Bereitstellungen verwendet, um nicht authentifizierte Geräte (Walled-Garden-VLAN) von authentifizierten Gästen (Gäste-VLAN) zu trennen. RADIUS CoA verschiebt ein Gerät nach erfolgreicher Authentifizierung zwischen den VLANs.

UnionID

Eine WeChat-Kennung, die für einen bestimmten Benutzer über alle offiziellen Konten und Website-Anwendungen hinweg konsistent bleibt, die mit derselben Registrierung auf der Open Platform verknüpft sind.

Unerlässlich für Hotelketten, Einzelhandelsgruppen und Betreiber mehrerer Standorte, die denselben Gast über mehrere Objekte hinweg wiedererkennen müssen, von denen jedes ein eigenes offizielles Konto hat.

Ausgearbeitete Beispiele

Ein Luxushotel mit 200 Zimmern in Singapur nutzt HPE Aruba Controller und bedient ein hohes Aufkommen an chinesischen Geschäftsreisenden. Sie möchten demografische Daten von Erstbesuchern erfassen und sicherstellen, dass sich wiederkehrende Gäste automatisch verbinden, ohne das Captive Portal erneut zu sehen. Wie sollten sie die WeChat OAuth-Integration konfigurieren?

Schritt 1: Registrieren Sie ein Service-Konto auf der WeChat Official Accounts Platform (mp.weixin.qq.com), um Gäste zu bedienen, die über den WeChat In-App-Browser auf das Captive Portal zugreifen. Registrieren Sie eine Website-Anwendung auf der WeChat Open Platform (open.weixin.qq.com) für Gäste, die Standard-Mobilbrowser nutzen.

Schritt 2: Konfigurieren Sie das Captive Portal so, dass es den MicroMessenger-User-Agent-String erkennt. Stellen Sie den Official Accounts OAuth-Flow für In-App-Browser-Nutzer und den Open Platform QR-Code-Flow für Standard-Browser-Nutzer bereit.

Schritt 3: Fordern Sie bei Erstverbindungen (keine vorhandene OpenID in der Datenbank) den Scope "snsapi_userinfo" an. Zeigen Sie vor dem OAuth-Redirect einen PIPL-konformen Einwilligungsbildschirm an. Speichern Sie die zurückgegebene OpenID, den Spitznamen, die Stadt und das Geschlecht in der Gästeprofildatenbank.

Schritt 4: Fordern Sie für wiederkehrende Gäste (OpenID ist in der Datenbank vorhanden) den Scope "snsapi_base" an. Dies authentifiziert geräuschlos ohne für den Nutzer sichtbare Aufforderung.

Schritt 5: Konfigurieren Sie den HPE Aruba Controller für RADIUS CoA auf UDP-Port 3799. Nach erfolgreichem OAuth sendet der Portal-Server eine CoA-Anfrage, um das Gerät aus dem Walled-Garden-VLAN in das Gäste-VLAN zu verschieben.

Schritt 6: Implementieren Sie eine MAC-Adressen-Protokollierung zusammen mit der OpenID, um die Erkennung wiederkehrender Gäste zu steuern. Beachten Sie, dass die MAC-Randomisierung die OpenID als primäre Kennung erfordert, nicht die MAC-Adresse allein.

Kommentar des Prüfers: Dieser Ansatz trennt die beiden Plattformregistrierungen korrekt nach Zugriffskontext, nutzt die Scope-Auswahl, um die Balance zwischen Nutzerhürden und Datenerfassung zu wahren, und implementiert RADIUS CoA für eine sichere Netzwerkdurchsetzung. Die Verwendung der OpenID als primäre Kennung für wiederkehrende Gäste ist die richtige Reaktion auf die MAC-Randomisierung. Die PIPL-Einwilligungsebene ist für Daten chinesischer Staatsbürger nicht verhandelbar.

Das IT-Team einer Einzelhandelskette meldet eine hohe Ausfallrate bei WeChat WiFi-Logins an drei Einkaufszentrums-Standorten. Nutzer authentifizieren sich in WeChat, werden aber mit einer Fehlermeldung zum Captive Portal zurückgeleitet. Die Portal-Protokolle zeigen den Fehler 40029. Was ist die wahrscheinliche Ursache und wie lösen Sie diese?

Fehler 40029 bedeutet, dass WeChat den Autorisierungscode während des Token-Austauschs abgelehnt hat. Die beiden häufigsten Ursachen sind eine Diskrepanz bei der Redirect-URI und die Wiederverwendung von Codes.

Schritt 1: Melden Sie sich in der WeChat-Entwicklerkonsole sowohl für die Official Accounts Platform als auch für die Open Platform an. Navigieren Sie zu den OAuth-Einstellungen und listen Sie alle registrierten Redirect-URIs auf.

Schritt 2: Vergleichen Sie diese mit den tatsächlichen Redirect-URIs, die Ihr Portal-Server in der Produktionsumgebung an allen drei Standorten verwendet. Prüfen Sie auf Subdomain-Unterschiede (portal.brand.com vs. brand.com), Protokoll-Unterschiede (HTTP vs. HTTPS) und Pfad-Unterschiede (/callback vs. /wechat/callback).

Schritt 3: Registrieren Sie jede Variante in der WeChat-Konsole. WeChat führt eine exakte Übereinstimmungsprüfung durch, keinen Präfix-Abgleich.

Schritt 4: Wenn die URIs übereinstimmen, prüfen Sie, ob Ihr Portal-Server versucht, Autorisierungscodes wiederzuverwenden. WeChat-Codes sind nur einmalig verwendbar und laufen nach fünf Minuten ab. Wenn Ihr Server den Token-Austausch mit demselben Code erneut versucht, erhält er beim zweiten Versuch den Fehler 40029.

Schritt 5: Implementieren Sie Idempotenz im Token-Austausch-Endpunkt, um doppelte Anfragen zu verhindern.

Kommentar des Prüfers: Fehler 40029 ist der häufigste Fehler bei WeChat OAuth-Bereitstellungen und wird fast immer durch eine Diskrepanz bei der Redirect-URI verursacht. Bereitstellungen an mehreren Standorten sind besonders anfällig, da jeder Standort eine andere Subdomain oder Load-Balancer-Adresse verwenden kann. Die sekundäre Ursache, die Wiederverwendung von Codes, ist seltener, sollte aber überprüft werden, wenn die URI-Registrierung nachweislich korrekt ist.

Übungsfragen

Q1. Sie stellen ein Captive Portal für ein Stadion mit einer Kapazität von 60.000 Zuschauern bereit, in dem internationale Veranstaltungen mit einer großen chinesischen Fangemeinde stattfinden. Die Priorität liegt darin, alle Besucher innerhalb der ersten 15 Minuten nach Öffnung der Tore online zu bringen, um die Überlastung des Mobilfunknetzes zu reduzieren. Die Erfassung von Marketingdaten ist ein sekundäres Ziel. Welchen WeChat OAuth-Scope sollten Sie konfigurieren und warum?

Hinweis: Bedenken Sie die Auswirkungen eines Zustimmungsbildschirms, der 15.000 gleichzeitigen Benutzern auf einem Portal-Server angezeigt wird.

Musterlösung anzeigen

Konfigurieren Sie den Scope snsapi_base. Dies ermöglicht eine stille Authentifizierung ohne Aufforderung zur Benutzerzustimmung und bietet so das schnellstmögliche Onboarding-Erlebnis. Bei einer Stadion-Größenordnung führt ein Zustimmungsbildschirm zu Reibungsverlusten, die sich über Tausende von gleichzeitigen Verbindungen multiplizieren und zu Lastspitzen auf dem Portal-Server führen können. snsapi_base gibt nur die OpenID zurück, was ausreicht, um die Sitzung zu protokollieren und wiederkehrende Fans zu identifizieren. Für Erstbesucher, von denen Sie demografische Daten wünschen, können Sie die Profilvervollständigung über eine Umfrage nach der Verbindung abfragen, anstatt direkt an der Authentifizierungsschranke.

Q2. Ein Netzwerkarchitekt in Ihrem Team schlägt vor, das WeChat AppSecret im clientseitigen JavaScript des Captive Portals zu speichern, um Server-Roundtrips zu reduzieren, indem der Token-Austausch direkt vom Browser aus aufgerufen wird. Erklären Sie, warum dieser Ansatz ein kritischer Sicherheitsfehler ist und wie die korrekte Architektur aussieht.

Hinweis: Bedenken Sie, wer den clientseitigen Code einsehen kann und was das AppSecret diesen Personen ermöglicht.

Musterlösung anzeigen

Die Speicherung des AppSecret im clientseitigen JavaScript legt es für jeden offen, der den Quellcode der Seite anzeigt oder den Netzwerkverkehr abfängt. Das AppSecret authentifiziert Ihre Anwendung gegenüber der WeChat-API. Damit kann ein böswilliger Akteur Ihre Anwendung imitieren, den Token-Austausch-Endpunkt von WeChat mit jedem gültigen Autorisierungscode aufrufen, OpenIDs und Profildaten von Benutzern abrufen und potenziell Ihre API-Rate-Limits ausschöpfen. Die korrekte Architektur ist ein serverseitiger Token-Austausch-Endpunkt. Der Browser empfängt den Autorisierungscode von WeChat und leitet ihn an Ihren Server weiter. Ihr Server tauscht den Code unter Verwendung des in einer Umgebungsvariablen oder einem Secrets Manager gespeicherten AppSecret gegen ein Token aus und gibt nur die Daten zurück, die das Portal benötigt. Das AppSecret verlässt niemals Ihren Server.

Q3. Ihr Standort betreibt drei Hotelanlagen in verschiedenen Städten, von denen jede über ein eigenes WeChat Official Account verfügt. Ein Mitglied Ihres Treueprogramms, das sich an allen drei Standorten authentifiziert hat, besitzt drei verschiedene OpenIDs in Ihrer Datenbank. Wie führen Sie diese zu einer einzigen Gastidentität zusammen?

Hinweis: WeChat bietet einen Mechanismus zur kontoübergreifenden Identitätsauflösung, der eine spezifische Plattformkonfiguration erfordert.

Musterlösung anzeigen

Implementieren Sie den UnionID-Mechanismus von WeChat. Verknüpfen Sie alle drei Official Accounts mit derselben Open Platform-Registrierung unter open.weixin.qq.com. Sobald sie verknüpft sind, gibt WeChat in der snsapi_userinfo-Antwort eine UnionID neben der OpenID zurück. Die UnionID ist für einen bestimmten Benutzer über alle Konten hinweg, die mit derselben Open Platform-Registrierung verknüpft sind, konsistent. Migrieren Sie Ihre Datenbank so, dass die UnionID als primäre Gastkennung für standortübergreifende Datensätze verwendet wird, während die kontospezifische OpenID für kontospezifische API-Aufrufe beibehalten wird. Für Gäste, die sich vor der Implementierung der UnionID authentifiziert haben, lösen Sie bei ihrem nächsten Besuch eine erneute Authentifizierung mit snsapi_userinfo aus, um die UnionID zu erfassen.

Q4. Nach der Bereitstellung der WeChat WiFi-Authentifizierung an einem Einzelhandelsstandort mit Cisco Meraki Access Points melden Gäste, dass sie die WeChat-Anmeldung erfolgreich abschließen, aber zur Portalseite zurückgeleitet werden und nicht im Internet surfen können. Die Protokolle des Portal-Servers zeigen einen erfolgreichen Token-Abruf. Was ist die wahrscheinlichste Ursache und wie diagnostizieren Sie diese?

Hinweis: Das Portal hat die Identität verifiziert. Was ist noch nicht geschehen?

Musterlösung anzeigen

Die RADIUS Change of Authorisation (CoA) wird nicht abgeschlossen. Der Portal-Server hat die Identität des Gasts über WeChat OAuth verifiziert, aber den Cisco Meraki Controller nicht erfolgreich angewiesen, das Gerät aus dem Walled-Garden-VLAN in das Gast-VLAN zu verschieben. Diagnostizieren Sie dies, indem Sie Folgendes überprüfen: (1) ob auf dem Meraki Controller RADIUS CoA aktiviert ist und die IP des Portal-Servers als autorisierter CoA-Client aufgeführt ist; (2) ob der UDP-Port 3799 zwischen dem Portal-Server und dem Controller geöffnet ist; (3) die Protokolle des Portal-Servers auf CoA-Anforderungsfehler oder -Timeouts; und (4) ob das auf beiden Seiten konfigurierte Shared Secret übereinstimmt. Wenn CoA in Ihrer Meraki-Lizenzstufe nicht unterstützt wird, ist der MAC-Address-Bypass die Ausweichlösung, obwohl dies das im Leitfaden erwähnte Risiko der MAC-Randomisierung birgt.

Weiterlesen in dieser Reihe

Einrichtung eines Captive Portals auf Starlink: Ein Leitfaden für abgelegene und maritime Standorte

Dieser Leitfaden beschreibt detailliert, wie Sie die native Starlink-Hardware umgehen und ein Cloud-gesteuertes Captive Portal mithilfe von Enterprise-Routing-Geräten integrieren. Sie erfahren, wie Sie die CGNAT-Einschränkung überwinden, eine VLAN-Segmentierung erzwingen, Bandbreitenbeschränkungen von Satelliten verwalten und die Einhaltung gesetzlicher Vorschriften sicherstellen.

Captive Portal Best Practices: Design für hohe Conversion und Compliance

Dieser technische Leitfaden bietet IT-Managern, Netzwerkarchitekten und Leitern des Standortbetriebs ein vollständiges Konzept für die Bereitstellung von Captive Portalen, die Netzwerksicherheit mit hoher User Conversion verbinden. Er deckt die gesamte Architektur ab, von der VLAN-Segmentierung und RADIUS-Authentifizierung bis hin zur GDPR-konformen Einwilligungserklärung und der Auswahl der Authentifizierungsmethode. Basierend auf den betrieblichen Erfahrungen von Purple in über 80.000 Standorten und 440 Millionen Logins im Jahr 2024 ist jede Empfehlung durch reale Bereitstellungsdaten untermauert.

How to Optimize Captive Portals for Maximum Network Security and User Conversion

Dieser Leitfaden bietet eine vollständige technische Blaupause für die Optimierung von Captive Portals in Unternehmensstandorten und deckt Netzwerksegmentierungsarchitektur, die Auswahl von Authentifizierungsmethoden, GDPR-konformes Einwilligungsdesign und die Conversion-Optimierung ab. Er richtet sich an IT-Manager, Netzwerkarchitekten und CTOs in Hotels, Einzelhandelsketten, Stadien und Organisationen des öffentlichen Sektors, die Netzwerksicherheit mit der Erfassung von First-Party-Daten in Einklang bringen müssen. Purple betreibt eine Captive Portal-Infrastruktur an über 80.000 Standorten mit 440 Millionen Logins im Jahr 2024, und die hier vorgestellten Frameworks spiegeln diese betriebliche Erfahrung wider.