久久久亚洲欧洲日产国码vR,亚洲M码欧洲S码SSS222

參考：

從密碼到token，一個授權(quán)的故事
理解OAuth 2.0
小程序官方文檔
微信小程序之登錄態(tài)維護(十一)

微信的登陸認證方式跟Oauth的授權(quán)碼認證模式非常相似，接下來我大致講解Oauth的三種常用模式以及與微信登陸認證的關(guān)聯(lián)。

Oauth的三種常用模式

密碼模式

密碼模式的登陸方式大致如上，實際場景里，當(dāng)用戶在登陸掘金客戶端的時候，可以選擇github認證登陸，而不是直接賬號密碼登陸時。如果這個時候掘金客戶端允許用戶直接在上面輸入賬號密碼，那么客戶端在用戶點擊登陸時，將輸入的信息轉(zhuǎn)發(fā)至github授權(quán)服務(wù)器上請求授權(quán)登陸。如果github服務(wù)器授權(quán)通過，會返回成功登陸信息，同時我們也成功登陸客戶端。

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

對應(yīng)的登陸請求如下:

//客戶端直接帶上賬戶名、密碼訪問授權(quán)服務(wù)器
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

授權(quán)服務(wù)器返回的信息如下：

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認證方式，這種認證方式其實是用戶在客戶端直接錄入授權(quán)賬號和密碼，由客戶端直接發(fā)起對授權(quán)服務(wù)器的登陸認證，其中客戶端不允許保存密碼。

相對應(yīng)的，這種認證最大的缺點就是用戶賬號密碼全部記錄在客戶端的前端界面，通過請求傳輸給授權(quán)服務(wù)器，整個過程里密碼容易泄露，安全性差

簡化模式

接著，我們來看第二種認證模式。相比上面那種直接在客戶端輸入賬號密碼的方式，我們轉(zhuǎn)換下思路，在授權(quán)登陸的時候，客戶端帶上之前在授權(quán)服務(wù)器里注冊過的AppId、AppSecret和登陸成功后的重定向URI，直接訪問對應(yīng)的授權(quán)服務(wù)器。授權(quán)服務(wù)器接收請求，轉(zhuǎn)至登陸認證界面。

用戶在授權(quán)服務(wù)器的認證中心下進行賬號密碼的錄入，點擊登陸時，授權(quán)服務(wù)器通過AppId和App_Secret來識別客戶端，如果識別通過，將token通過hash fagment的形式附著在重定向地址上，返回給客戶端。

在整個過程里，客戶端都不接觸用戶名和密碼，只需要保存授權(quán)服務(wù)器返回的token，在后續(xù)的API請求里帶上token即可。

客戶端發(fā)起的請求如下：

//客戶端需要帶上注冊過的id、重定向地址，也可以帶上對應(yīng)的密鑰
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

授權(quán)服務(wù)器返回的信息：

//授權(quán)服務(wù)器的token通過#號隔開，直接附著在地址上
HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
          &state=xyz&token_type=example&expires_in=3600

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

授權(quán)碼模式

基于第二種模式里，token是直接通過URL地址返回給客戶端導(dǎo)致安全性差的問題，那么我們可以變通一下，在授權(quán)服務(wù)器重定向至客戶端時，不要直接帶上token，帶上某個特殊的授權(quán)碼code表示服務(wù)器已經(jīng)同意授權(quán)認證。

接著讓客戶端的服務(wù)器后臺發(fā)起請求，把客戶端在授權(quán)服務(wù)器里注冊過的AppId、AppSecret、接收的授權(quán)碼code帶上，由授權(quán)服務(wù)器通過Id和Secret密鑰對code進行解密驗證，如果驗證通過表示當(dāng)前請求的客戶端是正確的，接著再返回實際的token給客戶端即可。

客戶端第一次發(fā)起的請求：

//客戶端第一次發(fā)起請求，帶上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

授權(quán)服務(wù)器返回的信息：

//授權(quán)服務(wù)器登陸認證通過，返回對應(yīng)的授權(quán)碼code
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
          &state=xyz

客戶端第二次發(fā)起的請求：

//客戶端第二發(fā)起的請求，帶上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

授權(quán)服務(wù)器最終返回的信息：

//返回對應(yīng)的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"
}

授權(quán)碼認證模式里授權(quán)服務(wù)器不直接返回token，而是返回授權(quán)碼，由開發(fā)者服務(wù)器帶上相關(guān)信息后臺發(fā)送請求，授權(quán)服務(wù)器進行單獨的授權(quán)認證之后才返回token。通過兩次請求再返回token，保證了安全性。