在做專案整合微信登入以及微信支付的時候，都需要進行使用者授權。這個授權的流程可以簡單描述為： 
1. 使用者從我們的應用觸發需要授權的操作，比如點選微信登入； 
2. 應用收到這種使用者請求後，將使用者重定向到微信提供的一個授權頁面： 
或 
3. 使用者通過微信掃碼（PC端授權，上邊左圖）或者點選確認按鈕（移動端授權，上邊右圖）告知微信，授權應用訪問自己的微信賬號資訊； 
4. 微信收到使用者的授權許可後，生成授權碼，並把它作為引數回撥至應用的某個頁面； 
5. 應用的回撥頁面在接收到微信的回撥請求後，拿到其中的授權碼，並通過微信官方提供的access token api介面獲取access token； 
6. 最後通過access token以及微信官方提供的另一個userinfo api介面就能獲取到使用者的微信賬號資訊。

為了實現這個過程，首先要為應用申請一個微信公眾號，並將應用最終部署的域名設定到微信公眾號設定裡面的授權回撥頁面域名這個選項裡面。微信官方對這個選項的說明如下：

關於網頁授權回撥域名的說明

1、在微信公眾號請求使用者網頁授權之前，開發者需要先到公眾平臺官網中的“開發 - 介面許可權 - 網頁服務 - 網頁帳號 - 網頁授權獲取使用者基本資訊”的配置選項中，修改授權回撥域名。請注意，這裡填寫的是域名（是一個字串），而不是URL，因此請勿加 http:// 等協議頭；

2、授權回撥域名配置規範為全域名，比如需要網頁授權的域名為：www.qq.com，配置以後此域名下面的頁面http://www.qq.com/music.html 、 http://www.qq.com/login.html 都可以進行OAuth2.0鑑權。但http://pay.qq.com 、 http://music.qq.com 、 http://qq.com無法進行OAuth2.0鑑權

3、如果公眾號登入授權給了第三方開發者來進行管理，則不必做任何設定，由第三方代替公眾號實現網頁授權即可

由此可見，這個規則極其嚴格。如果說我們的應用最終部署的時候只有一個域名，那麼這種規則不會有什麼問題；但是考慮到將來應用的複雜性，我們可能在應用設計之初就會對應用做拆分，然後不同的業務採用不同的二級域名來部署。比如一個帶有交易的應用，你可能會把登入註冊，交易管理和常規業務都獨立出來，然後採用以下的方式來部署它們： 
www.your.com 部署常規業務； 
trade.your.com 部署交易管理的業務； 
passport.your.com 部署登入註冊的業務； 
在這種模式下，如果整合微信登入和微信支付，前面說的授權回撥頁面域名的規則就會給應用帶來問題。在這裡：至少可以確認trade.your.com和passport.your.com都需要前面的介紹的使用者微信授權，但是它們是兩個不同的子域名，而且我們只有一個公眾號；根據授權回撥頁面域名的原則，它只能用一個域名，並且只有回撥地址的域名與該設定完全相同，才能成功發起微信授權，否則就會提示rediret_uri引數錯誤或者引發無法回撥的問題。

那麼這種情況該如何處理？

當下的解決方案是引入一個新的非常簡單的應用來作為微信授權的代理服務，可以這麼做： 
1. 把公眾號的網頁授權介面域名設定成另外一個子域名，如proxy.your.com； 
2. 然後把php_weixin_proxy裡面的index.php部署到proxy.your.com

php_weixin_proxy下的index.php是一個很簡單的php檔案，你可以直接檢視原始碼瞭解它的實現方式。因為當前專案的環境，我採用php來完成這個代理服務實現，實際上，你完全可以用任意平臺語言來完成類似的功能。

當其它業務需要發起微信授權時，將授權請求先發到proxy.your.com，然後proxy.your.com會把這個請求轉發到微信； 
當用戶同意授權後，proxy.your.com會收到微信的授權回撥，並把回撥結果（code、state引數）原封不動地再返回給最開始發起授權的業務。

後面這個連結跟上面的比： 
1. 後面的連結中的host變成了proxy.your.com，也就是代理的授權回撥域名； 
2. 後面的多了一個device引數，這個是必要的。因為微信pc端跟移動端的授權地址是不一樣的，而後面的連結是傳送個proxy.your.com的，所以需要多加個引數告訴它在轉發給授權申請給微信的時候，是用PC端還是移動端的授權地址。

整體方案思路：

小結：

這個方案我測試過，是行的通的。雖然說引入了代理服務，增加了一次重定向操作，不過由於這個授權請求並不是所有請求都需要，所以實際上也不會對使用者體驗產生多大的影響，但是從架構上來說，它的好處很明顯，能夠配合著應用的拆分邏輯，整合同一個公眾號的登入及支付功能，不必為每個子應用都單獨申請一個公眾號來開發了（這種方式從業務上來說也不合理，一個公司哪需要運營那麼多公眾號）。