淺談微信小程序登錄與Oauth

參考：

1. 從密碼到token， 一個受權的故事
2. 理解OAuth 2.0
3. 小程序官方文檔
4. 微信小程序之登陸態維護(十一)

微信的登錄認證方式跟Oauth的受權碼認證模式很是類似，接下來我大體講解Oauth的三種經常使用模式以及與微信登錄認證的關聯。

Oauth的三種經常使用模式

密碼模式

  密碼模式的登錄方式大體如上，實際場景裏，當用戶在登錄掘金客戶端的時候，能夠選擇github認證登錄，而不是直接帳號密碼登錄時。若是這個時候掘金客戶端容許用戶直接在上面輸入帳號密碼，那麼客戶端在用戶點擊登錄時，將輸入的信息轉發至github受權服務器上請求受權登錄。若是github服務器受權經過，會返回成功登錄信息，同時咱們也成功登錄客戶端。

  另外在上面整個過程裏，掘金客戶端不容許保存用戶的密碼。

對應的登錄請求以下:

//客戶端直接帶上帳戶名、密碼訪問受權服務器
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=password&username=johndoe&password=A3ddj3w
複製代碼

受權服務器返回的信息以下：

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"example",
  "expires_in":3600,
  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
  "example_parameter":"example_value"
}
複製代碼

  這是第一種Oauth認證方式，這種認證方式實際上是用戶在客戶端直接錄入受權帳號和密碼，由客戶端直接發起對受權服務器的登錄認證，其中客戶端不容許保存密碼。

  相對應的，這種認證最大的缺點就是用戶帳號密碼所有記錄在客戶端的前端界面，經過請求傳輸給受權服務器，整個過程裏密碼容易泄露，安全性差

簡化模式

  接着，咱們來看第二種認證模式。相比上面那種直接在客戶端輸入帳號密碼的方式，咱們轉換下思路，在受權登錄的時候，客戶端帶上以前在受權服務器裏註冊過的AppId、AppSecret和登錄成功後的重定向URI，直接訪問對應的受權服務器。受權服務器接收請求，轉至登錄認證界面。

  用戶在受權服務器的認證中心下進行帳號密碼的錄入，點擊登錄時，受權服務器經過AppId和App_Secret來識別客戶端，若是識別經過，將token經過hash fagment的形式附着在重定向地址上，返回給客戶端。

  在整個過程裏，客戶端都不接觸用戶名和密碼，只須要保存受權服務器返回的token，在後續的API請求裏帶上token便可。

客戶端發起的請求以下：

//客戶端須要帶上註冊過的id、重定向地址，也能夠帶上對應的密鑰
GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
複製代碼

受權服務器返回的信息：

//受權服務器的token經過#號隔開，直接附着在地址上
HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
          &state=xyz&token_type=example&expires_in=3600
複製代碼

  這種方式最大的缺點是token經過重定向地址直接返回客戶端，安全性差，容易被人經過瀏覽器的歷史記錄或者訪問日誌裏竊取

受權碼模式

  基於第二種模式裏，token是直接經過URL地址返回給客戶端致使安全性差的問題，那麼咱們能夠變通一下，在受權服務器重定向至客戶端時，不要直接帶上token，帶上某個特殊的受權碼code表示服務器已經贊成受權認證。

  接着讓客戶端的服務器後臺發起請求，把客戶端在受權服務器裏註冊過的AppId、AppSecret、接收的受權碼code帶上，由受權服務器經過Id和Secret密鑰對code進行解密驗證，若是驗證經過表示當前請求的客戶端是正確的，接着再返回實際的token給客戶端便可。

客戶端第一次發起的請求：

//客戶端第一次發起請求，帶上id和重定向地址
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
複製代碼

受權服務器返回的信息：

//受權服務器登錄認證經過，返回對應的受權碼code
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
          &state=xyz
複製代碼

客戶端第二次發起的請求：

//客戶端第二發起的請求，帶上id、secret和重定向地址
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
複製代碼

受權服務器最終返回的信息：

//返回對應的token
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"example",
  "expires_in":3600,
  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
  "example_parameter":"example_value"
}
複製代碼

  受權碼認證模式裏受權服務器不直接返回token，而是返回受權碼，由開發者服務器帶上相關信息後臺發送請求，受權服務器進行單獨的受權認證以後才返回token。經過兩次請求再返回token，保證了安全性。

微信認證方式

微信的登錄認證方式，其實跟受權碼模式很類似，區別在於簡化了獲取受權碼code的過程，不須要帶上帳號密碼，調用wx.login就能夠從微信服務器上返回受權碼，而且整個過程不須要繁瑣地重定向，經過後臺請求就能夠獲取token。

這四種認證方式對應的關係以下圖所示：