- 鑑權方式
- 賬號+密碼
- 賬號+簡訊驗證碼
- 第三方渠道鑑權——微信
- Reference
本文只是一個Demo設計，僅供學習思路，並不能用於真實的線上業務，因為有很多漏洞。
一般線上應用都需要對使用者身份進行鑑權，透過身份校驗的使用者，都會得到一個access_token，這個憑證是全域性唯一介面呼叫憑據，呼叫應用的各介面時都需使用access_token，如果token校驗失敗，則表明無許可權訪問相關介面。
注：下文access_token 和 token 是一個東西。
注：使用者需要進行妥善儲存access_token。線上應用的客戶端一般會將token存放在前端的儲存空間———Cookie中。
access_token的一些安全要求：
- access_token的儲存至少要保留512個字元空間。
- access_token的有效期一般為2個小時，需定時重新整理，重複獲取將導致上次獲取的access_token失效。
那麼問題來了，線上應用是怎麼做身份鑑權的呢？
鑑權方式
常見的鑑權方式由如下三種：
- 賬號+密碼
- 賬號+簡訊驗證碼
- 第三方渠道——微信
賬號+密碼
這個很簡單，就是對比資料庫中的賬號密碼，一致就發放token。
賬號+簡訊驗證碼
這個流程相對多一些，需要先給使用者手機傳送一條簡訊，簡訊裡包含了一個六位的數字（稱作：簡訊驗證碼），使用者將驗證碼傳送到伺服器，伺服器判斷驗證碼一致就發放token。
第三方渠道鑑權——微信
本文主要講解這個，結合著加密方式做身份鑑權。
一般來說，每個微信使用者都會由一個微信ID——appid，
正常的流程，會把使用者的appid作為一個唯一標識進行儲存，做鑑權....
正常的流程是這樣，但是從安全形度來說，它不安全，並不能阻擋駭客的偽造，
比如說駭客偽造了很多appid，傳送到伺服器，伺服器並沒有能力鑑別誰是偽造的appid，那麼就會造成鑑權上的繞過。
當然，微信推出了一個服務，每次獲取 openid 引數時，呼叫微信公眾平臺的“獲取使用者基本資訊”的介面去鑑別這個openid是不是偽造的。不過這個方式，只能證明這個opendid是不是微信，並不能證明這個opendid是不是自己系統的，可以結合著另一種方式，用加密做鑑權。
呼叫流程：
-
加密做鑑權：前端（使用者）獲得了微信授權openid後，將openid傳輸給後端，
後端先呼叫 微信公眾平臺的“獲取使用者基本資訊”的介面去鑑別這個openid是不是偽造的，才能入庫。 -
後端把回撥給前端的 openid 進行加密，返回給前端。
-
前端呼叫 api 的時候，前端需要把授權得到的加密後的 openid 傳給後端，後端先做解密校驗操作，，如果解密操作失敗，則認定openid非法，拒絕此次請求，成功才繼續執行進行剩下的業務邏輯。
-
因為伺服器同時負責加密和解密，需要採用對稱加密演算法，金鑰安全的儲存在伺服器裡。
-
後期只要openid能解密成功，就意味著是自己系統加密的，只要金鑰不洩露，別人無法偽造。
呼叫流程圖演示：
如果你有耐心看到這裡，恭喜你能看到更遠的風景，
這個方案並沒有考慮完善，
比如，如果2個小時候後token失效，或者使用者本地的cookie丟失，那麼使用者怎麼才能再次才能獲取token呢？
答案是：這個方案獲取不了了，所有這個只是一個一次性系統。美麗的廢物。
但是本文是想討論一下，透過加密做鑑權的一些可能性。
當然，這個方案做不了，可以轉換一下思路，透過其它方式做，
比如，在前端裡面整合JS程式碼做簽名，然後後臺透過校驗簽名來確保請求是從自己的渠道發過來的。
Reference
https://www.cnblogs.com/xjnotxj/p/9289528.html