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

執行摘要

當中國訪客連線到您的企業網路，並遇到僅提供電子郵件、Facebook 或優惠券代碼的 Captive Portal 時，您會立即引入阻礙。根據騰訊 2024 年的數據，WeChat 擁有 13.8 億月活躍用戶。整合支援 WeChat 登入的顧客 WiFi 功能並非僅是餐旅業的便利之舉，而是無阻礙獲取該客群第一方數據的技術要求。

本指南詳細介紹了將 WeChat OAuth 2.0 驗證整合至 Captive Portals 的技術架構。其中解釋了支援標準行動瀏覽器和 WeChat 內建瀏覽器所需的雙平台註冊，評估了用於數據收集的 snsapi_base 與 snsapi_userinfo 權限範圍之間的折衷方案，並概述了如何使用 RADIUS Change of Authorization (CoA) 或 MAC 驗證旁路來強制執行網路存取。此外，它還涵蓋了在 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 基礎架構中大規模部署此功能所需的安全性設定和合規指令（GDPR 和中國的 PIPL）。

技術深挖：WeChat OAuth 2.0 架構

Captive Portal 攔截來自未驗證裝置的 HTTP 流量，並將其重新導向至託管在 Portal 伺服器上的登入頁面。加入 WeChat 驗證是使用 OAuth 2.0 協定（與 Google、Microsoft Entra ID 和 Okta 用於同盟身分識別的標準相同）在此流程中插入第三方身分識別提供者。

驗證順序如下。顧客連線到 SSID。存取點或無線控制器偵測到未驗證的工作階段，並將 HTTP 流量重新導向至 Captive Portal URL。顧客在 Portal 網頁上選擇 WeChat 登入。Portal 伺服器將瀏覽器重新導向至位於 open.weixin.qq.com 的 WeChat 授權端點，並傳遞 AppID、重新導向 URI、回應類型 code 以及請求的權限範圍。WeChat 在其自己的伺服器上處理驗證。如果顧客使用帶有 snsapi_base 權限範圍的 WeChat 內建瀏覽器，則驗證是無感的——不會出現同意提示。如果使用 snsapi_userinfo，WeChat 會呈現同意畫面。然後，WeChat 會帶著臨時授權碼重新導向回 Portal 的重新導向 URI。Portal 伺服器透過呼叫 api.weixin.qq.com/sns/oauth2/access_token 來交換此授權碼以取得 Access Token，並傳遞 AppID、AppSecret、授權碼和 authorization_code 的授權類型。WeChat 會傳回 Access Token、Refresh Token、使用者的 OpenID 以及授予的權限範圍。如果授予了 snsapi_userinfo，伺服器會進行第二次 API 呼叫以取得使用者的暱稱、頭像、性別和城市。

雙平台註冊要求

大多數實作在註冊階段失敗。WeChat 營運兩個獨立的開發者平台，企業部署通常兩者都需要。

對於在 WeChat 內建瀏覽器中存取 Portal 的顧客，您需要在公眾平台上註冊服務號。訂閱號將無法運作——它缺乏 OAuth 網頁授權權限。對於從 Android 上的 Chrome 或 iOS 上的 Safari 存取 Portal 的顧客，您需要在開放平台上註冊網站應用，該應用使用 snsapi_login 權限範圍並呈現一個 QR Code 供使用者掃描。

在實務中，大多數場地部署兩者都會使用。酒店的顧客可能會在 Chrome 中開啟 Portal，看到 QR Code，用 WeChat 掃描並進行驗證。或者他們可能會點擊 WeChat 本身中的連結，進入內建瀏覽器，並使用 snsapi_base 進行無感驗證。

權限範圍選擇：數據獲取 vs. 阻礙

您請求的權限範圍決定了您收集哪些數據以及顧客體驗到的阻礙。這是一個具有合規性影響的真正決策點。

snsapi_base 僅傳回 OpenID——該使用者在您公眾號內的唯一識別碼。它不需要使用者同意提示。驗證對顧客而言是無感的。當您已擁有回訪顧客的個人檔案，或當您優先考慮無阻礙存取時，請使用此選項。在 GDPR 和 PIPL 數據最小化原則下， snsapi_base 更容易進行合規說明。

snsapi_userinfo 傳回 OpenID 以及使用者的暱稱、個人頭像、性別和城市。它需要一個明確的同意畫面。對於您需要建立個人檔案的首次顧客註冊，請使用此選項，並在您的 Portal 網頁上搭配符合規範的同意層。

用於多物業部署的 UnionID

OpenID 對於使用者和特定公眾號的組合是唯一的。一個擁有 20 家物業且每家物業都有自己公眾號的酒店集團，將會看到同一個顧客的 20 個不同 OpenID。UnionID 解決了這個問題。它是一個單一識別碼，代表連結到同一個開放平台帳戶的所有公眾號和應用程式中的使用者。將您的公眾號連結到您的開放平台帳戶，UnionID 就會包含在 OAuth 回應中傳回。這是建立 cross-property 訪客識別。

實作指南

網路強制執行機制

取得 OAuth 權杖可證明身分，但並不會開啟網路。您必須向控制器發送訊號以允許流量。

RADIUS 授權變更 (CoA)（定義於 RFC 3576）是推薦的企業級方法。在成功進行 OAuth 後，入口網站伺服器會向網路控制器發送 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）字串。您的入口網站必須偵測此字串並進行相應的路由：應用程式內瀏覽器使用公眾號流程，標準瀏覽器則使用開放平台 QR code 流程。若未能偵測到此字串，將會導致體驗中斷或驗證錯誤。

最佳實踐與合規性

GDPR 合規性

如果您服務歐洲訪客或在歐洲營運，GDPR 適用於您透過微信 OAuth 收集的資料。您必須建立合法的處理依據——通常是同意或合法權益。在進行驗證之前，您必須在 Captive Portal 上提供清晰的隱私權聲明。您必須尊重當事人存取請求和刪除請求。如需詳細的合規架構，請參閱 合規指南：GDPR 與 Guest WiFi 資料隱私 。

PIPL 合規性

當您處理中國公民的個人資料時，適用中國的《個人信息保護法》（PIPL）。與 GDPR 類似，PIPL 要求明確的目的限制、資料最小化以及有記錄的合法依據。snsapi_base 在資料最小化原則下比 snsapi_userinfo 更容易證明其合理性。無論您收集什麼，請在正式上線前記錄您的法律依據和保留期限。

網路分段

使用 VLAN 分段將訪客 WiFi 流量與您的企業網路隔離。透過微信驗證的訪客應進入專用的訪客 VLAN，且僅能存取網際網路——無法存取內部系統。這符合 PCI DSS 對持卡人資料環境隔離的要求以及一般的企業安全實踐。如需了解更多關於分段架構的資訊，請參閱 頻寬管理：2026 年實用指南 。

備用驗證

如果微信的 API 無法使用，您的入口網站必須重新導向至替代的登入方法。不要讓訪客面對空白畫面。備用到電子郵件或簡訊可確保連線不中斷。這對於 交通運輸 和 醫療保健 環境中的場所尤為重要，因為在這些環境中，網路連線是一項服務義務。

實際案例研究

款待業：奢華酒店集團

倫敦一家擁有 400 間客房的奢華酒店服務了很大比例來自中國大陸的旅客。他們現有的 Captive Portal 需要電子郵件地址和簡訊驗證。中國的手機號碼經常無法接收來自歐洲電信商的簡訊，且許多旅客的裝置上並未設定當地的電子郵件。這導致入口網站的流失率高達 60%。

該酒店在公眾平台註冊了服務號，並在開放平台註冊了網站應用程式。入口網站會偵測 MicroMessenger 使用者代理，並為應用程式內瀏覽器使用者觸發 snsapi_base——在不到三秒的時間內將他們連線，且無需彈出同意畫面。透過 Chrome 或 Safari 瀏覽器存取的訪客則會看到一個 QR code。在隨後的入住中，系統會識別出相同的 OpenID，並自動為訪客重新進行驗證。酒店的 CRM 會記錄回訪，從而實現有針對性的抵達前溝通。如需了解更多關於在款待業環境中部署 WiFi 的資訊，請參閱 款待業 。

零售業：購物中心數據分析

一家大型購物中心希望收集中國消費者的客群特徵數據，以作為招商組合和行銷決策的參考。他們需要出發城市、性別和到訪頻率。僅靠 snsapi_base 是不夠的——他們需要 snsapi_userinfo。入口網站會請求完整的 userinfo 權限範圍。訪客會看到微信同意畫面並點擊「允許」。該購物中心的分析平台與 Purple 的 WiFi Analytics 整合，可接收經過驗證的客群特徵數據串流。在週六下午，有 40% 的 WiFi 使用者來自特定地區。這些數據直接y 有助於了解應接觸哪些品牌以舉辦快閃活動。若要了解更多關於零售 WiFi 部署的資訊，請參閱 零售 。

疑難排解與風險緩釋

在 WeChat OAuth Captive Portal 部署中，最常見的五種失敗模式如下。

重新導向 URI 不符（錯誤 40029）。 WeChat 會根據已註冊的網域驗證重新導向 URI。任何子網域、路徑或協定不符都會導致代碼交換失敗。請註冊所有變體，包括預備環境。

AppSecret 外洩。 將 AppSecret 嵌入用戶端程式碼是最嚴重的單一安全性錯誤。請將所有權杖（token）交換邏輯移至伺服器端。

缺少 CSRF 保護。 遺漏 state 參數驗證會使 Portal 易受跨網站請求偽造（CSRF）攻擊。請為每個工作階段（session）產生一個加密隨機值，並在回呼（callback）時進行驗證。

應用程式內瀏覽器偵測失敗。 未能在使用者代理（user agent）中偵測到 MicroMessenger，意味著使用應用程式內瀏覽器的使用者將被引導至錯誤的 OAuth 流程，進而產生錯誤。

MAC 位址隨機化破壞 MAB 工作階段。 現代行動作業系統會隨機化 MAC 位址。使用基於 MAB 強制執行的訪客在重新連線時將遺失其工作階段。請升級至 RADIUS CoA 以獲得可靠的工作階段管理。如需安全 WiFi 設定指引，請參閱 什麼是安全 WiFi：2026 年企業必備指南 。

投資報酬率（ROI）與業務影響

部署 WeChat 登入訪客 WiFi 功能具有三個可衡量的影響。

提高驗證率。 消除簡訊驗證失敗點和電子郵件輸入要求，可提高中國訪客成功連線的比例。對於不支援 WeChat 的 Portal，60% 的流失率是一個真實的基準。

第一方數據品質。 經 WeChat 驗證的個人檔案包含已驗證的 OpenID，且透過 snsapi_userinfo，可直接獲取來自社群平台的客群屬性。這些數據會匯入分析平台，以推動精準行銷，而無需依賴第三方 Cookie。

降低支援成本。 無縫登入可減少國際訪客因排解連線問題而撥打給前台和 IT 支援的電話。

Purple 在全球超過 80,000 個場域營運，並在 2024 年處理了 4.4 億次登入（Purple 內部數據）。該平台已通過 ISO 27001 認證，符合 GDPR 和 CCPA 規範，並維持 99.999% 的可用性。對於 零售 和 旅宿餐飲 領域的場域，WeChat 驗證將網路從成本中心轉變為可靠的第一方數據獲取管道。