那一年，我所在公司的使用者量達到了公司成立以來的新高峰，經過多個程式設計師日日夜夜加班，每個業務系統達到了幾乎四個9的穩定性，同時業務在業界也有了一定的知名度。那一天突然有一個合作商登門拜訪，提出合作共贏的意向。業務的場景就是我們的系統使用者能夠在他們系統登入，並能夠獲取使用者一定的資訊以便進行一些業務操作。

他們希望我們能夠把已存在的使用者資料Copy一份匯入他們的系統，並且新註冊的使用者進行單項同步更新。這不是蝦扯蛋嗎？.....

為了實現使用者資訊互通而達到業務要求，其實方案有很多。如果不是底線情況下，同步使用者資訊這種方案就是一個外行人，一個扯淡的方案。為什麼這麼說？首先說資訊同步這種方式，如果是單項同步，雙方所有相關人員的工作量已經非常之大，一定條件下單項同步升級為雙向資訊同步，雙方的程式設計人員將會苦不堪言。

另外撇開工作量，使用者的資訊本質上屬於使用者的私密資訊，一個使用者能夠把自己的隱私放心的儲存在你這裡，就說明了對公司的信任度。一旦發生使用者資訊複製的操作，本質上是對使用者的不負責任，道德上，法律上都有所欠缺。

作為一個技術人員，排除不合理方案，提供在業務可行情況下的技術方案是職責所在，那有沒有不用複製使用者資訊這麼low B的方案呢？假設我們所在公司的系統為A，業務的域名為www.A.com,第三方系統為B，業務域名為www.B.com

在第三方系統登入的入口，允許我方使用者輸入賬號密碼，然後第三方系統（客戶端或者服務端都可以）攜帶使用者輸入的賬號密碼請求我司登入伺服器，如果驗證通過則返回使用者相關資訊，第三方系統接收到返回資料，按照自己相關的登入流程進行登入，並且可以儲存使用者相關的資訊。請求的形式和大體的流程如下圖所示

說實話，我並不推薦這種方案，雖然它比直接複製使用者資訊要好一些，但是依然問題很大，使用者在無形中已經把賬號密碼或者其他登入憑證洩露給並不信任的第三方系統中，而這可能並非使用者想要的結果。

以上方案有一個致命的缺點，那就是登入頁面是使用者並不信任的第三方頁面，如果能避免這樣的危險，讓使用者在信任的我方登入，會大大增強使用者的信任度。技術方面在我方實現登入實在是容易，唯一需要考慮的是使用者登入成功之後如何把使用者資訊傳送給第三方系統。如果採用請求呼叫的方式（比如：登入成功，我方呼叫第三方一個介面），技術上可以實現，但是下次再來一個第三方申請這樣的業務，我方的呼叫介面可能會需要修改，所以現在業界比較好的也比較通用的方式是通過地址的跳轉來實現。具體流程如下：

1. 使用者在第三方點選登入，跳轉到我方提供的登入頁面，頁面URL中帶有登入成功跳轉的頁面地址，並在此頁面輸入賬號密碼。

2. 我方根據使用者賬號密碼判斷使用者正確性，登陸成功，獲取使用者資訊。

3. 然後跳轉到第三方提供的登入成功跳轉頁面，並把使用者資訊攜帶過去。

4. 第三方跳轉頁面接收到使用者資訊，處理剩餘業務，流程結束。

第一步中第三方跳轉到我方的登入頁面URL如下所示：

http://www.A.com/login?type=userinfo&redirecturi=http://www.B.com/callback

方案2中登入部分已經和方案1有了本質的區別，雖然僅僅是一個登入方的改變，安全性以及對使用者隱私的保護上卻有著大大的提升。但是流程中卻依然存在著主動傳輸使用者資訊，如果有人劫持的話，還是有使用者資訊洩露的風險。如何避免這樣的風險呢？

試想，能否利用其它憑據來代替使用者資訊呢？當然是可以，這也是現代Web系統實現授權的普遍方式。使用者資訊取而代之的是一個令牌，而且這個令牌有一定的時效性，只能維持一段時間內有效，這在一定程度上保護了系統資料。第三方系統獲取到這個令牌之後，每次獲取使用者資訊都會攜帶者這個令牌作為憑證，我方的系統同時也只認可這個令牌作為授權的憑證。

http://www.A.com/login?type=token&redirecturi=http://www.B.com/callback

方案3其實在很多時候已經足夠了，但是有一點需要注意，每個令牌有一定的有效時間，這是設計上的優勢，同時也意味著令牌如果被其他人獲取到，一樣可以竊取使用者資訊，由於在方案3中令牌的下發實際上還是通過前端（瀏覽器）來傳輸的，凡是在前端傳輸的情況下，就會有洩露的風險，那有沒有辦法避免在前端傳輸呢？

既然傳輸憑證不可避免，於是人們便想到了可以在前端（瀏覽器）傳輸一個只有一次有效的憑證，然後第三方後端依據這個憑證去獲取令牌，因為服務端的通訊要比前端（瀏覽器）的通訊要安全的多。於是方案4應運而生：

1. 使用者跳轉到我方登入頁面進行登入。

2. 我方驗證使用者使用者名稱密碼無誤，產生一個有效次數為1並且一定時間內有效的code，並攜帶著這個code跳轉到第三方的回撥頁面

3. 第三方回撥頁面，收到code引數，傳輸給後端程式。

4. 第三方後端程式收到code引數，攜帶著code呼叫我方介面

5. 我方驗證code有效性，如果有效則返回令牌資訊

6. 第三方收到令牌資訊，攜帶令牌資訊呼叫我方介面獲取使用者資訊

7. 我方驗證token有效性，如果有效則返回使用者資訊

8. 之後的每次呼叫都攜帶者token進行訪問，code就算被人獲取到已經不起作用

http://www.A.com/login?type=code&redirecturi=http://www.B.com/callback

方案4雖然看上去已經足夠好，但是並非完美。

1. 當第三方跳轉到我方登入頁面的時候，我方並不知道這個第三方是誰，是不是可信任的，所以有必要讓我方識別這個第三方是否可以信任。我方在授權第三方的時候可以給每一個第三方頒發一個類似於appid和appkey的資料，appid用來標識每一個我方授權的第三方，而且每一個appid必須註冊進行回撥的url。這樣當第三方跳轉到我方登入頁面的時候，我方就可以識別出來這個第三方以及回撥跳轉的url是否有效。

2. 當第三方攜帶者code去換取token，以及之後攜帶token去獲取使用者資訊的每次通訊，都應該按照我方規則利用appid和appkey進行簽名處理，這樣我方的伺服器端也能夠識別出來呼叫方是否是可信任的。

3. 在使用者登入授權的頁面，使用者可勾選自己授權給第三方的資料內容，這些許可權將作用於code以及令牌中。

4. 由於每個令牌都有失效時間，如何更新令牌則會是一個技術點，其實完全可以在下發令牌的同時也下發一個用於更新令牌的令牌，這個令牌隨著每次重新下發令牌而更新。

5. 我方使用者的資訊每次更新的時候，可以把相關的令牌失效，以達到讓第三方重新獲取使用者資訊而同步的效果

6. 我方登入頁面以及供第三方呼叫的所有介面都應該採用https協議，並要求所有的第三方回撥頁面必須也全部採用https，這能有效的仿製惡性劫持。

不知道菜菜把不清楚author2.0 授權的同學教會了沒有，如果還不清楚，請私信菜菜