Integration der WeChat-Authentifizierung in Captive Portals für Gäste-WiFi
Dieser Leitfaden erklärt, wie Sie die WeChat OAuth 2.0-Authentifizierung in Captive Portals für Enterprise-Gäste-WiFi integrieren. Er behandelt die Registrierungsanforderungen auf beiden Plattformen, die Scope-Auswahl für die Erfassung von First-Party-Daten, die Netzwerkdurchsetzung über RADIUS Change of Authorization sowie die Einhaltung der GDPR und des chinesischen PIPL. Betreiber von Standorten in den Bereichen Hotellerie, Einzelhandel und Events finden hier konkrete Implementierungsschritte, Praxisbeispiele und Sicherheitsrichtlinien für die skalierbare Bereitstellung von WeChat-Logins im Gäste-WiFi.
Diesen Leitfaden anhören
Podcast-Transkript ansehen
Zusammenfassung
Wenn ein chinesischer Besucher sich mit Ihrem Unternehmensnetzwerk verbindet und auf ein Captive Portal stößt, das nur E-Mail, Facebook oder Anmeldecodes anbietet, entsteht sofortige Reibung. Laut den Daten von Tencent aus dem Jahr 2024 hat WeChat 1,38 Milliarden monatlich aktive Nutzer. Die Integration des WeChat-Logins in das Gäste-WiFi ist kein zusätzlicher Service für das Gastgewerbe; es ist eine technische Voraussetzung, um First-Party-Daten dieser Zielgruppe reibungslos zu erfassen.
Dieser Leitfaden beschreibt die technische Architektur der Integration von WeChat OAuth 2.0-Authentifizierung in Captive Portals. Er erklärt die für die Unterstützung von Standard-Mobilbrowsern und dem WeChat-In-App-Browser erforderliche Dual-Plattform-Registrierung, bewertet die Kompromisse zwischen den Scopes snsapi_base und snsapi_userinfo für die Datenerfassung und beschreibt, wie der Netzwerkzugriff mittels RADIUS Change of Authorization (CoA) oder MAC Authentication Bypass erzwungen wird. Er deckt auch die Sicherheitskonfigurationen und Compliance-Richtlinien - GDPR und Chinas Personal Information Protection Law (PIPL) - ab, die für großflächige Implementierungen in Infrastrukturen von Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet erforderlich sind.
Technischer Deep Dive: WeChat OAuth 2.0-Architektur
Ein Captive Portal fängt den HTTP-Verkehr von nicht authentifizierten Geräten ab und leitet sie auf eine Landingpage um, die auf einem Portalserver gehostet wird. Die Integration der WeChat-Authentifizierung fügt einen Drittanbieter-Identitätsanbieter über das OAuth 2.0-Protokoll in diesen Ablauf ein - denselben Standard, den auch Google, Microsoft Entra ID und Okta für föderierte Identitäten nutzen.
Der Authentifizierungsablauf funktioniert wie folgt: Ein Besucher verbindet sich mit der SSID. Der Access Point oder Wireless Controller erkennt die unauthentifizierte Sitzung und leitet den HTTP-Verkehr zur Captive Portal-URL weiter. Der Besucher wählt auf der Portal-Seite die WeChat-Anmeldung. Der Portal-Server leitet den Browser zum WeChat-Autorisierungsendpunkt unter open.weixin.qq.com weiter und übergibt die AppID, den Redirect-URI, den Antworttyp code sowie den angeforderten Scope. WeChat verarbeitet die Authentifizierung auf den eigenen Servern. Wenn sich der Besucher im integrierten WeChat-Browser befindet und den snsapi_base-Scope verwendet, erfolgt die Authentifizierung geräuschlos - es erscheint keine Abfrage der Einwilligung zur Autorisierung. Wenn snsapi_userinfo verwendet wird, zeigt WeChat eine Autorisierungs-Einwilligungsseite an. WeChat leitet dann mit einem temporären Autorisierungscode zurück zur Redirect-URI des Portals. Der Portal-Server tauscht diesen Code gegen ein Access Token aus, indem er einen API-Aufruf an api.weixin.qq.com/sns/oauth2/access_token mit der AppID, dem AppSecret, dem Code und dem Grant-Typ authorization_code durchführt. WeChat gibt das Access Token, das Refresh Token, die OpenID des Benutzers und den erteilten Scope zurück. Wenn snsapi_userinfo erteilt wurde, initiiert der Server einen zweiten API-Aufruf, um den Nicknamen, das Profilbild, das Geschlecht und die Stadt des Benutzers abzurufen.
Anforderungen für die Registrierung auf Dual-Plattformen
Die meisten Implementierungen scheitern in der Registrierungsphase. WeChat betreibt zwei separate Entwicklerplattformen, und Bereitstellungen in Unternehmen erfordern in der Regel beide.
| Plattform | URL | Erforderlicher Kontotyp | Unterstützte Scopes | Browser-Umgebung |
|---|---|---|---|---|
| Official Accounts Platform | mp.weixin.qq.com | Service-Konto | snsapi_base, snsapi_userinfo | WeChat-In-App-Browser |
| Open Platform | open.weixin.qq.com | Web-Anwendung | snsapi_login | Standard-Mobile-Browser |
Für Besucher, die das Portal über den integrierten WeChat-Browser aufrufen, benötigen Sie ein Service-Konto auf der Official Accounts Platform. Abonnement-Konten funktionieren nicht - ihnen fehlen die Berechtigungen zur OAuth-Webseiten-Autorisierung. Für Besucher, die das Portal über Chrome unter Android oder Safari unter iOS aufrufen, benötigen Sie eine Web-Anwendung auf der Open Platform, die den snsapi_login-Scope verwendet und dem Benutzer einen QR-Code zum Scannen anzeigt.
In der Praxis nutzen die meisten Standorte beide Optionen. Ein Hotelgast öffnet das Portal eventuell in Chrome, sieht einen QR-Code, scannt diesen mit WeChat und authentifiziert sich. Oder er tippt direkt in WeChat auf einen Link, wechselt in den In-App-Browser und authentifiziert sich geräuschlos über snsapi_base.
Scope-Auswahl: Datenerfassung vs. Benutzerreibung
Der von Ihnen angeforderte Scope bestimmt die Daten, die Sie erfassen, und die Hürden, auf die der Besucher stößt. Dies ist eine praktische Entscheidung mit Auswirkungen auf die Compliance.
snsapi_base gibt nur die OpenID zurück - die eindeutige Kennung für diesen Benutzer innerhalb Ihres Official Accounts. Es ist keine Einwilligung des Benutzers erforderlich. Die Authentifizierung erfolgt für den Besucher geräuschlos. Ideal für wiederkehrende Besucher, deren Profile Sie bereits haben, oder wenn Sie eine reibungslose Anmeldung bevorzugen. Nach den Grundsätzen der Datenminimierung der GDPR und PIPL ist snsapi_base viel einfacher zu rechtfertigen.
snsapi_userinfo gibt die OpenID sowie den Spitznamen, das Profilbild, das Geschlecht und den Wohnort des Benutzers zurück. Dies erfordert eine explizite Genehmigungsseite. Ideal für die Registrierung von Erstbesuchern, bei der Sie ein Profil erstellen müssen, kombiniert mit einem datenschutzkonformen Einverständnis-Overlay auf Ihrer Portal-Seite.
UnionID für Multi-Site-Bereitstellungen
Eine OpenID ist für die Kombination aus einem Benutzer und einem bestimmten Official Account eindeutig. Eine Hotelgruppe mit 20 Standorten, von denen jeder seinen eigenen Official Account betreibt, würde 20 verschiedene OpenIDs für denselben Besucher sehen. Die UnionID löst dieses Problem. Es handelt sich um eine einzige Kennung, die einen Benutzer über alle Official Accounts und Anwendungen hinweg darstellt, die mit demselben Open Platform-Konto verknüpft sind. Verknüpfen Sie Ihre Official Accounts mit Ihrem Open Platform-Konto, und die UnionID wird in der OAuth-Antwort zurückgegeben. Dies ist die Grundlage für die standortübergreifende Besuchererkennung.
Implementierungshandbuch
Netzwerk-Durchsetzungsmechanismen
Der Erhalt eines OAuth-Tokens beweist nur die Identität; er öffnet das Netzwerk nicht. Sie müssen dem Controller signalisieren, dass er den Datenverkehr zulässt.
RADIUS Change of Authorization (CoA) (definiert in RFC 3576) ist die empfohlene Methode für Unternehmen. Nach erfolgreicher OAuth-Validierung sendet der Portal-Server eine CoA-Anfrage an den Netzwerk-Controller. Der Controller verschiebt das Gerät aus dem Pre-Authentication-VLAN in das Gäste-VLAN. Dies gilt für Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet.
MAC Authentication Bypass (MAB) registriert die MAC-Adresse des Geräts als autorisierten Client in der RADIUS-Datenbank. Der Controller erlaubt den Zugriff basierend auf dieser MAC. MAB ist einfacher zu implementieren, aber weniger zuverlässig: Moderne iOS und Android-Geräte verwenden standardmäßig zufällige MAC-Adressen, was die Sitzungszuordnung bei einer erneuten Verbindung unterbricht.
Die Guest WiFi -Plattform von Purple automatisiert diesen Übergang. Sobald das WeChat-OAuth abgeschlossen ist, sendet das Cloud-Overlay-Netzwerk von Purple das entsprechende CoA- oder MAB-Signal an die zugrunde liegende Hardware, wodurch die manuelle VLAN-Konfiguration entfällt.
Sicherheitskonfiguration
Die folgenden drei Konfigurationen sind unverzichtbar.
- Schützen Sie das AppSecret. Das
AppSecretdarf niemals im clientseitigen JavaScript erscheinen. Es muss auf Ihrem Server verbleiben. Bei einer Kompromittierung können Angreifer Ihre Anwendung imitieren und die WeChat-API in Ihrem Namen aufrufen. - CSRF-Schutz implementieren. Generieren Sie einen kryptografisch zufälligen
state-Wert, speichern Sie ihn in der Benutzersitzung und validieren Sie ihn, wenn die WeChat-Weiterleitung zurückgegeben wird. Dies verhindert Cross-Site-Request-Forgery-Angriffe, wie in RFC 6749 definiert. - Registrieren Sie alle Redirect-URI-Varianten. WeChat validiert die Redirect-URI mit Ihrer registrierten Domain. Registrieren Sie jede Subdomain- und Pfad-Variante, die Sie verwenden (einschließlich Staging-Umgebungen), um 40029-Fehler (ungültiger Code) zu vermeiden.
In-App-Browser-Erkennung
Der In-App-Browser von WeChat setzt einen User-Agent-String, der MicroMessenger enthält. Ihr Captive Portal muss diesen String erkennen und entsprechend weiterleiten: Der In-App-Browser nutzt den Official Account Flow, während Standard-Browser den Open Platform QR-Code-Flow verwenden. Wenn dieser String nicht erkannt wird, führt dies zu einer fehlerhaften Benutzererfahrung oder Authentifizierungsfehlern.
Best Practices und Compliance
GDPR-Compliance
Wenn Sie europäische Besucher bedienen oder in Europa tätig sind, gilt die GDPR für die Daten, die Sie über WeChat OAuth erfassen. Sie müssen eine konforme Verarbeitungsgrundlage schaffen - in der Regel eine Einwilligung oder ein berechtigtes Interesse. Bevor die Authentifizierung stattfindet, müssen Sie einen klaren Datenschutzhinweis auf dem Captive Portal bereitstellen. Sie müssen auf Auskunfts- und Löschanfragen reagieren. Ein detailliertes Compliance-Framework finden Sie im Compliance Playbook: GDPR und Guest WiFi Datenschutz .
PIPL-Compliance
Wenn Sie personenbezogene Daten von chinesischen Staatsbürgern verarbeiten, gilt das chinesische Gesetz zum Schutz persönlicher Informationen (PIPL). Ähnlich wie die GDPR erfordert das PIPL eine explizite Zweckbindung, Datenminimierung und eine schriftliche Rechtsgrundlage. Unter dem Prinzip der Datenminimierung ist snsapi_base wesentlich einfacher zu rechtfertigen als snsapi_userinfo. Dokumentieren Sie unabhängig von den erfassten Daten Ihre Rechtsgrundlage und Aufbewahrungsfristen vor dem Go-Live.
Netzwerktrennung
Verwenden Sie eine VLAN-Segmentierung, um den Gast-WiFi-Traffic von Ihrem Unternehmensnetzwerk zu isolieren. Gäste, die über WeChat authentifiziert wurden, sollten in ein dediziertes Gast-VLAN mit alleinigem Internetzugang verschoben werden - ohne Zugriff auf interne Systeme. Dies entspricht den PCI-DSS-Anforderungen zur Isolierung von Karteninhaberdaten-Umgebungen und allgemeinen Sicherheitsrichtlinien im Unternehmen. Weitere Informationen zur Isolationsarchitektur finden Sie unter Bandbreitenmanagement: Ein praktischer Leitfaden für 2026 .
Fallback-Authentifizierung
Falls die WeChat-API nicht verfügbar ist, muss Ihr Portal auf eine alternative Login-Methode umleiten. Lassen Sie Gäste nicht vor einem leeren Bildschirm stehen. Die Bereitstellung von E-Mail- oder SMS-Fallbacks sichert die Kontinuität. Dies ist besonders in Umgebungen für Transport und Healthcare von entscheidender Bedeutung, in denen die Netzwerkkonnektivität eine Dienstleistungsverpflichtung darstellt.
Praxisnahe Fallstudien
Hotellerie: Luxushotelgruppe
Ein Luxushotel mit 400 Zimmern in London beherbergte eine beträchtliche Anzahl von Gästen aus Festlandchina. Das ursprüngliche Captive Portal erforderte eine E-Mail-Adresse und eine Verifizierung per SMS. Chinesische Mobilfunknummern konnten jedoch häufig keine SMS-Nachrichten von europäischen Anbietern empfangen, und viele Gäste hatten keine nativen E-Mail-Konten auf ihren Geräten eingerichtet. Dies führte zu Abbruchraten im Portal von bis zu 60 %.
Das Hotel registrierte ein Service-Konto auf der Plattform für offizielle Konten und eine Website-Anwendung auf der offenen Plattform. Das Portal erkannte den User-Agent MicroMessenger und löste snsapi_base für Nutzer von In-App-Browsern aus - was sie in weniger als drei Sekunden und ohne Autorisierungsaufforderung verband. Gästen, die Chrome oder Safari nutzten, wurde ein QR-Code angezeigt. Bei nachfolgenden Besuchen erkannte das System dieselbe OpenID und authentifizierte den Gast im Hintergrund, ohne nach Anmeldedaten zu fragen. Das CRM des Hotels protokollierte die Rückkehr des Gasts, was eine gezielte Kommunikation vor der Ankunft ermöglichte. Weitere Informationen zur Bereitstellung von WiFi im Gastgewerbe finden Sie unter Hospitality .
Einzelhandel: Analysen für Einkaufszentren
Ein großes Einkaufszentrum wollte demografische Erkenntnisse von chinesischen Verbrauchern gewinnen, um den Mietermix und die Marketingstrategien anzupassen. Sie mussten Heimatstadt, Geschlecht und Besuchshäufigkeit verstehen. Hier war snsapi_base unzureichend - sie benötigten snsapi_userinfo. Das Portal forderte den vollständigen userinfo-Bereich an. Die Gäste sahen die WeChat-Autorisierungsaufforderung und klickten auf Zulassen. Die Analyseplattform des Einkaufszentrums, die mit Purple's WiFi Analytics integriert ist, erhielt einen Stream von verifizierten demografischen Daten. An Samstagnachmittagen stammten 40 % der WiFi-Nutzer aus einer bestimmten Region. Diese Daten beeinflussten direkt, welche Marken für Pop-up-Aktionen angesprochen wurden. Weitere Informationen zu WiFi-Bereitstellungen im Einzelhandel finden Sie unter Retail .
Fehlerbehebung und Risikominderung
Die fünf häufigsten Fehlerszenarien bei WeChat OAuth Captive Portal-Bereitstellungen sind:
Abweichung des Redirect URI (Fehler 40029). WeChat validiert den Redirect URI mit der registrierten Domain. Jede Abweichung bei Subdomain, Pfad oder Protokoll führt dazu, dass der Code-Austausch fehlschlägt. Registrieren Sie alle Varianten, einschließlich Staging-Umgebungen.
Offenlegung des AppSecret. Die Einbettung des AppSecret in clientseitigen Code ist der kritischste Sicherheitsfehler. Bitte verlegen Sie die gesamte Logik für den Token-Austausch auf die Serverseite.
Fehlender CSRF-Schutz. Das Ignorieren der Validierung des state-Parameters macht das Portal anfällig für Cross-Site Request Forgery-Angriffe. Generieren Sie einen kryptografischen Zufallswert pro Sitzung und validieren Sie diesen beim Callback.
Fehlgeschlagene Erkennung des In-App-Browsers. Wenn MicroMessenger im User-Agent nicht erkannt wird, wird Nutzern von In-App-Browsern der falsche OAuth-Flow angezeigt, was zu Fehlern führt.
Die Randomisierung von MAC-Adressen unterbricht MAB-Sitzungen. Moderne mobile Betriebssysteme randomisieren MAC-Adressen. Gäste, die auf eine MAB-Erzwingung angewiesen sind, verlieren ihre Sitzung bei der erneuten Verbindung. Aktualisieren Sie auf RADIUS CoA für ein zuverlässiges Sitzungsmanagement. Eine Anleitung zur sicheren WiFi-Konfiguration finden Sie unter What is Secure WiFi: The 2026 Enterprise Essential Guide .
-
ROI und geschäftliche Auswirkungen
Die Bereitstellung des WeChat-Logins für das Gäste-WiFi bietet drei messbare Vorteile.
Verbesserte Authentifizierungsraten. Durch den Wegfall von Fehlerquellen bei der SMS-Verifizierung und von Anforderungen zur E-Mail-Eingabe erhöht sich der Anteil chinesischer Besucher, die sich erfolgreich verbinden. Bei Captive Portals ohne WeChat-Unterstützung ist eine Abbruchquote von 60 % eine realistische Ausgangsbasis.
Qualität von First-Party-Daten. Über WeChat verifizierte Profile enthalten eine validierte OpenID und über snsapi_userinfo direkten Zugriff auf demografische Attribute der Social-Media-Plattform. Diese Daten können in Analyseplattformen eingespeist werden, um zielgerichtetes Marketing ohne die Verwendung von Drittanbieter-Cookies zu betreiben.
Reduzierter Support-Aufwand. Ein nahtloser Login reduziert das Aufkommen an Anrufen beim Empfang und beim IT-Support-Personal zur Behebung von Verbindungsproblemen bei internationalen Besuchern.
Purple ist in über 80.000 Standorten im Einsatz und hat im Jahr 2024 440 Millionen Logins verarbeitet (interne Daten von Purple). Die Plattform ist ISO 27001 zertifiziert, GDPR- und CCPA-konform und weist eine Betriebszeit von 99,999 % auf. Für Standorte in den Bereichen Retail und Hospitality verwandelt die WeChat-Authentifizierung das Netzwerk von einem Kostenfaktor in einen robusten Kanal zur Erfassung von First-Party-Daten.
Schlüsseldefinitionen
Captive Portal
Eine Webseite, die den HTTP-Datenverkehr von einem nicht authentifizierten Gerät abfängt und eine Interaktion des Benutzers erfordert, bevor der Netzwerkzugriff gewährt wird.
Die primäre Benutzeroberfläche, auf der dem Gast die WeChat-Anmeldeoption angezeigt wird. Der Portalserver hostet diese Seite und steuert den OAuth-Flow.
OAuth 2.0
Ein Autorisierungsprotokoll nach Industriestandard (RFC 6749), das es einer Drittanbieteranwendung ermöglicht, im Namen eines Benutzers eingeschränkten Zugriff auf einen HTTP-Dienst zu erhalten.
Das zugrunde liegende Protokoll, das WeChat verwendet, um Authentifizierungs-Token an den Portal-Server zu übergeben, ohne Benutzeranmeldedaten preiszugeben. Dasselbe Protokoll, das auch von Microsoft Entra ID, Okta und Google Workspace verwendet wird.
OpenID
Eine eindeutige alphanumerische Kennung, die einem bestimmten WeChat-Benutzer für einen bestimmten Official Account zugewiesen wird.
Wird als Primärschlüssel zur Identifizierung wiederkehrender Gäste in der WiFi-Analysedatenbank verwendet. Ändert sich je nach Official Account - verwenden Sie UnionID für eine standortübergreifende Erkennung.
UnionID
Eine einzige WeChat-Kennung, die einen Benutzer über alle Official Accounts und Apps hinweg darstellt, die mit demselben Open Platform-Konto verknüpft sind.
Unerlässlich für Hotelgruppen, Einzelhandelsketten und Stadionbetreiber mit mehreren Veranstaltungsorten, die denselben Gast über ihr gesamtes Portfolio hinweg wiedererkennen müssen.
RADIUS CoA (Change of Authorization)
Eine Erweiterung des RADIUS-Protokolls (RFC 3576), die es einem RADIUS-Server ermöglicht, die Autorisierungsattribute einer aktiven Sitzung dynamisch zu ändern.
Die sichere Methode, mit der ein Gästegerät nach erfolgreicher WeChat-Anmeldung von einem isolierten Pre-Authentication-VLAN in das aktive Internet-VLAN verschoben wird. Unterstützt von Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet.
snsapi_base
Ein WeChat-OAuth-Scope, der nur die OpenID des Benutzers zurückgibt und keine Zustimmung des Benutzers erfordert.
Der empfohlene Scope für die erneute Authentifizierung wiederkehrender Gäste. Im Rahmen der Grundsätze der Datenminimierung unter GDPR und PIPL einfacher zu rechtfertigen.
snsapi_userinfo
Ein WeChat-OAuth-Scope, der die OpenID, den Spitznamen, das Profilbild, das Geschlecht und die Stadt des Benutzers zurückgibt und einen expliziten Zustimmungsbildschirm erfordert.
Wird für die Erstregistrierung von Gästen verwendet, wenn demografische Daten für Analysen benötigt werden. Erfordert eine dokumentierte Rechtsgrundlage gemäß GDPR und PIPL.
PIPL (Personal Information Protection Law)
Chinas umfassende Datenschutzgesetzgebung, die im November 2021 in Kraft getreten ist und die Verarbeitung personenbezogener Daten natürlicher Personen mit Wohnsitz in China regelt.
Gilt, wenn Veranstaltungsorte Daten von chinesischen Bürgern über WeChat OAuth verarbeiten. Erfordert eine klare Einwilligung, Zweckbindung, Datenminimierung und einen Löschmechanismus.
AppSecret
Ein vertraulicher kryptografischer Schlüssel, der von WeChat bei der Registrierung der Anwendung ausgestellt wird und zur Autorisierung von API-Aufrufen vom Portal-Server verwendet wird.
Darf ausschließlich serverseitig gespeichert werden. Eine Offenlegung in clientseitigem JavaScript ermöglicht es Angreifern, sich als Anwendung auszugeben und WeChat-APIs böswillig aufzurufen.
Ausgearbeitete Beispiele
Ein Luxushotel mit 400 Zimmern in London verzeichnet eine Absprungrate von 60 % auf dem Portal bei Gästen aus Festlandchina. Das aktuelle Portal erfordert eine Verifizierung per E-Mail und SMS. Der IT-Leiter muss eine WeChat-Authentifizierung implementieren und gleichzeitig die GDPR-Konformität und die Netzwerksicherheit gewährleisten.
Schritt 1: Registrieren Sie ein Service-Konto auf der WeChat Official Accounts Platform (mp.weixin.qq.com) und eine Website-Anwendung auf der WeChat Open Platform (open.weixin.qq.com). Schritt 2: Konfigurieren Sie das Portal so, dass es den MicroMessenger-User-Agent-String erkennt. Wenn dieser erkannt wird, lösen Sie den OAuth-Flow "snsapi_base" für eine geräuschlose Authentifizierung aus. Wenn er nicht erkannt wird, zeigen Sie den QR-Code-Flow an. Schritt 3: Fügen Sie der Portalseite einen GDPR-konformen Datenschutzhinweis und ein Zustimmungs-Kontrollkästchen hinzu, bevor die WeChat-Login-Schaltfläche aktiv wird. Der Hinweis muss Folgendes angeben: erfasste Daten (nur OpenID), Zweck (Zugang zum Gäste-WiFi und Wiedererkennung bei wiederholten Besuchen) und Aufbewahrungsfrist. Schritt 4: Nach erfolgreichem OAuth-Token-Austausch sendet der Portalserver eine RADIUS CoA-Anfrage an den Cisco Meraki Controller, um das Gästegerät aus dem Pre-Auth-VLAN in das segmentierte Gäste-VLAN zu verschieben. Schritt 5: Speichern Sie die OpenID zusammen mit der MAC-Adresse des Geräts in der Gästedatenbank. Bei nachfolgenden Besuchen löst die wiederkehrende OpenID eine geräuschlose Re-Authentifizierung aus.
Ein Einkaufszentrum möchte das Geschlecht und die Stadt von chinesischen Käufern über das Gäste-WiFi erfassen, um diese Daten in seine Analyseplattform einzuspeisen. Derzeit nutzen sie ein MAC Authentication Bypass für ihr bestehendes Portal auf HPE Aruba-Hardware.
Schritt 1: Registrieren Sie ein Service-Konto auf der WeChat Official Accounts Platform. Schritt 2: Konfigurieren Sie das Portal so, dass es den Scope "snsapi_userinfo" verwendet, um Geschlecht und Stadt abzurufen. Schritt 3: Fügen Sie einen klaren Zustimmungsbildschirm hinzu, der den Mehrwert erklärt: kostenloses WiFi im Austausch für den Zugriff auf Profildaten. Die Zustimmung muss sowohl unter GDPR als auch unter PIPL ausdrücklich und granular erfolgen. Schritt 4: Nach der Authentifizierung registriert der Portalserver die MAC-Adresse des Geräts in der RADIUS-Datenbank. Der HPE Aruba-Controller erlaubt den Zugriff über MAB. Schritt 5: Dokumentieren Sie die Rechtsgrundlage (Zustimmung), den Zweck (Standortanalyse und Marketing) und die Aufbewahrungsfrist (24 Monate) in einem Datenverarbeitungsregister. Bieten Sie einen Mechanismus zur Datenlöschung an.
Übungsfragen
Q1. Sie stellen ein Captive Portal in einem Stadion bereit. Sie möchten, dass sich wiederkehrende Dauerkarteninhaber, die sich zuvor authentifiziert haben, bei zukünftigen Besuchen automatisch verbinden, ohne einen Anmeldebildschirm zu sehen. Welchen WeChat-OAuth-Scope sollten Sie für den Ablauf der erneuten Authentifizierung implementieren und warum?
Hinweis: Überlegen Sie, welcher Scope eine stille Authentifizierung ermöglicht, ohne den Benutzer bei jedem Besuch zur Zustimmung aufzufordern.
Musterlösung anzeigen
Verwenden Sie snsapi_base. Dieser Scope gibt nur die OpenID des Benutzers zurück und erfordert keine Zustimmungsaufforderung, was eine stille erneute Authentifizierung ermöglicht. Beim ersten Besuch speichern Sie die OpenID im Profil des Fans. Bei nachfolgenden Besuchen erkennt das Portal die wiederkehrende OpenID über snsapi_base, bestätigt die Übereinstimmung und gibt eine RADIUS CoA aus, um den Zugriff zu gewähren - all dies, ohne dass der Fan einen Anmeldebildschirm sieht. Dies steht auch im Einklang mit den GDPR-Grundsätzen der Datenminimierung, da Sie keine zusätzlichen Daten erheben, die über das für die Authentifizierungsfunktion erforderliche Maß hinausgehen.
Q2. Während des Tests leitet Ihr Portal erfolgreich zu WeChat weiter, der Benutzer erteilt seine Zustimmung und WeChat leitet zurück zu Ihrem Portal. Die Portal-Serverprotokolle zeigen jedoch den OAuth-Fehler 40029 (ungültiger Code). Was ist der wahrscheinlichste Konfigurationsfehler und wie beheben Sie ihn?
Hinweis: WeChat validiert das Ziel, an das es den Autorisierungscode sendet, streng anhand einer registrierten Liste.
Musterlösung anzeigen
Die wahrscheinlichste Ursache ist eine Diskrepanz bei der Redirect-URI. WeChat validiert die Redirect-URI in der OAuth-Anfrage mit der auf der Plattform registrierten autorisierten Domain. Wenn der Portal-Server eine andere Subdomain, einen anderen Pfad oder HTTP anstelle von HTTPS verwendet, schlägt der Code-Austausch mit dem Fehler 40029 fehl. Lösung: Melden Sie sich auf der WeChat-Entwicklerplattform an, navigieren Sie zu den Einstellungen Ihres Service-Kontos oder Ihrer Website-Anwendung und fügen Sie jede von Ihnen verwendete Redirect-URI-Variante hinzu - einschließlich Staging-Subdomains, verschiedener Pfade und HTTPS-Versionen. Stellen Sie sicher, dass der Parameter redirect_uri in Ihrer OAuth-Anfrage exakt mit einer der registrierten URIs übereinstimmt, einschließlich der URL-Codierung.
Q3. Ein IT-Manager schlägt vor, das WeChat AppSecret in das Frontend-JavaScript des Captive Portals einzubetten, um den Token-Austauschprozess direkt über den Client-Browser zu beschleunigen. Warum müssen Sie diesen Vorschlag ablehnen und wie sieht die korrekte Architektur aus?
Hinweis: Bedenken Sie die Sicherheitsrisiken, die entstehen, wenn kryptografische Schlüssel in öffentlich zugänglichem Code offengelegt werden.
Musterlösung anzeigen
Lehnen Sie diesen Vorschlag ab. Das AppSecret ist ein vertraulicher kryptografischer Schlüssel. Wenn es in das clientseitige JavaScript eingebettet wird, ist es für jeden sichtbar, der den Quellcode der Seite aufruft oder den Netzwerkverkehr abfängt. Ein Angreifer kann das AppSecret auslesen, sich als die Anwendung ausgeben, WeChat APIs im Namen des Standorts aufrufen, auf Benutzerdaten zugreifen und möglicherweise das gesamte offizielle Konto kompromittieren. Die korrekte Architektur: Die clientseitige Portalseite empfängt den Autorisierungscode von WeChat und leitet ihn über einen serverseitigen API-Aufruf an den Portal-Server weiter. Der Portal-Server speichert das AppSecret in einer sicheren Umgebungsvariablen und führt den Token-Austausch mit der WeChat-API durch. Das AppSecret verlässt den Server zu keinem Zeitpunkt.
Q4. Eine Hotelgruppe mit 15 Standorten in Europa möchte ein einheitliches Gästeprofil erstellen, das erkennt, wenn derselbe chinesische Gast in verschiedenen Hotels übernachtet. Jedes Hotel hat sein eigenes offizielles WeChat-Konto. Welche WeChat-Kennung sollte verwendet werden und welche Konfiguration ist erforderlich?
Hinweis: Die OpenID ist kontospezifisch. Es gibt eine andere Kennung, die für die kontoübergreifende Erkennung konzipiert ist.
Musterlösung anzeigen
Verwenden Sie die UnionID. Die OpenID ändert sich pro offiziellem Konto, sodass derselbe Gast 15 verschiedene OpenIDs in 15 Konten hat. Die UnionID ist eine stabile Kennung, die einen Benutzer über alle offiziellen Konten und Apps hinweg darstellt, die mit demselben Open Platform-Konto verknüpft sind. Erforderliche Konfiguration: Verknüpfen Sie alle 15 offiziellen Konten mit einem einzigen WeChat Open Platform-Konto. Nach der Verknüpfung wird die UnionID in der OAuth-Antwort zurückgegeben, sobald der Benutzer mindestens eines der verknüpften Konten autorisiert hat. Verwenden Sie die UnionID als Primärschlüssel im Gäste-CRM, um standortübergreifende Profile zu erstellen und wiederkehrende Gäste unabhängig vom besuchten Standort zu erkennen.
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.