Zum Hauptinhalt springen

So konfigurieren Sie die WeChat OAuth-Authentifizierung für Captive Portals

Dieser technische Leitfaden erklärt, wie Sie die WeChat OAuth-Authentifizierung für Captive Portals konfigurieren. Er beschreibt die erforderlichen Plattform-Registrierungen, den OAuth 2.0-Ablauf, die Auswahl des Scopes und die Mechanismen zur Netzwerkerzwingung, die erforderlich sind, um First-Party-Daten von chinesischen Besuchern sicher zu erfassen.

📖 4 Min. Lesezeit📝 815 Wörter🔧 2 ausgearbeitete Beispiele3 Übungsfragen📚 8 Schlüsseldefinitionen

Diesen Leitfaden anhören

Podcast-Transkript ansehen
SO KONFIGURIEREN SIE DIE 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. WeChat hat laut den Daten von Tencent aus dem Jahr 2024 1,38 Milliarden monatlich aktive Nutzer. Die überwältigende Mehrheit befindet sich in China, aber die Plattform hat auch eine bedeutende internationale Präsenz - vier Millionen Nutzer in den USA, 12 Millionen in Malaysia und wachsende Zahlen in Südostasien, Europa und dem Nahen Osten. 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 Hindernisse. Möglicherweise hat er auf diesem Gerät keine lokale E-Mail-Adresse eingerichtet. Aber er hat mit fast absoluter Sicherheit WeChat. Die Frage ist also nicht, ob Sie den WeChat-Login anbieten sollten - sondern 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 Plattformregistrierungen, die Scope-Entscheidung, die bestimmt, welche Daten Sie erfassen, den netzwerkseitigen Durchsetzungsmechanismus und die Compliance-Überlegungen, die im Jahr 2026 wichtig sind. --- TECHNISCHER DEEP-DIVE (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 Portal-Server gehostet - entweder vor Ort oder in der Cloud. Wenn Sie WeChat-OAuth hinzufügen, binden Sie einen Drittanbieter-Identitätsanbieter in diesen Ablauf ein. Hier ist die Sequenz. 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 Portal-Seite lädt und zeigt die Anmeldeoptionen an - einschließlich WeChat. Der Gast tippt auf WeChat-Login. Ihr Portal-Server leitet den Browser an den Autorisierungs-Endpunkt von WeChat unter open.weixin.qq.com 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 im Browser bei WeChat angemeldet ist, sieht er einen Zustimmungsbildschirm. Wenn er den In-App-Browser von WeChat verwendet, kann die Benutzererfahrung mit dem Scope snsapi_base völlig geräuschlos sein - ohne jegliche Zustimmungsaufforderung. WeChat leitet dann mit einem temporären Autorisierungscode zurück zur Redirect-URI Ihres Portals weiter. Ihr Portal-Server tauscht diesen Code gegen ein Access Token aus, indem er api.weixin.qq.com/sns/oauth2/access_token aufruft und Ihre AppID, Ihr AppSecret, den Code und den Grant Type authorization_code übergibt. WeChat gibt ein Access Token, ein Refresh Token, die OpenID des Benutzers und den erteilten Scope zurück. Wenn Sie den Scope snsapi_userinfo angefordert haben, können Sie einen zweiten API-Aufruf durchführen, um den Spitznamen, den Avatar, das Geschlecht und die Stadt des Benutzers abzurufen.Nun zu den beiden Plattform-Registrierungen. Hier schleichen sich bei den meisten Implementierungen Fehler ein. WeChat bietet zwei separate Entwicklerplattformen. Die WeChat Open Platform unter open.weixin.qq.com verwaltet Website-Anwendungen und mobile Apps. Die WeChat Official Accounts Platform unter mp.weixin.qq.com verwaltet öffentliche Konten - also das, was die meisten Standorte tatsächlich benötigen. Für ein Captive Portal, das Gästen innerhalb des WeChat-In-App-Browsers bereitgestellt wird, benötigen Sie ein Service Account auf der Official Accounts Platform. Ein Subscription Account funktioniert hierbei nicht - es verfügt nicht über die erforderlichen OAuth-Berechtigungen zur Autorisierung von Webseiten. Ein Service Account bietet diese und unterstützt sowohl die Scopes snsapi_base als auch snsapi_userinfo. Für ein Captive Portal, auf das über einen standardmäßigen mobilen Browser außerhalb von WeChat zugegriffen wird - Chrome auf Android oder Safari auf iOS - benötigen Sie eine Website-Anwendung, die auf der Open Platform registriert ist. Diese verwendet den Scope snsapi_login und stellt einen QR-Code dar, den der Benutzer mit seiner WeChat-App scannt. In der Praxis nutzen die meisten Bereitstellungen an Standorten beide Varianten. Ein Gast im WiFi eines Hotels ö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 selbst, gelangt in den In-App-Browser und authentifiziert sich geräuschlos via snsapi_base. Lassen Sie uns über die Auswahl des Scopes sprechen, da dies eine wichtige Entscheidung ist. snsapi_base gibt nur die OpenID zurück - eine eindeutige Kennung für diesen Benutzer innerhalb Ihres Official Accounts. Dies erfordert keine Zustimmung des Benutzers. Die Authentifizierung erfolgt für den Benutzer unsichtbar. Dies eignet sich 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. 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, ob er Ihrem Official Account den Zugriff auf seine Daten gestattet. Die meisten Benutzer stimmen zu, aber es entsteht eine Hürde. Die richtige Wahl hängt von Ihrem Anwendungsfall ab. Für die Registrierung eines Erstbesuchers, bei der Sie ein Profil erstellen möchten, verwenden Sie snsapi_userinfo und kombinieren Sie dies mit einer GDPR-konformen Einwilligungsebene auf Ihrer Portalseite. Für einen wiederkehrenden Gast, der bereits eingewilligt hat und dessen Profil Sie bereits besitzen, nutzen Sie snsapi_base für eine geräuschlose Re-Authentifizierung. Nun zur Netzwerk-Durchsetzung. Der Erhalt eines OAuth-Tokens beweist zwar die Identität, öffnet aber nicht automatisch das Netzwerk. Sie benötigen einen Mechanismus, um eine erfolgreiche Authentifizierung in einen Netzwerkzugriff zu übersetzen.Die zwei Standardverfahren sind RADIUS Change of Authorisation, definiert in RFC 3576, und MAC-Adress-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 nicht authentifizierten VLAN in das Gäste-VLAN. Dies funktioniert mit Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist und den meisten anderen Enterprise-Controllern. Beim 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. Die Guest WiFi-Plattform von Purple unterstützt beide Mechanismen. Nach Abschluss des WeChat-OAuth-Vorgangs sendet das Cloud-Overlay von Purple das entsprechende Signal an die zugrunde liegende Hardware - ob es sich nun um Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme oder Fortinet handelt. Der Standortbetreiber muss diese Übersetzung nicht manuell verwalten. --- IMPLEMENTIERUNGSEMPFEHLUNGEN UND STOLPERSTEINE (ca. 2 Minuten) Hier sind die fünf häufigsten Gründe, warum Implementierungen von WeChat-OAuth-Captive-Portalen fehlschlagen. Erstens: Abweichungen 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 - ungültiger Code - fehl. Registrieren Sie jede von Ihnen verwendete Domain-Variante, einschließlich Staging-Umgebungen. Zweitens: Das AppSecret auf Client-Seite. Ihr AppSecret darf niemals im clientseitigen JavaScript oder in einer mobilen App-Binärdatei auftauchen. 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 Benutzersitzung und validieren Sie ihn, wenn WeChat zurückleitet. Wenn Sie dies überspringen, haben Sie eine echte Sicherheitslücke. Viertens: Fehlende In-App-Browser-Erkennung. Der In-App-Browser von WeChat setzt einen spezifischen User-Agent-String, der "MicroMessenger" enthält. Wenn Ihr Portal dies nicht erkennt und nicht den richtigen OAuth-Flow ausliefert - Official-Account-Flow für den In-App-Browser, Open-Platform-QR-Flow für Standard-Browser - erhalten Benutzer eine fehlerhafte Darstellung oder eine Fehlermeldung. Fünftens: Abstimmung von 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 Chinas Personal Information Protection Law - PIPL - für die Verarbeitung ihrer Daten. Beide erfordern eine Rechtsgrundlage für die Verarbeitung, eine klare Zweckbindung und Datenminimierung. snsapi_base ist unter den Grundsätzen der Datenminimierung leichter zu rechtfertigen als snsapi_userinfo. Dokumentieren Sie unabhängig von Ihren erfassten Daten Ihre Rechtsgrundlage und Ihre Speicherfrist. --- SCHNELLE FRAGEN UND ANTWORTEN (ca. 1 Minute) Frage: Kann ich die WeChat-Anmeldung auf einem Portal nutzen, das auch E-Mail- und SMS-Anmeldung 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. Die WeChat-Anmeldung 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 API von WeChat nicht verfügbar ist? Ihr Portal sollte ein 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 bei diesen unterschiedliche OpenIDs. Für die kontoübergreifende Identitätsauflösung bietet WeChat eine UnionID an, 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 Scope-Entscheidung, eine Integration der Netzwerkdurchsetzung und eine Compliance-Prüfung. Wenn Sie diese vier Punkte richtig angehen, erhalten Sie eine Anmeldemethode, die über eine Milliarde potenzieller Besucher ohne jeglichen Passwort-Frust bedient. Die praktischen nächsten Schritte sind folgende: Bestimmen Sie erstens, ob Ihre Besucher das Portal im In-App-Browser von WeChat oder in einem Standard-Mobilbrowser aufrufen - das entscheidet darüber, welche Plattformregistrierung Sie benötigen. Entscheiden Sie zweitens über den Scope - snsapi_base für wiederkehrende Gäste, snsapi_userinfo für die Erstregistrierung mit Einwilligung. Bestätigen Sie drittens, ob Ihre Netzwerkhardware RADIUS CoA unterstützt, oder konfigurieren Sie MAC-Bypass als Alternative. Überprüfen Sie viertens Ihre Datenschutzerklärung und Ihren Einwilligungsprozess im Hinblick auf die Anforderungen der GDPR und des PIPL. Testen Sie fünftens die Redirect-URI, die Validierung des State-Parameters und die In-App-Browser-Erkennung, bevor Sie live gehen. Wenn Sie sehen möchten, wie Purple WeChat OAuth als Teil einer umfassenderen Guest WiFi- und Analyseplattform handhabt - auf über 80.000 Standorten und bei 440 Millionen Anmeldungen im Jahr 2024 - besuchen Sie purple.ai oder sprechen Sie mit Ihrem Account-Team. Vielen Dank fürs Zuhören. - ENDE DES SKRIPTS

header_image.png

Management-Zusammenfassung

Wenn chinesische Besucher eine Verbindung zu Ihrem WiFi herstellen, stellt eine Begrüßungsseite mit Optionen zur Anmeldung nur über E-Mail oder Facebook eine unmittelbare Einstiegshürde dar. Mit 13,8 Milliarden monatlich aktiven Nutzern beseitigt die Konfiguration von WeChat als Identitätsanbieter diese Reibungspunkte. Dieses Handbuch zeigt, wie Sie die WeChat OAuth 2.0-Authentifizierung für Captive Portals implementieren, und beschreibt detailliert die erforderlichen Plattformregistrierungen, OAuth-Flows sowie die Mechanismen zur Netzwerkerzwingung, die erforderlich sind, um eine erfolgreiche Anmeldung in einen Netzwerkzugriff umzuwandeln. Wir behandeln die technische Implementierung für Enterprise-Hardware sowie die Compliance-Anforderungen unter GDPR und PIPL.

Technische Architektur

Das Captive Portal fängt den HTTP-Verkehr von nicht authentifizierten Geräten ab und leitet sie auf eine Begrüßungsseite weiter, die auf einem Portalserver gehostet wird. Wenn Sie die WeChat-OAuth-Integration implementieren, fügen Sie einen Drittanbieter-Identitätsanbieter in diesen Ablauf ein.

architecture_overview.png

Hier ist der genaue Schritt-für-Schritt-Ablauf:

  1. Der Besucher verbindet sich mit der SSID.
  2. Der Wireless Access Point (AP) oder Wireless Controller erkennt das Fehlen einer authentifizierten Sitzung und leitet den HTTP-Verkehr an die Captive Portal-URL weiter.
  3. Der Besucher wählt den WeChat-Login.
  4. Der Portalserver leitet den Browser zum Autorisierungs-Endpunkt von WeChat (open.weixin.qq.com) weiter und übergibt die AppID, die redirect_uri, den response_type=code und den scope.
  5. WeChat übernimmt die Authentifizierung. Wenn sich der Besucher im In-App-Browser von WeChat befindet und den Scope snsapi_base verwendet, geschieht dies geräuschlos im Hintergrund.
  6. WeChat leitet mit einem temporären Autorisierungscode an die redirect_uri des Portals zurück.
  7. Der Portalserver tauscht diesen Code durch Aufruf von api.weixin.qq.com/sns/oauth2/access_token gegen ein Access Token aus.
  8. WeChat gibt das access_token, das refresh_token und die openid des Benutzers zurück.

Anforderungen an die Plattformregistrierung

Die Implementierung des WeChat-Logins erfordert die Registrierung auf der richtigen Entwicklerplattform. WeChat betreibt zwei separate Plattformen. Die Auswahl der falschen Plattform führt zum Fehlschlagen der Integration.

WeChat Official Accounts-Plattform

Für Captive Portals, die innerhalb des WeChat-In-App-Browsers bereitgestellt werden, benötigen Sie ein Service-Konto, das auf der WeChat Official Accounts Platform (mp.weixin.qq.com) registriert ist. Abonnement-Konten verfügen nicht über die erforderlichen OAuth-Webseiten-Autorisierungsberechtigungen. Service-Konten unterstützen sowohl den snsapi_base- als auch den snsapi_userinfo-Bereich.

WeChat Open Platform

Für Captive Portals, auf die über standardmäßige mobile Browser außerhalb von WeChat zugegriffen wird (z. B. Chrome auf Android oder Safari auf iOS), benötigen Sie eine Website-Anwendung, die auf der Open Platform (open.weixin.qq.com) registriert ist. Diese verwendet den snsapi_login-Bereich und zeigt einen QR-Code an, den der Benutzer mit seiner WeChat-App scannen muss.

Die meisten Enterprise-Bereitstellungen erfordern beide Registrierungen, um alle Zugriffspfade abzudecken.

Bereichsauswahl und Datenerfassung

Der Parameter "Scope" bestimmt, welche Daten WeChat an Ihren Portal-Server zurückgibt. Diese Entscheidung wirkt sich sowohl auf die Benutzererfahrung als auch auf die Einhaltung des Datenschutzes aus.

scope_comparison_chart.png

snsapi_base

Dieser Bereich gibt nur die OpenID zurück, den eindeutigen Identifikator für den Benutzer innerhalb Ihres Official Accounts. Er erfordert keine Aufforderung zur Benutzerautorisierung, sodass die Authentifizierung im Hintergrund abläuft. Dies ist optimal für wiederkehrende Besucher, für die Sie bereits ein Profil haben, oder für Standorte, die Reibungslosigkeit über die Erfassung neuer Daten stellen.

snsapi_userinfo

Dieser Bereich gibt die OpenID zusammen mit dem WeChat-Spitznamen des Benutzers, dem Profilbild, dem Geschlecht, den Spracheinstellungen und der Stadt zurück. Er erfordert eine explizite Autorisierungsseite, was eine zusätzliche Interaktion erfordert. Verwenden Sie dies für die Registrierung von Erstbesuchern, wenn die Erstellung eines Profils erforderlich ist, kombiniert mit einer GDPR-konformen Einwilligungsebene.

Integration der Netzwerk-Erzwingung

Der Erhalt eines OAuth-Tokens beweist die Identität, öffnet aber nicht das Netzwerk. Sie müssen eine erfolgreiche Authentifizierung mithilfe von Standardprotokollen in Netzwerkzugriff umsetzen.

RADIUS Change of Authorization (CoA)

Definiert in IEEE 802.1X und RFC 3576, ermöglicht RADIUS CoA dem Portal-Server, nach erfolgreichem OAuth eine Anfrage an den Netzwerk-Controller zu senden. Der Controller verschiebt das Gerät dann von einem nicht authentifizierten VLAN in ein Gäste-VLAN. Dies ist der Standard für Enterprise-Hardware, einschließlich Cisco Meraki, HPE Aruba, Ruckus und Juniper Mist.

MAC-Adress-Bypass

Alternativ registriert der Portal-Server die MAC-Adresse des Geräts als autorisierten Client, und der Controller gestattet den Zugriff. Dies ist zwar einfacher zu implementieren, aber weniger sicher, da MAC-Adressen gefälscht werden können.

Die Cloud-Overlay-Technologie von Purple automatisiert diese Übergabe und sendet die entsprechenden Signale an die zugrunde liegende Hardware (einschließlich Ubiquiti UniFi, Cambium, Extreme und Fortinet), sobald das WeChat-OAuth abgeschlossen ist.

Compliance- und Sicherheitsüberlegungen

GDPR- und PIPL-Abstimmung

Wenn Sie europäische Besucher bedienen, gilt die GDPR für Daten, die über WeChat-OAuth erhoben werden. Wenn Sie chinesische Besucher bedienen, gilt das chinesische Gesetz zum Schutz persönlicher Informationen (PIPL). Beide Rahmenbedingungen erfordern eine rechtmäßige Grundlage für die Verarbeitung, eine ausdrückliche Zweckbindung und Datenminimierung. Im Vergleich zum snsapi_userinfo-Bereich lässt sich der snsapi_base-Bereich einfacher mit den Grundsätzen der Datenminimierung vereinbaren.

CSRF-Schutz

Der Parameter state in OAuth-Anfragen verhindert Cross-Site Request Forgery. Sie müssen einen kryptografisch zufälligen Zustandswert generieren, diesen in der Benutzersitzung speichern und validieren, wenn WeChat zurückleitet.

Validierung der Redirect-URI

WeChat validiert die redirect_uri mit der auf der Plattform registrierten autorisierten Domain. Wenn Ihr Portal-Server eine andere Subdomain oder einen anderen Pfad verwendet oder HTTP anstelle von HTTPS nutzt, schlägt der OAuth-Ablauf mit dem Fehler 40029 fehl.

Für weitere Informationen zur Sicherung Ihres Netzwerks lesen Sie unseren Leitfaden Enterprise WiFi Security: Ein vollständiger Leitfaden für 2026 .

Schlüsseldefinitionen

snsapi_base

Ein WeChat OAuth-Scope, der nur die OpenID des Benutzers zurückgibt, ohne eine Einverständniserklärung anzuzeigen.

Wird verwendet, wenn IT-Teams wiederkehrende Besucher stillschweigend authentifizieren müssen, ohne Reibungsverluste beim Login zu verursachen.

snsapi_userinfo

Ein WeChat OAuth-Scope, der die OpenID zusammen mit demografischen Daten (Spitzname, Geschlecht, Stadt) zurückgibt und die ausdrückliche Zustimmung des Benutzers erfordert.

Wird bei der Erstregistrierung verwendet, wenn Marketingteams ein Besucherprofil erstellen müssen.

OpenID

Eine eindeutige Kennung für einen bestimmten Benutzer innerhalb eines bestimmten WeChat Official Account.

Wird als Primärschlüssel in der Portal-Datenbank verwendet, um das Besucherverhalten und wiederkehrende Besuche zu verfolgen.

RADIUS CoA

Change of Authorisation. Ein in RFC 3576 definierter Mechanismus, der es einem Server ermöglicht, den Autorisierungsstatus einer aktiven Sitzung zu ändern.

Wird vom Portalserver verwendet, um dem Wireless-Controller mitzuteilen, dass er nach erfolgreicher WeChat-Authentifizierung den Netzwerkzugriff gewähren soll.

PIPL

Personal Information Protection Law. Chinas umfassende Datenschutzverordnung.

Muss neben der GDPR berücksichtigt werden, wenn der Einwilligungsablauf für chinesische Besucher, die den WeChat-Login nutzen, gestaltet wird.

AppID and AppSecret

Die von WeChat bereitgestellten Anmeldedaten zur Identifizierung und Authentifizierung Ihrer Anwendung.

Das AppSecret muss sicher auf dem Portalserver verbleiben und darf niemals im clientseitigen Code offengelegt werden.

State Parameter

Eine kryptografisch zufällige Zeichenfolge, die im OAuth-Request übergeben und bei der Rückkehr validiert wird.

Unerlässlich zur Verhinderung von Cross-Site Request Forgery (CSRF)-Angriffen auf das Captive Portal.

MAC Address Bypass

Eine Methode zur Gewährung des Netzwerkzugriffs durch Autorisierung der Hardwareadresse des Geräts, anstatt eine 802.1X-Authentifizierung zu erfordern.

Eine Alternative zu RADIUS CoA für einfachere Netzwerkeinrichtungen, wenn auch weniger sicher.

Ausgearbeitete Beispiele

Eine Luxus-Einzelhandelsmarke in London möchte WeChat-Login für chinesische Käufer anbieten. Sie möchten demografische Daten erfassen, um ihren Kundenstamm besser zu verstehen, sind jedoch besorgt über die GDPR-Konformität und hohe Absprungraten auf dem Portal.

Der Einzelhändler sollte ein Service-Konto auf der WeChat Official Accounts Platform registrieren. Er muss das Portal so konfigurieren, dass es bei Erstverbindungen den Scope snsapi_userinfo verwendet, um demografische Daten (Spitzname, Geschlecht, Stadt) zu erfassen. Um die GDPR-Konformität zu gewährleisten, muss die Portalseite vor der WeChat-Weiterleitung ein klares, bewusstes Opt-in anzeigen und genau erklären, welche Daten erfasst werden und warum. Für wiederkehrende Käufer sollte das Portal die MAC-Adresse erkennen und snsapi_base für eine stille Re-Authentifizierung verwenden, um Reibungsverluste zu minimieren.

Kommentar des Prüfers: Dieser Ansatz gleicht die Datenerfassung mit der Benutzererfahrung ab. Durch die Begrenzung des reibungsintensiven `snsapi_userinfo`-Ablaufs auf den ersten Besuch und die anschließende Nutzung von `snsapi_base` maximiert der Einzelhändler die Konversionsrate und bleibt gleichzeitig konform mit den Prinzipien der Datenminimierung.

Ein Stadion stellt ein neues WiFi-Netzwerk unter Verwendung von HPE Aruba-Controllern bereit. Sie haben WeChat OAuth konfiguriert und das Portal erhält erfolgreich das Access Token, aber das Gerät des Besuchers verbleibt auf der Captive Portal-Seite und kann nicht auf das Internet zugreifen.

Der Integration fehlt ein Mechanismus zur Netzwerkerzwingung. Der Portalserver hat die Identität des Benutzers bei WeChat verifiziert, aber er hat den HPE Aruba-Controller nicht angewiesen, den Zugriff freizugeben. Der Portalserver muss so konfiguriert werden, dass er eine RADIUS Change of Authorisation (CoA)-Nachricht an den Controller sendet und diesen anweist, die MAC-Adresse des Benutzers von der Pre-Authentifizierungsrolle in die authentifizierte Gastrolle zu überführen.

Kommentar des Prüfers: Dies verdeutlicht den Unterschied zwischen Identitätsprüfung und Netzwerkzugriffskontrolle. Unternehmensnetzwerke erfordern ein Protokoll wie RADIUS CoA, um die Lücke zwischen der Webanwendung (Portal) und der Netzwerkinfrastruktur zu schließen.

Übungsfragen

Q1. Sie stellen ein Captive Portal in einer Einzelhandelskette bereit. Tests zeigen, dass Benutzer, die das Portal in Safari auf iOS öffnen, eine Fehlermeldung erhalten, wenn sie das WeChat-Login wählen. Benutzer, die das Portal über einen WeChat-Nachrichtenlink öffnen, können sich jedoch erfolgreich authentifizieren. Was ist die wahrscheinlichste Ursache?

Hinweis: Berücksichtigen Sie den Unterschied zwischen dem WeChat In-App-Browser und standardmäßigen mobilen Browsern.

Musterlösung anzeigen

Die Implementierung basiert wahrscheinlich ausschließlich auf einem Service-Konto, das auf der Official Accounts Platform registriert ist, welche nur OAuth innerhalb des WeChat In-App-Browsers unterstützt. Um Safari auf iOS zu unterstützen, müssen Sie auch eine Website-Anwendung auf der WeChat Open Platform registrieren und eine User-Agent-Erkennung implementieren, um Safari-Benutzer zum QR-Code-Flow weiterzuleiten.

Q2. Die Serverprotokolle Ihres Portals zeigen häufige 40029 "invalid code"-Fehler, die während des Access-Token-Austauschs von der WeChat API zurückgegeben werden. Welche Konfiguration sollten Sie zuerst überprüfen?

Hinweis: Überlegen Sie, wie WeChat die Quelle der Authentifizierungsanfrage validiert.

Musterlösung anzeigen

Sie sollten die Konfiguration des redirect_uri überprüfen. WeChat validiert die Redirect-URI streng anhand der in der Entwicklerkonsole registrierten autorisierten Domain. Wenn das Portal eine andere Subdomain verwendet oder HTTPS nicht nutzt, wird WeChat den Code-Austausch ablehnen.

Q3. Ein Betreiber eines Veranstaltungsortes möchte Besucherdaten erfassen, besteht jedoch auf einen reibungslosen Login-Prozess ohne Hürden. Er bittet Sie, das WeChat-Login so zu konfigurieren, dass der Spitzname und die Stadt des Besuchers erfasst werden, ohne dass ein Zustimmungsfenster angezeigt wird. Wie reagieren Sie?

Hinweis: Überprüfen Sie die Funktionen der verschiedenen OAuth-Scopes.

Musterlösung anzeigen

Sie müssen den Betreiber darüber informieren, dass dies technisch unmöglich ist. Die Erfassung demografischer Daten wie Spitzname und Stadt erfordert den Scope snsapi_userinfo, der zwingend ein WeChat-Zustimmungsfenster auslöst. Um einen völlig reibungslosen Prozess zu gewährleisten, müssen Sie snsapi_base verwenden, was geräuschlos im Hintergrund läuft, aber nur die OpenID zurückgibt.