對於微信而言， 小程式算是第三方了， 那麼， 小程式是如何登入的呢？ 微信肯定不能把密碼給小程式， 讓小程式來登入啊， 小程式甚至無法獲取微信的微訊號。 在這裡， 我們需要徹底把微信和小程式分開， 割裂來看， 才好理解。

        那小程式是怎樣來登入的呢？ 這就涉及到微信開放平臺了。我們知道， 很多網站支援QQ登入， 支援微博登入， 也支援微信登入。 這種借賬號體系的行為， 我們早就討論過， 無需贅述。 我們知道， 每個用微信的人， 都一個微訊號， 那麼從微信中進入小程式， 就需要一個什麼號來標識這個小程式， 這就是openID,  對於同一個小程式而言， 不同使用者的openID是不一致的， 這在oAuth協議中有介紹。

        下面， 我們來看看小程式的登入過程。

        小程式呼叫wx.login函式， 獲取與這個使用者對應的code(js_code),  然後把這code帶給小程式後臺， 於是乎小程式後臺就拿到了區別於使用者的code, 這實際上是微信給小程式的一個登入態標誌， 有點像token/session, 其實不是像， 而是是。 雖然每個使用者的code不一樣， 但當然不能以這個作為區分每個使用者的標誌啊， 因為code會變化（過期）， 所以思來想去， 還是用與微訊號有一一對應關係的openID更為靠譜。

         來一起看看微信公眾平臺的介紹：

wx.login(OBJECT)

呼叫介面獲取登入憑證（code）進而換取使用者登入態資訊，包括使用者的唯一標識（openid） 及本次登入的 會話金鑰（session_key）等。使用者資料的加解密通訊需要依賴會話金鑰完成。

注：呼叫 login 會引起登入態的重新整理，之前的 sessionKey 可能會失效。

OBJECT引數說明：

success返回引數說明：

示例程式碼：

//app.js
App({
  onLaunch: function() {
    wx.login({
      success: function(res) {
        if (res.code) {
          //發起網路請求
          wx.request({
            url: 'https://test.com/onLogin',
            data: {
              code: res.code
            }
          })
        } else {
          console.log('獲取使用者登入態失敗！' + res.errMsg)
        }
      }
    });
  }
})

code 換取 session_key

​這是一個 HTTPS 介面，開發者伺服器使用登入憑證 code 獲取 session_key 和 openid。

session_key 是對使用者資料進行加密簽名的金鑰。為了自身應用安全，session_key 不應該在網路上傳輸。

介面地址：

https://api.weixin.qq.com/sns/jscode2session?appid=APPID&secret=SECRET&js_code=JSCODE&grant_type=authorization_code

請求引數：

返回引數：

返回說明：

//正常返回的JSON資料包
{
      "openid": "OPENID",
      "session_key": "SESSIONKEY",
      "unionid": "UNIONID"
}
//錯誤時返回JSON資料包(示例為Code無效)
{
    "errcode": 40029,
    "errmsg": "invalid code"
}

wx.checkSession(OBJECT)

通過上述介面獲得的使用者登入態擁有一定的時效性。使用者越久未使用小程式，使用者登入態越有可能失效。反之如果使用者一直在使用小程式，則使用者登入態一直保持有效。具體時效邏輯由微信維護，對開發者透明。開發者只需要呼叫wx.checkSession介面檢測當前使用者登入態是否有效。登入態過期後開發者可以再呼叫wx.login獲取新的使用者登入態。

OBJECT引數說明：

示例程式碼：

wx.checkSession({
  success: function(){
    //session 未過期，並且在本生命週期一直有效
  },
  fail: function(){
    //登入態過期
    wx.login() //重新登入
    ....
  }
})

登入態維護

通過 wx.login 獲取到使用者登入態之後，需要維護登入態。

開發者要注意不應該直接把 session_key、openid 等欄位作為使用者的標識或者 session 的標識，而應該自己派發一個 session 登入態（請參考登入時序圖）。對於開發者自己生成的 session，應該保證其安全性且不應該設定較長的過期時間。session 派發到小程式客戶端之後，可將其儲存在 storage ，用於後續通訊使用。

通過 wx.checkSession 可以檢測使用者登入態是否失效。並決定是否呼叫 wx.login 重新獲取登入態

登入時序圖

        值得注意的是， code可以認為是微信給小程式的一個登入態票據， 而3rd_session則是小程式後臺給小程式的登入態票據。 在後續的會話中， 真正的主角是小程式和小程式後臺， 所有的業務邏輯應該圍繞小程式和小程式後臺展開，微信和微信後臺退居幕後（只能提供了開放登入介面的能力、和基礎的api功能而已）

        在後續的讀寫訪問中， 3rd_session作為登入態票據， 來訪問小程式後臺， 執行對應的動作。 小程式後臺則要進行登入態校驗。

        其實， 很簡單。