Integration der WeChat WiFi Authentifizierung: Captive Portal Onboarding für APAC Kunden

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 Enterprise Captive Portals für Standorte in der APAC Region integrieren. Er behandelt die Plattformregistrierung, die Auswahl des Scopes, die Durchsetzung von RADIUS Change of Authorisation und die duale Compliance mit der GDPR und der chinesischen PIPL. Er richtet sich an IT Leiter, Netzwerkarchitekten und Standortleiter, die in diesem Quartal handeln müssen.

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

Video overview

Diesen Leitfaden anhören

Podcast-Transkript ansehen

WIE SIE DIE WECHAT OAUTH-AUTHENTIFIZIERUNG FÜR CAPTIVE PORTALS KONFIGURIEREN
Ein technisches Briefing von Purple - ca. 10 Minuten

EINFÜHRUNG UND KONTEXT (ca. 1 Minute)

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 weiter.

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 fast sicher WeChat. Die Frage ist also nicht, ob Sie den WeChat-Login anbieten sollten. Die Frage ist, wie Sie ihn korrekt, sicher und so konfigurieren, dass First-Party-Daten entstehen, die Sie auch tatsächlich nutzen können.

Genau das werden wir heute behandeln. 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 und die Compliance-Überlegungen, die im Jahr 2026 von Bedeutung sind.

TECHNISCHE TIEFENANALYSE (ca. 5 Minuten)

Beginnen wir mit der Architektur. Ein Captive Portal fängt den HTTP-Verkehr 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 von Identitäten in diesen Ablauf ein.

Hier ist die Abfolge. 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-Verkehr an Ihre Captive Portal-URL weiter. Die Portalseite wird geladen und zeigt die Anmeldeoptionen an, einschließlich WeChat. Der Gast tippt auf den WeChat-Login. Ihr Portalserver leitet den Browser zum Autorisierungs-Endpunkt 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 dies mit dem Scope „snsapi_base“ im Hintergrund geschehen - also ganz ohne 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 erteilten Scope zurück. Wenn Sie den Scope „snsapi_userinfo“ angefordert haben, können Sie einen zweiten API-Aufruf starten, um den Spitznamen, das Profilbild, das Geschlecht und die Stadt des Nutzers abzurufen.

Nun zu den beiden Plattform-Registrierungen. Hier schleichen sich bei den meisten Implementierungen Fehler ein.

WeChat verfügt über 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 Account auf der Official Accounts Platform. Ein Subscription Account funktioniert nicht. Dieses verfügt nicht über Berechtigungen zur OAuth-Webseiten-Autorisierung. Ein Service Account bietet diese und unterstützt sowohl den snsapi base- als auch den snsapi userinfo-Bereich.

Für ein Captive Portal, auf das über einen standardmäßigen mobilen Browser außerhalb von WeChat zugegriffen wird, wie Chrome auf Android oder Safari auf iOS, benötigen Sie eine auf der Open Platform registrierte Website-Anwendung. Diese nutzt den snsapi login-Bereich und zeigt einen QR-Code an, den der Nutzer mit seiner WeChat-App scannt.

In der Praxis nutzen die meisten Standort-Installationen beides. Ein Gast in einem Hotel öffnet das Portal beispielsweise 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 im Hintergrund über snsapi base.

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

Der snsapi base-Bereich gibt nur die OpenID zurück. Dies ist eine eindeutige Kennung für diesen Nutzer innerhalb Ihres Official Account. Es ist keine Zustimmung des Nutzers erforderlich. Die Authentifizierung erfolgt für den Nutzer unsichtbar. Dies ist ideal für wiederkehrende Gäste, von denen Sie bereits ein Profil haben, oder für Standorte, an denen Sie absolute Reibungslosigkeit auf Kosten neuer Daten bevorzugen.

Der snsapi userinfo-Bereich gibt die OpenID sowie den WeChat-Spitznamen, das Profilbild, das Geschlecht, die Spracheinstellung und die Stadt des Nutzers zurück. Dies erfordert einen expliziten Zustimmungsbildschirm. Der Nutzer sieht eine Aufforderung mit der Frage, ob er Ihrem Official Account den Zugriff auf seine Daten gestattet. Die meisten Nutzer stimmen zu, aber es entsteht eine Hürde.

Die richtige Wahl hängt von Ihrem Anwendungsfall ab. Für die Erstregistrierung eines Gastes, bei der Sie ein Profil erstellen möchten, nutzen 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, nutzen Sie snsapi base für eine geräuschlose erneute Authentifizierung.

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

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

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

Die Guest WiFi Plattform von Purple unterstützt beide Mechanismen. Nach Abschluss von 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 häufigsten Ursachen, warum WeChat OAuth Captive Portal Implementierungen scheitern.

Erstens: Keine Übereinstimmung 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, scheitert der OAuth-Flow mit dem Fehler 40029, was einen ungültigen Code bedeutet. Registrieren Sie jede von Ihnen verwendete Domain-Variante, einschließlich Staging-Umgebungen.

Zweitens: Das AppSecret auf der Clientseite. Ihr AppSecret darf niemals in clientseitigem 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 Vermeidung 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 fehlende Erkennung des In-App-Browsers. Der In-App-Browser von WeChat setzt einen spezifischen User-Agent-String, der MicroMessenger enthält. Wenn Ihr Portal dies nicht erkennt und den richtigen OAuth-Flow bereitstellt, erhalten Benutzer eine fehlerhafte Darstellung oder eine Fehlermeldung.

Fünftens: DSGVO- und PIPL-Konformität. 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 (PIPL) für die Verarbeitung ihrer Daten. Beide erfordern eine Rechtsgrundlage für die Verarbeitung, eine klare Zweckbindung und Datenminimierung. Der snsapi-Basisbereich ist unter den Grundsätzen der Datenminimierung einfacher 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 nutzen, das auch E-Mail- und SMS-Login anbietet?
Ja. Die meisten Portal-Plattformen für Unternehmen, 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 unter iOS funktioniert über den QR-Code-Flow oder den Redirect-Flow. Die WeChat-App selbst übernimmt die Authentifizierung.
Frage: Was passiert, wenn die WeChat API nicht verfügbar ist?
Ihr Portal sollte ein Fallback implementieren. Wenn der WeChat API-Aufruf ein Timeout überschreitet 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 bei diesen unterschiedliche OpenIDs. Für die accountübergreifende Identitätsauflösung bietet WeChat eine UnionID, was voraussetzt, dass Ihre Accounts auf der Open Platform verknüpft sind.

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

Zusammenfassend lässt sich sagen: Die WeChat OAuth-Authentifizierung für Captive Portale 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 angehen, verfügen Sie über eine Anmeldemethode, die über eine Milliarde potenzieller Besucher ohne Passwort-Hürden bedient.

Die praktischen nächsten Schritte sind folgende. Erstens: Stellen Sie fest, ob Ihre Besucher das Portal im WeChat In-App-Browser oder in einem Standard-Mobilbrowser aufrufen. Das bestimmt, welche Plattformregistrierung Sie benötigen. Zweitens: Entscheiden Sie sich für den Scope. Verwenden Sie "snsapi base" für wiederkehrende Gäste und "snsapi userinfo" für die Erstregistrierung mit Einwilligung. Drittens: Bestätigen Sie, dass Ihre Netzwerkhardware RADIUS CoA unterstützt, oder konfigurieren Sie alternativ einen MAC-Bypass. Viertens: Überprüfen Sie Ihre Datenschutzerklärung und Ihren Einwilligungsflow im Hinblick auf die Anforderungen der GDPR und PIPL. Fünftens: Testen Sie die 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 in 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 Konsumenten. Standorte, die Gäste aus der Region APAC bedienen, können es sich nicht leisten, diese Option bei der Anmeldung im 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-Anwendung auf der Open Platform für den Zugriff über Standardbrowser. Die Verwendung des falschen Registrierungstyps ist der häufigste Implementierungsfehler.
✓Die Auswahl des Scopes ist eine grundlegende Architekturentscheidung. Verwenden Sie snsapi_base für eine lautlose, reibungslose Authentifizierung, die nur eine OpenID zurückgibt. Verwenden Sie snsapi_userinfo, um demografische Daten zu erfassen, und akzeptieren Sie dafür die Hürde eines Einwilligungsbildschirms.
✓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 Prozess 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ästebildidentität über alle verknüpften Konten hinweg.

📚 Teil unserer Kernserie: Captive Portal Leitfaden →

Integration der WeChat WiFi Authentifizierung: Captive Portal Onboarding für APAC Kunden

Executive Summary

Für Enterprise-Standorte in der APAC-Region oder solche, die weltweit chinesische Touristen bedienen, ist die WeChat WiFi-Authentifizierung unverzichtbar geworden. 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 Anmeldeoptionen über E-Mail oder Facebook sieht, stößt sofort auf Hürden. Diese Gäste nutzen mit an Sicherheit grenzender Wahrscheinlichkeit WeChat - und haben fast sicher keine lokale E-Mail-Adresse auf ihrem Gerät konfiguriert.

Dieser Leitfaden beschreibt detailliert, 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 Scope, der bestimmt, welche First-Party-Daten Sie erfassen, und den RADIUS Change of Authorisation (CoA) Mechanismus, der einen erfolgreichen OAuth-Austausch in den tatsächlichen Netzwerkzugriff übersetzt. Zudem gehen wir auf die sich überschneidenden Compliance-Anforderungen der GDPR und des chinesischen Gesetzes zum Schutz persönlicher Informationen (PIPL) ein.

Die Guest WiFi Plattform von Purple automatisiert die Durchsetzungsebene im Netzwerk auf Hardware von Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet. Purple wird an über 80.000 Live-Standorten betrieben 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 Anmeldeseite weiter, die auf einem Portal-Server gehostet wird - entweder lokal oder in der Cloud. Die Integration von WeChat OAuth bindet die Identity-Infrastruktur von Tencent in diesen Flow ein.

Der Ablauf ist wie folgt: 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 Portal weiter. Die Portal-Seite lädt und zeigt die Anmeldeoptionen an, einschließlich WeChat. Der Gast wählt WeChat aus. Der Portal-Server erstellt eine Weiterleitung an den Autorisierungs-Endpunkt von WeChat unter open.weixin.qq.com und übergibt dabei vier Parameter: die AppID, den Redirect-URI, den auf code gesetzten Response-Typ und den angeforderten Scope.

WeChat authentifiziert den Benutzer vollständig auf der 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 an den 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-Type 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.

Integration der WeChat WiFi Authentifizierung: Captive Portal Onboarding für APAC Kunden - architecture overview

Plattforregistrierung: die Entscheidung, an der die meisten Implementierungen scheitern

Tencent betreibt zwei separate Entwicklerplattformen. 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-Konto (Official Accounts Platform)	mp.weixin.qq.com	snsapi_base, snsapi_userinfo
Standard-Mobilbrowser (Chrome, Safari)	Website-Anwendung (Open Platform)	open.weixin.qq.com	snsapi_login (QR-Code-Ablauf)

Ein Abonnement-Konto (Subscription Account) auf der Official Accounts Platform funktioniert nicht. Ihm fehlen die OAuth-Webseiten-Autorisierungsberechtigungen. Nur ein Service-Konto verfügt über diese Berechtigungen.

Die meisten Enterprise-Implementierungen im Gastgewerbe und Einzelhandel nutzen beide Registrierungen. Ein Gast im Hotel öffnet das Portal beispielsweise in Chrome, scannt einen QR-Code mit WeChat und authentifiziert sich über den Open Platform-Ablauf. Oder er folgt einem Link direkt in WeChat, landet im In-App-Browser und authentifiziert sich stillschweigend über den Official Accounts-Ablauf. Beide Pfade müssen unterstützt werden.

Scope-Auswahl und Datenerfassung

Der OAuth-Scope ist eine echte Architekturentscheidung und 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 Einwilligungserklärung des Benutzers erforderlich. Die Authentifizierung ist 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, in denen die Verbindungsgeschwindigkeit Priorität hat.

snsapi_userinfo gibt die OpenID sowie Spitznamen, Profilbild, Geschlecht, Spracheinstellung und Stadt zurück. Dies löst einen expliziten Zustimmungsbildschirm aus. Verwenden Sie dies bei der ersten Registrierung von Gästen, um ein First-Party-Datenprofil zu erstellen, kombiniert mit einer PIPL- und GDPR-konformen Einwilligungsebene auf der Portalseite.

Die praktische Regel: Nutzen Sie snsapi_base für Schnelligkeit und snsapi_userinfo für Daten. Sie können beide implementieren, indem Sie prüfen, ob die OpenID des Benutzers bereits in Ihrer Datenbank existiert. Wenn ja, fordern Sie snsapi_base an. Wenn nicht, 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 empfangen 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 (ein eingeschränktes 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 address bypass registriert die MAC-Adresse des Geräts nach erfolgreichem OAuth als autorisierten Client. Der Controller lässt dann Datenverkehr von dieser Adresse ohne weitere Abfrage zu. Dies ist einfacher zu implementieren, birgt jedoch zwei Risiken: MAC-Adressen können manipuliert werden, und iOS 14 sowie Android 10 und neuer verwenden standardmäßig eine MAC-Adressen-Randomisierung, 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 .

Implementierungshandbuch

Checkliste vor der Bereitstellung

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

Bestimmen Sie erstens den Zugriffskontext. Untersuchen 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 werden. 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 Ihre AppID und Ihr AppSecret für jede Plattform.

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 ihn in der Session des Benutzers, übergeben Sie ihn im OAuth-Request und validieren Sie ihn bei der Rückkehr.

Konfigurationsschritte für Ruckus SmartZone

Für Standorte, die mit Ruckus SmartZone betrieben werden, befindet sich die Konfiguration des WeChat-Portals unter „Services and Profiles“, dann „Hotspots and Portals“ und schließlich auf der Registerkarte „WeChat“. Sie konfigurieren die Authentifizierungs-URL (den WeChat-Callback-Endpunkt Ihres Portalservers), 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 während der Authentifizierungsphase den Datenverkehr zu den WeChat-API-Endpunkten zuzulassen. Siehe auch den Schritt-für-Schritt-Leitfaden: Konfiguration von Ruijie Wireless Controllern für Guest WiFi Captive Portals für vergleichbare Controller-Konfigurationsmuster.

In-App-Browser-Erkennung

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, verwenden Sie den Official Accounts Flow. Wenn er fehlt, verwenden Sie den QR-Code-Flow der Open Platform. Eine fehlerhafte Erkennung führt zu einer mangelhaften Benutzererfahrung oder zu Authentifizierungsfehlern.

Best Practices

Datenminimierung und duale Framework-Compliance

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 ist unter den Grundsätzen der Datenminimierung leichter zu 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 verlangt eine ausdrückliche Einwilligung für sensible personenbezogene Daten und schreibt vor, dass Datenverarbeiter außerhalb Chinas gleichwertige Schutzstandards implementieren. Wenn sich Ihr Portalserver außerhalb des chinesischen Festlands befindet, müssen Sie prüfen, ob Regeln für den grenzüberschreitenden Datentransfer auf die von Ihnen empfangenen WeChat OpenID- und Profildaten anwendbar sind.

UnionID für standortübergreifende Implementierungen

Die OpenID ist pro Benutzer und Official Account eindeutig. Wenn Sie mehrere Official Accounts über verschiedene Standorte hinweg 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 auf UnionID basierende Identitätsauflösung implementieren.

Sicherheits-Hardening

Speichern Sie das AppSecret in einer Umgebungsvariable oder einem Secrets Manager, niemals im Quellcode. Rotieren Sie es sofort, wenn Sie einen Missbrauch vermuten. Implementieren Sie ein Rate-Limiting an Ihrem 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 aktive Angriffsversuche hinweisen.

Für einen breiteren Überblick über die Sicherheitsarchitektur von Gästenetzwerken lesen Sie Warum Consumer-WiFi-Geräte nicht in Ihr Gästenetzwerk gehören .

Fallstudien

Luxushotelkette, Singapur

Ein Luxushotel mit 350 Zimmern in Singapur, das hauptsächlich chinesische Geschäftsreisende bedient, führte eine WeChat WiFi-Authentifizierung parallel zu ihrer bestehenden E-Mail-Anmeldeoption ein. Vor der Einführung meldete das Rezeptionspersonal durchschnittlich 15 Gästebeschwerden pro Tag über Probleme bei der WiFi-Anmeldung. 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 über die MAC-Adresse identifiziert wurden. Der HPE Aruba Controller wurde für RADIUS CoA konfiguriert, um die Sitzungsaktivierung zu steuern.

Innerhalb von 30 Tagen sanken die Beschwerden über die WiFi-Anmeldung für Gäste 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 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 Ausweichoption. 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 Einführung 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-Einwilligungsprozesse gesammelten First-Party-Daten ermöglichten es dem Marketingteam des Einkaufszentrums, die Käufer nach ihrer Heimatstadt zu segmentieren, um gezielte Kampagnen auszusteuern.

Integration der WeChat WiFi Authentifizierung: Captive Portal Onboarding für APAC Kunden - retail venue wechat wifi

Fehlerbehebung und Risikominderung

Fehler	Ursache	Lösung
40029 ungültiger Code	Abweichende Redirect-URI oder Code-Wiederverwendung	Überprüfen Sie, ob die registrierten URIs exakt übereinstimmen; Codes können nur einmal verwendet werden
Leerer Bildschirm nach Authentifizierung	RADIUS CoA nicht konfiguriert oder fehlerhaft	Überprüfen Sie die CoA-Einstellungen des Controllers und die Firewall-Regeln für UDP-Port 3799
MAC-Randomisierung stört den Ablauf für wiederkehrende Gäste	iOS/Android MAC-Randomisierung	Migrieren Sie auf OpenID-basiertes Sitzungs-Tracking; vermeiden Sie eine reine Identifizierung über die MAC-Adresse
snsapi_userinfo gibt leere Felder zurück	Benutzer hat WeChat-Datenschutzeinstellungen eingeschränkt	Behandeln Sie Null-Werte fehlerfrei; fordern Sie keine Profil-Daten für den Netzzugang an

ROI und geschäftlicher Nutzen

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 70 % Auslastung und 40 % chinesischen Gästen bedeutet dies rund 20.000 neue, verifizierte Profile pro Jahr - jedes davon verknüpft mit einer WeChat Identität, die eine kontinuierliche Wiederansprache ermöglicht.

Entlastung des Supports. Probleme beim Login sind der Hauptgrund für Support-Anfragen zum Gäste-WiFi. Standorte, die die WeChat Authentifizierung als zusätzliche Option anbieten, berichten konsistent von weniger WiFi-bezogenen Anfragen an der Rezeption. Das entlastet das Personal für wertvollere Kundenkontakte.

Marketing-Reichweite. Über offizielle WeChat Konten (Official Accounts) können Standorte Push-Benachrichtigungen an Follower senden. Ein Gast, der sich über Ihr offizielles Konto 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 Plan von Purple geht noch einen Schritt weiter: Er ermöglicht automatisierte Nachrichten nach dem Besuch, Loyalty-Trigger und segmentierte Kampagnen auf Basis der First-Party-Daten, die direkt bei der WiFi Authentifizierung erfasst wurden.

Schlüsseldefinitionen

Captive Portal

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

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

OAuth 2.0

Ein Autorisierungsprotokoll nach Branchenstandard, das es einer Drittanbieter-Anwendung (dem Captive Portal) ermöglicht, im Namen eines Nutzers eingeschränkten Zugriff auf einen Webdienst (WeChat) zu erhalten, ohne dass der Nutzer sein Passwort an den Drittanbieter weitergibt.

Das zugrundeliegende Framework, das die Anmeldung über WeChat ermöglicht. Das Portal sieht die WeChat-Anmeldedaten des Nutzers zu keinem Zeitpunkt; es erhält lediglich ein Token, das bestätigt, dass WeChat den Nutzer authentifiziert hat.

RADIUS CoA

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

Der Mechanismus zur Durchsetzung von Netzwerkrichtlinien, der einen erfolgreichen WeChat OAuth-Austausch in echten Netzwerkzugriff umwandelt. Ohne CoA authentifiziert sich der Gast, aber der Controller weiß nicht, dass er das Netzwerk freigeben muss.

OpenID

Eine eindeutige Kennung, die von WeChat einem bestimmten Nutzer für ein bestimmtes offizielles Konto oder eine Website-Anwendung zugewiesen wird. Sie ist sitzungsübergreifend stabil, unterscheidet sich jedoch von Konto zu Konto.

Der primäre Schlü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, der eine stille Authentifizierung ermöglicht und nur die OpenID des Nutzers zurückgibt, ohne eine Einverständniserklärung anzuzeigen.

Zur Verwendung für wiederkehrende Gäste oder in Umgebungen mit hohem Durchsatz, in denen die Verbindungsgeschwindigkeit im Vordergrund steht. Gibt außer der OpenID keine demografischen Daten zurück.

snsapi_userinfo

Ein WeChat OAuth-Bereich, der die OpenID des Nutzers, den Spitznamen, das Profilbild, das Geschlecht, die Sprache und die Stadt zurückgibt und eine explizite Einwilligung des Nutzers erfordert.

Zur Verwendung bei der Erstregistrierung von Gästen, um ein First-Party-Datenprofil zu erstellen. Muss mit einer DSGVO- und PIPL-konformen Einwilligungsebene kombiniert werden.

PIPL

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

Gilt für jeden Standort, der Daten von chinesischen Bürgern über WeChat OAuth erfasst, unabhängig davon, wo sich der Standort befindet. 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-Austausch-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 tätigen.

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 Nutzer ü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 erkennen müssen, von denen jedes über ein eigenes offizielles Konto verfügt.

Ausgearbeitete Beispiele

Ein Luxushotel mit 200 Zimmern in Singapur nutzt HPE Aruba Controller und bedient eine große Anzahl chinesischer Geschäftsreisender. Sie möchten demografische Daten von Erstbesuchern erfassen und sicherstellen, dass sich wiederkehrende Gäste automatisch verbinden, ohne das 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) für Gäste, die über den In-App-Browser von WeChat auf das Portal zugreifen. Registrieren Sie eine Website-Anwendung auf der WeChat Open Platform (open.weixin.qq.com) für Gäste mit Standard-Mobilbrowsern.

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 Nutzer von In-App-Browsern und den Open Platform QR-Code-Flow für Nutzer von Standard-Browseren bereit.

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

Schritt 4: Fordern Sie für wiederkehrende Gäste (OpenID ist in der Datenbank vorhanden) den Scope snsapi_base an. Dies authentifiziert den Nutzer geräuschlos ohne 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 die Protokollierung von MAC-Adressen 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 und nicht die MAC-Adresse allein.

Kommentar des Prüfers: Dieser Ansatz trennt die beiden Plattformregistrierungen korrekt nach dem Zugriffskontext, nutzt die Scope-Auswahl, um die Reibung mit der Datenerfassung abzuwägen, 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 Fehlerrate bei WeChat WiFi Logins an drei Einkaufszentrums-Standorten. Benutzer authentifizieren sich in WeChat, werden aber mit einem Fehler zur Portalseite zurückgeleitet. Die Portal-Protokolle zeigen den Fehler 40029. Was ist die wahrscheinliche Ursache und wie lösen Sie das Problem?

Der 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 Produktion an allen drei Standorten verwendet. Suchen Sie nach Unterschieden bei Subdomains (portal.brand.com vs. brand.com), Protokollen (HTTP vs. HTTPS) und Pfaden (/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 können nur einmal verwendet werden 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 Endpunkt für den Token-Austausch, um doppelte Anfragen zu verhindern.

Kommentar des Prüfers: Der Fehler 40029 ist der am häufigsten auftretende Fehler bei WeChat OAuth-Bereitstellungen und wird fast immer durch eine Diskrepanz der Redirect-URI verursacht. Bereitstellungen an mehreren Standorten sind dafür besonders anfällig, da jeder Standort eine andere Subdomain oder Load-Balancer-Adresse verwenden kann. Die sekundäre Ursache, die Code-Wiederverwendung, kommt seltener vor, sollte aber überprüft werden, sobald die korrekte URI-Registrierung bestätigt 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 Einlass online zu bringen, um die Mobilfunküberlastung zu verringern. Die Erfassung von Marketingdaten ist ein sekundäres Ziel. Welchen WeChat-OAuth-Scope sollten Sie konfigurieren und warum?

Hinweis: Berücksichtigen Sie die Auswirkungen eines Zustimmungsbildschirms, der 15.000 gleichzeitigen Nutzern auf einem Portal-Server angezeigt wird.

Musterlösung anzeigen

Konfigurieren Sie den Scope snsapi_base. Dies ermöglicht eine stille Authentifizierung ohne Aufforderung zur Benutzereinwilligung und sorgt so für ein schnellstmögliches Onboarding-Erlebnis. Bei der Größenordnung eines Stadions 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 am Authentifizierungs-Gate.

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

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

Musterlösung anzeigen

Das Speichern des AppSecret im clientseitigen JavaScript legt es für jeden offen, der den Quellcode der Seite ansieht 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-Ratenbegrenzungen 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, jede mit einem eigenen WeChat Official Account. Ein Mitglied des Treueprogramms, das sich an allen drei Standorten authentifiziert hat, verfügt über 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 bestimmte 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. Nach der Verknüpfung gibt WeChat in der snsapi_userinfo-Antwort neben der OpenID auch eine UnionID zurück. Die UnionID ist für einen bestimmten Benutzer über alle Konten hinweg, die mit derselben Open Platform-Registrierung verknüpft sind, einheitlich. Migrieren Sie Ihre Datenbank so, dass UnionID als primärer Gastidentifikator für standortübergreifende Datensätze verwendet wird, und behalten Sie die kontospezifische OpenID für kontospezifische API-Aufrufe bei. 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 Portalserver hat die Identität des Gastes über WeChat OAuth verifiziert, aber den Cisco Meraki Controller nicht erfolgreich angewiesen, das Gerät aus dem Walled-Garden-VLAN in das Gäste-VLAN zu verschieben. Diagnose durch Überprüfung von: (1) ob auf dem Meraki Controller RADIUS CoA aktiviert ist und die IP des Portalservers als autorisierter CoA-Client aufgeführt ist; (2) ob der UDP-Port 3799 zwischen dem Portalserver und dem Controller geöffnet ist; (3) den Portalserver-Protokollen 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-Adressen-Bypass die Alternative, obwohl dieser das in der Anleitung beschriebene Risiko der MAC-Randomisierung birgt.

Weiterlesen in dieser Reihe

Captive Portal für Ruijie: Einrichtung mit Purple Gäste-WiFi

Wie das Cloud-Gäste-WiFi von Purple über Web-Authentifizierung und RADIUS auf Ruijie RG Series Access Points aufsetzt, konfiguriert über die Befehlszeile, und wo Sie die genauen Einrichtungsschritte finden.

B2B Captive Portals gestalten: Erfassung von registrierten Namen und Unternehmensdaten

Dieser Leitfaden bietet IT-Managern und Betreibern von Veranstaltungsorten ein herstellerneutrales technisches Framework für das Design von B2B Captive Portals. Er beschreibt im Detail, wie Registrierungsfelder strukturiert werden sollten, um registrierte Namen und Unternehmensdaten zu erfassen, um hohe Ausfüllraten zu gewährleisten, während gleichzeitig die GDPR-Konformität gewahrt und Account-Level-Intelligence aufgebaut wird.

Captive Portal Architektur: Sicherheit, Umleitung und Best Practices

Ein definitives technisches Referenzdokument zur Captive Portal-Architektur in Unternehmen. Dieser Leitfaden beleuchtet Netzwerkisolierung, DNS-Umleitung, RADIUS-Authentifizierung und Sicherheitskonformität für IT-Entscheider, die sichere, datenreiche Gäste-WiFi-Netzwerke bereitstellen.