跳至主要內容

將 WeChat 驗證與顧客 WiFi Captive Portals 整合

本指南說明如何將 WeChat OAuth 2.0 驗證整合至企業級顧客 WiFi Captive Portals。內容涵蓋雙平台註冊要求、用於獲取第一方數據的權限範圍(Scope)選擇、透過 RADIUS Change of Authorization 進行的網路強制執行,以及對 GDPR 和中國 PIPL 的合規性。餐旅業、零售業和活動場地的營運商將能從中獲得具體的實作步驟、實際案例研究和安全性強化指南,以大規模部署支援 WeChat 登入的顧客 WiFi。

📖 8 分鐘閱讀📝 1,966 字數🔧 2 範例4 練習題📚 9 關鍵定義

收聽此指南

查看播客逐字稿
如何為 CAPTIVE PORTALS 設定 WECHAT OAUTH 驗證 Purple 技術簡報 - 長度約 10 分鐘 --- 引言與背景(約 1 分鐘) 歡迎。如果您負責服務中國訪客的酒店、零售連鎖店、體育場或會議中心的顧客 WiFi,本簡報非常適合您。 根據騰訊 2024 年的數據,WeChat 擁有 13.8 億月活躍用戶。絕大多數在中國,但該平台在國際上也佔有重要地位——在美國有 400 萬用戶,在馬來西亞有 1200 萬用戶,且在東南亞、歐洲和中東地區的用戶數量也在不斷增長。 當中國顧客連線到您的 WiFi 並看到僅有電子郵件、Facebook 或優惠券代碼的登入頁面時,他們會立即面臨阻礙。他們可能沒有在該裝置上設定本地電子郵件地址。但他們幾乎肯定有 WeChat。因此,問題不在於您是否應該提供 WeChat 登入,而是在於您如何正確、安全地設定它,並以一種能產生您實際可用的第一方數據的方式進行設定。 這就是我們今天將要涵蓋的內容。我們將逐步介紹 OAuth 2.0 流程、您需要的兩個平台註冊、決定您收集哪些數據的權限範圍(Scope)決策、網路端的強制執行機制,以及在 2026 年至關重要的合規性考量。 --- 技術深挖(約 5 分鐘) 讓我們從架構開始。Captive Portal 攔截來自未驗證裝置的 HTTP 流量,並將其重新導向至登入頁面。該登入頁面託管在 Portal 伺服器上——無論是地端還是雲端。當您加入 WeChat OAuth 時,您是在該流程中插入了一個第三方身分識別提供者。 以下是具體順序。顧客連線到您的 SSID。存取點或無線控制器偵測到該裝置沒有已驗證的工作階段,並將所有 HTTP 流量重新導向至您的 Captive Portal URL。Portal 網頁載入並呈現登入選項——包括 WeChat。顧客點擊 WeChat 登入。您的 Portal 伺服器將瀏覽器重新導向至 WeChat 的授權端點,並傳遞您的 App ID、重新導向 URI、回應類型(code)和權限範圍(scope)。 WeChat 完全在自己的伺服器上處理驗證。如果顧客已經在其瀏覽器中登入 WeChat,他們會看到一個同意畫面。如果他們使用的是 WeChat 內建瀏覽器,則使用 snsapi_base 權限範圍可以實現無感體驗——完全沒有同意提示。然後,WeChat 會帶著臨時授權碼重新導向回您 Portal 的重新導向 URI。您的 Portal 伺服器會交換該授權碼以取得 Access Token,並傳遞您的 App ID、App Secret、授權碼和授權碼授權類型。WeChat 會傳回 Access Token、Refresh Token、使用者的 OpenID 以及授予的權限範圍。如果您請求了 snsapi_userinfo 權限範圍,您隨後可以進行第二次 API 呼叫以取得使用者的暱稱、頭像、性別和城市。 現在,來談談這兩個平台註冊。這是大多數實作出錯的地方。 WeChat 有兩個獨立的開發者平台。WeChat 開放平台處理網站應用和行動應用程式。WeChat 公眾平台處理公眾號——這才是大多數場地實際需要的。 對於在 WeChat 內建瀏覽器中為顧客提供服務的 Captive Portal,您需要在公眾平台上註冊服務號。訂閱號將無法運作——它沒有 OAuth 網頁授權權限。服務號則有,且它支援 snsapi_base 和 snsapi_userinfo 權限範圍。 對於從 WeChat 之外的標準行動瀏覽器(Android 上的 Chrome、iOS 上的 Safari)存取的 Captive Portal,您需要在開放平台上註冊網站應用。這使用 snsapi_login 權限範圍,並呈現一個 QR Code 供使用者使用其 WeChat 應用程式進行掃描。 在實務中,大多數場地部署兩者都會使用。酒店 WiFi 上的顧客可能會在 Chrome 中開啟 Portal,看到 QR Code,用 WeChat 掃描並進行驗證。或者他們可能會點擊 WeChat 本身中的連結,進入內建瀏覽器,並使用 snsapi_base 進行無感驗證。 讓我們來談談權限範圍(Scope)的選擇,因為這是一個真正的決策點。 snsapi_base 僅傳回 OpenID——該使用者在您公眾號內的唯一識別碼。它不需要使用者同意提示。驗證對使用者而言是無感的。這非常適合您已經建立個人檔案的回訪顧客,或您希望實現零阻礙的場地。 snsapi_userinfo 傳回 OpenID 以及使用者的 WeChat 暱稱、個人頭像、性別、語言設定和城市。它需要一個明確的同意畫面。大多數使用者會接受,但這會帶來阻礙。 正確的選擇取決於您的使用案例。對於您希望建立個人檔案的首次顧客註冊,請使用 snsapi_userinfo,並在您的 Portal 網頁上搭配符合 GDPR 規範的同意層。對於已經同意且您已擁有其個人檔案的回訪顧客,請使用 snsapi_base 進行無感重新驗證。 現在,來談談網路強制執行端。獲取 OAuth Token 可以證明身分,但它不會自動開啟網路。您需要一種機制將成功的驗證轉換為網路存取權限。 兩種標準方法是 RFC 3576 中定義的 RADIUS Change of Authorization (CoA) 以及 MAC 位址旁路。使用 RADIUS CoA,您的 Portal 伺服器在成功進行 OAuth 後向網路控制器發送 CoA 請求,控制器會將裝置從未驗證的 VLAN 移至顧客 VLAN。這適用於 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist 以及大多數企業級控制器。使用 MAC 旁路,Portal 伺服器將裝置的 MAC 位址註冊為已授權用戶端,控制器隨即允許其存取。MAC 旁路實作較為簡單,但安全性較低,因為 MAC 位址可以被偽造。 Purple 的顧客 WiFi 平台可處理這兩種機制。在 WeChat OAuth 完成後,Purple 的雲端重疊網路(Cloud Overlay)會向底層硬體發送適當的訊號——無論是 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 還是 Fortinet。場地營運商不需要手動管理該轉換。 --- 實作建議與常見陷阱(約 2 分鐘) 讓我為您指出導致 WeChat OAuth Captive Portal 實作失敗的五個主要原因。 第一:重新導向 URI 不符。WeChat 會根據您在平台上註冊的授權網域驗證重新導向 URI。如果您的 Portal 伺服器使用不同的子網域、不同的路徑,或使用 HTTP 而非 HTTPS,則 OAuth 流程將失敗並顯示錯誤 40029 - 無效的授權碼。請註冊您使用的每個網域變體,包括測試環境。 第二:用戶端的 App Secret。您的 App Secret 絕不能出現在用戶端 JavaScript 中。它屬於您的伺服器。如果它被洩露,任何人都可以冒充您的應用程式並代表您呼叫 WeChat 的 API。 第三:缺少 CSRF 保護。OAuth 請求中的 state 參數專門用於防止跨站請求偽造。產生一個加密隨機的 state 值,將其儲存在使用者的工作階段中,並在 WeChat 重新導向回來時進行驗證。跳過此步驟,您將面臨真正的安全性漏洞。 第四:內建瀏覽器偵測遺漏。WeChat 的內建瀏覽器會設定一個包含 MicroMessenger 的特定使用者代理(User Agent)字串。如果您的 Portal 未偵測到此字串並提供正確的 OAuth 流程,使用者將獲得中斷的體驗或收到錯誤。 第五:GDPR 和 PIPL 的協調。如果您服務歐洲訪客,則適用 GDPR。如果您服務中國訪客,則適用中國的個人資訊保護法(PIPL)。兩者都需要處理的合法依據、明確的目的限制和數據最小化。在數據最小化原則下,snsapi_base 比 snsapi_userinfo 更容易進行合規說明。無論您收集什麼,請記錄您的法律依據和保留期限。 --- 快速問答(約 1 分鐘) 我可以在同時提供電子郵件和簡訊登入的 Portal 上使用 WeChat 登入嗎?可以。包括 Purple 在內的大多數企業級 Portal 平台都支援在同一個 Portal 網頁上提供多種驗證方法。 WeChat OAuth 在 iOS 上可以運作嗎?可以。iOS 上 Safari 中的 WeChat 登入可透過 QR Code 流程或重新導向流程運作。WeChat 應用程式本身會處理驗證。 如果 WeChat 的 API 無法使用會怎樣?請實作備用方案。如果 WeChat API 呼叫逾時或傳回錯誤,請將使用者重新導向至其他登入方法。 我可以使用 OpenID 作為持久的客戶識別碼嗎?在您的公眾號內是可以的。對於跨多個物業的跨帳戶身分識別,請改用 UnionID。 --- 總結與後續步驟(約 1 分鐘) 總結來說。為 Captive Portals 設定 WeChat OAuth 驗證是一項涉及雙平台註冊、權限範圍決策、網路強制執行整合以及合規性審查的工作。做好這四件事,您就擁有一種能以零密碼阻礙服務超過十億潛在訪客的登入方法。 實際的後續步驟:確定您的訪客是在 WeChat 內建瀏覽器中還是在標準行動瀏覽器中遇到 Portal。決定權限範圍——回訪顧客使用 snsapi_base,需要同意的首次註冊使用 snsapi_userinfo。確認您的網路硬體支援 RADIUS CoA。對照 GDPR 和 PIPL 審查您的隱私權聲明。在正式上線前,測試重新導向 URI、state 參數驗證以及內建瀏覽器偵測。 如果您想了解 Purple 如何將 WeChat OAuth 作為更廣泛的顧客 WiFi 和分析平台的一部分進行處理(在 2024 年跨越 80,000 個場地和 4.4 億次登入),請造訪 purple.ai 或與您的客戶團隊聯絡。 感謝您的收聽。 --- 劇本結束

header_image.png

摘要

当中国访客连接到您的企业网络并遇到一个仅提供电子邮件、Facebook或凭证代码的 Captive Portal 时,您会立即产生摩擦。根据腾讯2024年的数据,微信拥有13.8亿月活跃用户。集成微信登录 guest wifi 功能并不是一种款待便利,而是在没有摩擦的情况下捕获该人群第一方数据的技术要求。

本指南详细介绍了将微信 OAuth 2.0 身份验证集成到 captive portals 的技术架构。它解释了支持标准移动浏览器和微信应用内浏览器所需的双平台注册,评估了用于数据收集的 snsapi_basesnsapi_userinfo 作用域之间的权衡,并概述了如何使用 RADIUS 授权变更 (CoA) 或 MAC 身份验证旁路来强制网络访问。它还涵盖了在 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 基础设施中大规模部署此功能所需的安全配置和合规性指令——GDPR 和中国《个人信息保护法》(PIPL)。


技术深度剖析:微信 OAuth 2.0 架构

Captive Portal 会拦截来自未验证设备的 HTTP 流量,并将其重定向到托管在门户服务器上的登录页面。添加微信身份验证会使用 OAuth 2.0 协议将第三方身份验证提供商插入到此流程中,该协议与 Google、Microsoft Entra ID 和 Okta 用于联合身份验证的标准相同。

oauth_flow_diagram.png

认证流程的操作如下:访客连接到 SSID。接入点或无线控制器检测到未认证的会话,并将 HTTP 流量重定向到 Captive Portal URL。访客在 Portal 页面上选择微信登录。Portal 服务器将浏览器重定向到 open.weixin.qq.com 的微信授权端点,并传递 AppID、重定向 URI、code 的响应类型以及请求的 Scope。微信在其自己的服务器上处理认证。如果访客在微信内置浏览器中使用 snsapi_base Scope,则认证是无感知的——不会出现授权同意提示。如果使用 snsapi_userinfo,微信会显示一个授权同意页面。随后,微信将带着临时授权码重定向回 Portal 的重定向 URI。Portal 服务器通过调用 api.weixin.qq.com/sns/oauth2/access_token 并传递 AppIDAppSecret、该授权码以及 authorization_code 的授权类型,来将此授权码交换为 Access Token。微信将返回 Access Token、Refresh Token、用户的 OpenID 以及已授予的 Scope。如果授予了 snsapi_userinfo,服务器会发起第二次 API 调用,以获取用户的昵称、头像、性别和城市。

双平台注册要求

大多数实施方案都在注册阶段失败。微信运营着两个独立的开发者平台,而企业级部署通常两者都需要。

平台 URL 所需账号类型 支持的 Scope 浏览器环境
公众平台 mp.weixin.qq.com 服务号 snsapi_base, snsapi_userinfo 微信内置浏览器
开放平台 open.weixin.qq.com 网站应用 snsapi_login 标准移动浏览器

对于在微信内置浏览器内访问 Portal 的访客,您需要在公众平台上拥有一个服务号。订阅号将无法工作——它缺少 OAuth 网页授权权限。对于从 Android 上的 Chrome 或 iOS 上的 Safari 访问 Portal 的访客,您需要在开放平台上拥有一个网站应用,该应用使用 snsapi_login Scope 并显示一个二维码供用户扫描。

在实际操作中,大多数场所部署都会同时使用两者。酒店的访客可能会在 Chrome 中打开 Portal,看到一个二维码,用微信扫描它并进行认证。或者他们可能会直接点击微信内的链接,进入内置浏览器,并通过 snsapi_base 进行无感知认证。

Scope 选择:数据获取 vs. 用户摩擦

scope_comparison.png

您请求的 Scope 决定了您收集的数据以及访客体验到的摩擦。这是一个涉及合规性影响的实际决策点。

snsapi_base 仅返回 OpenID——即该用户在您公众号内的唯一标识符。它不需要用户同意授权提示。身份验证对访客是无感知的。适用于您已拥有其个人资料的返店访客,或者在您优先考虑无摩擦接入的场景。在 GDPR 和 PIPL 数据最小化原则下,snsapi_base 更容易证明其合理性。

snsapi_userinfo 返回 OpenID 以及用户的昵称、头像、性别和城市。它需要一个明确的授权同意页面。适用于需要建立个人资料的首次访客注册,并配合您 Portal 页面上符合合规要求的授权同意层。

跨门店部署的 UnionID

OpenID 针对用户与特定公众号的组合是唯一的。一家拥有 20 家门店且每家门店都有自己公众号的酒店集团,对于同一位访客会看到 20 个不同的 OpenID。UnionID 解决了这个问题。它是一个单一标识符,代表同一开放平台账号下链接的所有公众号和应用中的用户。将您的公众号链接到您的开放平台账号,OAuth 响应中就会返回 UnionID。这是跨门店访客识别的基础。


实施指南

网络强制执行机制

获取 OAuth 令牌仅能证明身份,并不能打开网络。您必须向控制器发送信号以允许流量通过。

RADIUS 授权变更 (CoA)(在 RFC 3576 中定义)是推荐的企业级方法。OAuth 验证成功后,Portal 服务器向网络控制器发送 CoA 请求。控制器将设备从认证前 VLAN 移动到访客 VLAN。这适用于 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet。

MAC 认证绕过 (MAB) 将设备的 MAC 地址作为已授权客户端注册到 RADIUS 数据库中。控制器根据该 MAC 允许访问。MAB 较易实施,但并不可靠:现代 iOS 和 Android 设备默认会随机化 MAC 地址,从而在重新连接时中断会话关联。

Purple 的 Guest WiFi 平台可自动完成此转换。微信 OAuth 完成后,Purple 的云端覆盖网络向底层硬件发送相应的 CoA 或 MAB 信号,从而免去了手动配置 VLAN 的麻烦。

安全配置

以下三项配置是不容妥协的。

  1. 保护 AppSecret。 AppSecret 绝不能出现在客户端 JavaScript 中。它必须保留在您的服务器上。如果泄露,攻击者可以冒充您的应用程序并代表您调用微信 API。
  2. 实施 CSRF 防护。 生成一个加密随机的 state 值,将其存储在用户会话中,并在微信重定向返回时进行验证。这可以防止 RFC 6749 中定义的跨站请求伪造攻击。
  3. 注册所有重定向 URI 变体。 微信会根据您注册的域名验证重定向 URI。请注册您使用的每一个子域名和路径变体(包括暂存环境),以防止出现 40029 错误(无效的代码)。

应用内浏览器检测

微信的应用内浏览器会设置包含 MicroMessenger 的用户代理(user agent)字符串。您的 Captive Portal 必须检测此字符串并进行相应路由:应用内浏览器使用公众号流程,标准浏览器使用开放平台二维码流程。如果未能检测到该字符串,会导致体验中断或身份验证错误。

hotel_wechat_wifi.png


最佳实践与合规性

GDPR 合规性

如果您服务于欧洲访客或在欧洲运营,GDPR 适用于您通过微信 OAuth 收集的数据。您必须确定合规的处理依据——通常是征得同意或合法利益。在进行身份验证之前,您必须在 Captive Portal 上提供清晰的隐私声明。您必须响应主体访问请求和删除请求。有关详细的合规框架,请参阅 合规手册:GDPR 与访客 WiFi 数据隐私

PIPL 合规性

当您处理中国公民的个人数据时,中国《个人信息保护法》(PIPL)适用。与 GDPR 类似,PIPL 要求明确的目的限制、数据最小化以及书面的合法依据。在数据最小化原则下,snsapi_basesnsapi_userinfo 更容易证明其合理性。无论您收集什么数据,请在上线前记录您的法律依据和保存期限。

网络隔离

使用 VLAN 隔离将访客 WiFi 流量与您的企业网络隔离开来。通过微信验证的访客应接入专用的访客 VLAN,且仅能访问互联网——无法访问内部系统。这符合 PCI DSS 对持卡人数据环境隔离的要求以及一般的企业安全实践。有关隔离架构的更多信息,请参阅 带宽管理:2026年实用指南

备用身份验证

如果微信的 API 不可用,您的门户必须重定向到替代的登录方式。不要让访客面对空白屏幕。提供电子邮箱或短信的备用方案可确保连贯性。这对于 交通运输医疗保健 环境中的场所尤为重要,在这些环境中,网络连接是一项服务义务。


真实案例研究

酒店业:奢华酒店集团

伦敦的一家拥有 400 间客房的奢华酒店接待了大量来自中国大陆的宾客。他们原有的 Captive Portal 要求提供电子邮件地址和短信验证。中国手机号码经常无法收到来自欧洲运营商的短信,而且许多宾客的设备上没有配置本地电子邮箱。这导致 Portal 的流失率高达 60%。

该酒店在公众号平台注册了服务号,并在开放平台注册了网站应用。Portal 检测到 MicroMessenger 用户代理,并为应用内浏览器用户触发 snsapi_base——在不到三秒的时间内将他们连接,且无需授权提示页面。通过 Chrome 或 Safari 访问的宾客则会看到一个二维码。在后续入住时,系统会识别出相同的 OpenID,并对宾客进行静默免密认证。酒店的 CRM 系统会记录该宾客的再次到访,从而实现有针对性的入店前沟通。有关在酒店环境中部署 WiFi 的更多信息,请参阅 酒店行业

零售:购物中心分析

一家大型购物中心希望获取中国消费者的受众特征数据,以辅助招商组合和营销决策。他们需要了解客源城市、性别和到访频率。此时仅靠 snsapi_base 远远不够——他们需要 snsapi_userinfo。Portal 会请求完整的 userinfo 作用域。宾客会看到微信授权提示页面,并点击允许。该购物中心与 Purple 的 WiFi Analytics 集成的分析平台接收到了经过验证的受众特征数据流。在周六下午,40% 的 WiFi 用户来自特定区域。该数据直接决定了应该接洽哪些品牌来举办快闪活动。有关零售 WiFi 部署的更多信息,请参阅 零售行业


故障排查与风险规避

微信 OAuth Captive Portal 部署中最常见的五种故障模式如下:

重定向 URI 不匹配(错误码 40029)。 微信会根据已注册的域名验证重定向 URI。任何子域名、路径或协议的不匹配都会导致 code 交换失败。请注册所有变体,包括暂存(staging)环境。

AppSecret 泄露。 将 AppSecret 嵌入在客户端代码中是最严重的安全错误。请将所有 token 交换逻辑转移到服务器端。

缺少 CSRF 保护。 忽略 state 参数验证会使 Portal 易受跨站请求伪造攻击。请为每个会话生成一个加密的随机值,并在回调时进行验证。

应用内浏览器检测失败。 未能在用户代理中检测到 MicroMessenger 意味着应用内浏览器用户将被提供错误的 OAuth 流程,从而导致报错。

MAC地址随机化破坏MAB会话。 现代移动操作系统会随机化MAC地址。使用基于MAB强制执行的访客在重新连接时将丢失其会话。升级到RADIUS CoA以实现可靠的会话管理。有关安全WiFi配置的指导,请参阅 什么是安全WiFi:2026年企业基本指南


投资回报率(ROI)与业务影响

部署微信登录访客WiFi功能具有三个可衡量的影响。

提高身份验证率。 消除短信验证失败点和电子邮件输入要求,可以提高成功连接的中国访客比例。对于不支持微信的Captive Portal,60%的流失率是一个现实的基准线。

第一方数据质量。 经微信验证的个人资料包括一个经过验证的OpenID,并且通过 snsapi_userinfo,可以直接获取来自该社交平台的受众特征属性。这些数据可以注入分析平台,以推动定向营销,而无需依赖第三方Cookie。

减少支持开销。 无缝登录减少了前台和IT支持人员处理国际访客连接故障排除的呼叫量。

Purple在超过80,000个场所中运营,并在2024年处理了4.4亿次登录(Purple内部数据)。该平台已通过ISO 27001认证,符合GDPR和CCPA,并保持99.999%的在线率。对于 零售酒店餐饮 行业的场所,微信身份验证将网络从成本中心转变为可靠的第一方数据采集渠道。

關鍵定義

Captive Portal

攔截來自未驗證裝置的 HTTP 流量,並要求使用者在獲得網路存取權之前與其進行互動的網頁。

向顧客呈現 WeChat 登入選項的主要介面。Portal 伺服器託管此網頁並協調 OAuth 流程。

OAuth 2.0

一種業界標準的授權協定 (RFC 6749),允許第三方應用程式代表使用者獲得對 HTTP 服務的有限存取權。

WeChat 用於向 Portal 伺服器傳遞驗證 Token 且不洩露使用者憑證的底層協定。與 Microsoft Entra ID、Okta 和 Google Workspace 使用的協定相同。

OpenID

分配給特定 WeChat 使用者在特定公眾號下的唯一英數字元識別碼。

在 WiFi 分析資料庫中用作識別回訪顧客的主鍵。每個公眾號的 OpenID 皆不同——跨場所識別請使用 UnionID。

UnionID

代表同一個開放平台帳戶下連結的所有公眾號和應用程式中,該使用者的單一 WeChat 識別碼。

對於擁有多個場地、需要跨所有物業識別同一位顧客的酒店集團、零售連鎖店和體育場營運商而言至關重要。

RADIUS CoA (Change of Authorization)

RADIUS 協定 (RFC 3576) 的擴充功能,允許 RADIUS 伺服器動態變更作用中工作階段的授權屬性。

在成功進行 WeChat 登入後,將顧客裝置從隔離的驗證前 VLAN 移至作用中網際網路 VLAN 的安全方法。支援的設備包括 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet。

snsapi_base

一種 WeChat OAuth 權限範圍,僅傳回使用者的 OpenID,且不需要使用者確認同意。

推薦用於回訪顧客重新驗證的權限範圍。在 GDPR 和 PIPL 數據最小化原則下更容易進行合規說明。

snsapi_userinfo

一種 WeChat OAuth 權限範圍,會傳回使用者的 OpenID、暱稱、頭像、性別和城市,且需要明確的同意畫面。

用於首次顧客註冊,此時分析需要人口統計數據。在 GDPR 和 PIPL 規範下需要記錄合法依據。

PIPL (Personal Information Protection Law)

中國於 2021 年 11 月生效的全面數據隱私法規,旨在規範對位於中國境內之自然人個人資訊的處理。

當場地透過 WeChat OAuth 處理中國公民的數據時適用。需要明確的同意、目的限制、數據最小化和刪除機制。

AppSecret

WeChat 在應用程式註冊期間核發的機密密碼金鑰,用於驗證來自 Portal 伺服器的 API 呼叫。

必須僅儲存在伺服器端。在用戶端 JavaScript 中洩露會使攻擊者能夠冒充應用程式並惡意呼叫 WeChat API。

範例

倫敦一家擁有 400 間客房的奢華酒店,其來自中國大陸的房客在入口網頁(Portal)的流失率高達 60%。目前的入口網頁需要電子郵件和簡訊驗證。IT 總監需要在保持 GDPR 合規性和網路安全性的同時,導入 WeChat 驗證。

步驟 1:在 WeChat 公眾平台 (mp.weixin.qq.com) 註冊服務號,並在 WeChat 開放平台 (open.weixin.qq.com) 註冊網站應用。步驟 2:設定入口網頁以偵測 MicroMessenger 使用者代理(User Agent)字串。若偵測到,則觸發 snsapi_base OAuth 流程以進行無感驗證。若未偵測到,則顯示 QR Code 流程。步驟 3:在 WeChat 登入按鈕啟用前,於入口網頁加入符合 GDPR 規範的隱私權聲明和同意核取方塊。聲明必須載明:收集的數據(僅限 OpenID)、目的(顧客 WiFi 存取和回訪識別)以及保留期限。步驟 4:成功交換 OAuth Token 後,入口網頁伺服器會向 Cisco Meraki 控制器發送 RADIUS CoA 請求,將顧客裝置從驗證前 VLAN 移至隔離的顧客 VLAN。步驟 5:在顧客資料庫中將 OpenID 與裝置 MAC 位址建立關聯並儲存。在後續訪問中,回訪的 OpenID 將觸發無感重新驗證。

考官評語: 此方法正確解決了技術和合規性要求。使用 snsapi_base 符合 GDPR 的數據最小化原則,在消除簡訊驗證失敗點的同時降低了法律風險。RADIUS CoA 可確保安全、自動化的網路分割。同意核取方塊滿足了 GDPR 對於書面合法依據的要求。關鍵決策是選擇 snsapi_base 而非 snsapi_userinfo——在此使用案例中,酒店不需要人口統計數據,因此收集這些數據會帶來不必要的合規義務。

某購物中心希望透過顧客 WiFi 獲取中國遊客的性別和城市數據,以匯入其分析平台。他們目前在 HPE Aruba 硬體上運行的現有入口網頁使用的是 MAC 驗證旁路(MAC Authentication Bypass)。

步驟 1:在 WeChat 公眾平台註冊服務號。步驟 2:設定入口網頁使用 snsapi_userinfo 權限範圍以取得性別和城市。步驟 3:加入清晰的同意畫面,說明價值交換:提供免費 WiFi 以換取個人檔案數據的存取權。根據 GDPR 和 PIPL,此同意必須是明確且細緻的。步驟 4:驗證後,入口網頁伺服器會在 RADIUS 資料庫中註冊裝置的 MAC 位址。HPE Aruba 控制器透過 MAB 允許存取。步驟 5:在數據處理登記冊中記錄合法依據(同意)、目的(場地分析和行銷)以及保留期限(24 個月)。提供數據刪除機制。

考官評語: snsapi_userinfo 權限範圍能正確擷取所需的人口統計數據。然而,依賴 MAB 會帶來顯著的營運風險:iOS 14+ 和 Android 10+ 預設會隨機化 MAC 位址,這意味著顧客在重新連線時會失去已驗證的工作階段,並被迫重新驗證。購物中心應計劃遷移至 HPE Aruba 上的 RADIUS CoA 以解決此問題。PIPL 合規文件並非選配項目——無論場地位置為何,處理中國公民的數據皆為法律強制要求。

練習題

Q1. 您正在體育場部署 Captive Portal。您希望先前已驗證過的回訪季票持有者在後續訪問時自動連線,而看不到登入畫面。您應該為重新驗證流程實作哪種 WeChat OAuth 權限範圍?為什麼?

提示:考慮哪種權限範圍允許進行無感驗證,而無需在每次訪問時提示使用者同意。

查看標準答案

使用 snsapi_base。此權限範圍僅傳回使用者的 OpenID 且不需要同意提示,從而實現無感重新驗證。在首次訪問時,您將 OpenID 與球迷的個人檔案關聯並儲存。在後續訪問中,Portal 透過 snsapi_base 偵測回訪的 OpenID,確認比對成功,並發送 RADIUS CoA 以授予存取權限——這一切都無需球迷看到登入畫面。這也符合 GDPR 的數據最小化原則,因為您沒有收集超出驗證功能所需之外的額外數據。

Q2. 在測試期間,您的 Portal 成功重新導向至 WeChat,使用者授予了同意,且 WeChat 重新導向回您的 Portal。然而,Portal 伺服器記錄顯示 OAuth 錯誤 40029(無效的授權碼)。最可能的設定錯誤是什麼?您該如何解決?

提示:WeChat 會根據註冊清單嚴格驗證其發送授權碼的目的地。

查看標準答案

最可能的原因是重新導向 URI 不符。WeChat 會根據平台上註冊的授權網域,驗證 OAuth 請求中的重新導向 URI。如果 Portal 伺服器使用不同的子網域、不同的路徑,或使用 HTTP 而非 HTTPS,則授權碼交換將失敗並顯示錯誤 40029。解決方法:登入 WeChat 開發者平台,導覽至您的服務號或網站應用設定,並新增您使用的每個重新導向 URI 變體——包括測試環境子網域、不同路徑和 HTTPS 版本。確保 OAuth 請求中的 redirect_uri 參數與註冊的 URI 之一完全相符(包括 URL 編碼)。

Q3. 一位 IT 經經理建議將 WeChat AppSecret 嵌入到 Captive Portal 的前端 JavaScript 中,以直接從用戶端瀏覽器加速 Token 交換過程。為什麼您必須拒絕此提議?正確的架構是什麼?

提示:考慮在公開存取的程式碼中洩露密碼金鑰的安全影響。

查看標準答案

拒絕此提議。AppSecret 是一個機密密碼金鑰。將其嵌入用戶端 JavaScript 會將其暴露給任何檢視網頁原始碼或攔截網路流量的人。攻擊者可以擷取 AppSecret 並冒充應用程式,代表場地呼叫 WeChat API、存取使用者數據,並可能使整個公眾號面臨安全風險。正確的架構:用戶端 Portal 網頁從 WeChat 接收授權碼,並透過伺服器端 API 呼叫將其轉發給 Portal 伺服器。Portal 伺服器將 AppSecret 保存在安全的環境變數中,並與 WeChat API 進行 Token 交換。AppSecret 絕不能離開伺服器。

Q4. 一個在歐洲擁有 15 家物業的酒店集團希望建立一個統一的顧客個人檔案,以識別同一個中國房客何時入住不同的物業。每家物業都有自己的 WeChat 公眾號。他們應該使用哪種 WeChat 識別碼?需要進行什麼設定?

提示:OpenID 是特定於帳戶的。有另一個專為跨帳戶設計的識別碼。

查看標準答案

使用 UnionID。OpenID 會因公眾號而異,因此同一個顧客在 15 個帳戶中將擁有 15 個不同的 OpenID。UnionID 是一個穩定的識別碼,代表連結到同一個開放平台帳戶的所有公眾號和應用程式中的使用者。所需的設定:將所有 15 個公眾號連結到單個 WeChat 開放平台帳戶。連結後,當使用者授權至少一個連結的帳戶時,OAuth 回應中就會傳回 UnionID。在顧客 CRM 中將 UnionID 用作主鍵,以建立跨物業的個人檔案,並無論顧客訪問哪家物業都能識別回訪顧客。