【登陸與令牌】小程序用戶怎麼拿到token的？

一般來講 獲取令牌token 的邏輯以下：

客戶端拿着帳號和密碼，向服務器兌換token令牌，用於後續系列操做。

---

如下是一個簡單的權限驗證模型：

服務器要作三件事：
1.驗證客戶端有token，便是否合法；
2.驗證token是否過時，便是否有效；
3.Token是否有對應的（訪問下單接口的）權限。

---

以小程序客戶端爲例：

小程序爲每一個用戶分配一個Code碼，用戶登陸小程序便可獲取，我的服務器獲取到用戶的Code，拿着Code以及appid和secret等信息向小程序服務器 換取 用戶的openid和session_key（這裏咱們不關心session_key，它是用於解密獲取userid的）。啥，爲啥不關心？那仍是解釋下userid和openid的不一樣吧，同一個用戶對於不一樣的小程序有不一樣的openid，可是userid卻始終相同，因此userid能夠用於關聯兩個小程序，通常狀況下不會被使用。
openid對於用戶來講是惟一標識且沒有失效期，因此不適合返回客戶端，很不安全的。所以生成有保質期的Token令牌，爲了減輕數據庫的壓力（不然頻繁驗證令牌合法，一直讀取查詢數據庫吃不消的），將Token和用戶信息存儲在緩存中，能夠加快訪問速度；可是有得有失，緩存的使用與數據庫相比會更加麻煩。

小程序攜帶令牌，在緩存中校驗Token，若可以經過，服務器返回小程序端想要的接口。
至於怎麼校驗，包括服務器怎麼獲取到code而且生成token和用戶信息綁定的，下次揭曉 (^▽^)