基於SPA的網頁受權流程(微信OAuth2)

先說傳統MVC網站的網頁受權流程。

1.用戶發起了某個須要登陸執行的操做

2.收集AppId等信息重定向到微信服務器

3.微信服務器回調到網站某個Controller的Action

4.在此Action下經過獲得的code請求獲得access_token，並用a_t進一步獲取用戶信息，至此受權流程完成，能夠保存用戶信息到數據庫和cookie，重定向回原頁面

SPA架構下的問題

1.服務端與前端之間不保證可信，須要認證交互

2.使用WebApi交互，沒法在服務端控制前端的頁面跳轉

3.認證過程當中有安全級別較高的數據(access_token)，不該該暴露在客戶端，直接致使認證流程必須前端與WebApi配合完成

做者：Yitimo
連接：https://www.jianshu.com/p/27b8069b4178
來源：簡書
簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。

 

這裏給出一張基於ng2的先後端分離的SPA的交互流程圖，只須要關心右下部分須要用戶數據但localStorage中沒有(也就是說用戶未登陸)的狀況。

這裏給出了三條登陸方式，前兩種(QQ與微信的受權登陸)均是第三方平臺的OAuth2認證登陸方式，第三種是暫沒必要實現但早晚會加入的用戶註冊登陸方式，爲了支持多種方式(受權或註冊)，必須給出很通用可擴展的登陸流程。

來談微信受權的流程

1.第一步確定是發起受權，即引導用戶點擊url重定向到微信的api，通常的實現都是location.href直接重定向。

注意：第一步完成後實際上用戶瀏覽器已經丟失客戶端頁面了，頁面已經到了微信的受權頁面，這是微信的站點

2.當用戶點擊贊成受權後微信會生成一個code和state並請求咱們提供的redirect_uri，此uri必須是前端頁面。

傳統MVC網站下頁面的Action與WebApi概念沒必要區分的很清楚，給人的感受就是你寫了一個redirect_uri(好比/OAuth/Callback)，微信就傳參數到這個action，這個action處理完後一個重定向就回到原頁面結束了，代碼全都是服務端語言來實現。可是單頁應用下，服務器概念移除，這個回調頁面就得是某個前端頁面，而後在這個頁面裏處理微信傳來的參數。

3.微信回調到前端頁面獲得的參數只有一個發起時帶上的state(能夠用來定向回發起頁)和一個code(只能使用一次且很快過時)，因此如今必須用code來換取access_token，再用access_token換取實際用戶信息，這些事情顯而易見不該該由客戶端來完成。

4.客戶端用code請求WebApi，由WebApi進行後續的access_token與用戶信息獲取操做。

受權的發起須要的參數僅爲AppId，不須要AppSecret，因此此操做由客戶端進行徹底沒問題，可是獲得code後的後續請求的數據安全係數很高，因此必定要由安全的服務器來實現，也就是WebApi。

5.具體的流程視需求而定，總而言之假設WebApi如今經過code已經完成了用戶信息的獲取與保存，那就將必要的登陸信息返回給前端，前端再將其保存到localStorage便可。

6.後續再遇到須要登陸數據的業務時，先從localStorage獲取，這是正經常使用戶已登陸的場景(localStorage可能太過暴力，也能夠用sessionStorage)，一旦本地沒有了登陸數據，則回到步驟1從新發起受權，完美。

注意：登陸數據保存在客戶端是必須的事情，但必定不要保存重要敏感數據，客戶端的任何數據都應該視爲不可靠數據，只能作一些假設，假設只要提供給了WebApi特定的數據，就視此次請求爲合法請求，並儘可能增長請求僞造的門檻。

做者：Yitimo 連接：https://www.jianshu.com/p/27b8069b4178 來源：簡書 簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。