以前的開發(fā)模式是以MVC為主，但是隨著互聯(lián)網(wǎng)行業(yè)快速的發(fā)展逐漸的演變成了前后端分離，若項目中需要做登錄的話，那么token成為前后端唯一的一個憑證。

token即標(biāo)志、記號的意思，在IT領(lǐng)域也叫作令牌。在計算機(jī)身份認(rèn)證中是令牌（臨時）的意思，在詞法分析中是標(biāo)記的意思。一般作為邀請、登錄系統(tǒng)使用。

token其實說的更通俗點可以叫暗號，在一些數(shù)據(jù)傳輸之前，要先進(jìn)行暗號的核對，不同的暗號被授權(quán)不同的數(shù)據(jù)操作。例如在USB1.1協(xié)議中定義了4類數(shù)據(jù)包：token包、data包、handshake包和special包。主機(jī)和USB設(shè)備之間連續(xù)數(shù)據(jù)的交換可以分為三個階段，第一個階段由主機(jī)發(fā)送token包，不同的token包內(nèi)容不一樣（暗號不一樣）可以告訴設(shè)備做不同的工作，第二個階段發(fā)送data包，第三個階段由設(shè)備返回一個handshake包。

在HTTP請求中使用承載令牌來訪問OAuth 2.0受保護(hù)的資源。擁有承載令牌的任何一方(“承載方”)都可以使用它訪問相關(guān)資源(無需證明擁有加密密鑰)。為了防止誤用，需要防止在存儲和傳輸中泄露承載令牌。

OAuth允許客戶端通過獲取訪問令牌，它在“OAuth 2.0授權(quán)”中定義框架“[RFC6749]作為”表示訪問的字符串而不是使用資源直接服務(wù)的憑證。

該令牌由服務(wù)端允許的情況下，由客戶端通過某種方式向服務(wù)端發(fā)出請求，由服務(wù)端向客戶端發(fā)出，客戶機(jī)使用訪問令牌訪問由資源服務(wù)器承載的受保護(hù)的資源。該規(guī)范描述了當(dāng)OAuth訪問令牌是承載令牌時，如何發(fā)出受保護(hù)的資源請求。

客戶端只需要擁有token可以以任何一種方法傳遞token，客戶端需要知道參數(shù)加密的密鑰，只需要存儲token即可。

OAuth為客戶端提供了一種方法來代表資源所有者訪問受保護(hù)的資源。在一般情況下，客戶機(jī)在訪問受保護(hù)的資源之前，必須首先從資源所有者獲得授權(quán)，然后將授權(quán)交換為訪問令牌。訪問令牌表示授權(quán)授予授予的范圍、持續(xù)時間和其他屬性。客戶機(jī)通過向資源服務(wù)器顯示訪問令牌來訪問受保護(hù)的資源。在某些情況下，客戶端可以直接向服務(wù)端顯示的發(fā)送自己的憑證。

 +--------+                +---------------+ |    |--(A)- Authorization Request ->|  Resource  | |    |                |   Owner   | |    |<-(B)-- Authorization Grant ---|        | |    |                +---------------+ |    | |    |                +---------------+ |    |--(C)-- Authorization Grant -->| Authorization | | Client |                |   Server  | |    |<-(D)----- Access Token -------|        | |    |                +---------------+ |    | |    |                +---------------+ |    |--(E)----- Access Token ------>|  Resource  | |    |                |   Server  | |    |<-(F)--- Protected Resource ---|        | +--------+                +---------------+

此方案的Authorization頭字段的語法遵循[RFC2617]第2節(jié)中定義的基本方案的用法。注意，與Basic一樣，它不符合[RFC2617]第1.2節(jié)中定義的通用語法，但與正在為HTTP 1.1 [HTTP- auth]開發(fā)的通用身份驗證框架兼容，盡管它沒有遵循其中列出的反映現(xiàn)有部署的首選實踐。承載憑證的語法如下

b64toke = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"="credentials = "Bearer" 1*SP b64token

客戶端應(yīng)該使用帶有承載HTTP授權(quán)方案的Authorization請求頭字段使用承載令牌發(fā)出經(jīng)過身份驗證的請求。資源服務(wù)器必須支持此方法。

在Internet Engineering Task Force (IETF)的白皮書中介紹Bearer Token的使用方法，那么我們平時使用token的時候姿勢是否正確。應(yīng)該如何正確使用token呢？

import axios from "axios";axios.interceptors.request.use(config => { if (store.state.token) {  config.headers.authorization = `Basic ${store.state.token}`; } return config;});

照白皮書所說這樣才是正確使用token的姿勢。小伙伴們平時你們使用token的時候是這樣的嗎？

那么除了前端有明確的使用規(guī)范，那么服務(wù)端又應(yīng)該怎樣有效的做好后端數(shù)據(jù)防護(hù)？在白皮書中同樣也有提到過。

根據(jù)OAuth 2.0動態(tài)客戶端注冊協(xié)議該規(guī)范定義了向授權(quán)服務(wù)器動態(tài)注冊O(shè)Auth 2.0客戶端的機(jī)制。注冊請求向授權(quán)服務(wù)器發(fā)送一組所需的客戶端元數(shù)據(jù)值（token）。結(jié)果的注冊響應(yīng)返回要在授權(quán)服務(wù)器上使用的客戶機(jī)標(biāo)識符和為客戶機(jī)注冊的客戶機(jī)元數(shù)據(jù)值。然后，客戶機(jī)可以使用此注冊信息使用OAuth 2.0協(xié)議與授權(quán)服務(wù)器通信。該規(guī)范還定義了一組通用客戶端元數(shù)據(jù)字段和值，供客戶端在注冊期間使用。

為了讓OAuth 2.0 [RFC6749]客戶機(jī)利用OAuth 2.0授權(quán)服務(wù)器，客戶機(jī)需要與服務(wù)器交互的特定信息，包括在該服務(wù)器上使用的OAuth 2.0客戶端標(biāo)識符。該規(guī)范描述了如何通過授權(quán)服務(wù)器動態(tài)注冊O(shè)Auth 2.0客戶端來獲取此信息。

抽象的動態(tài)客戶端注冊流程

  +--------(A)- Initial Access Token (OPTIONAL)  |  |  +----(B)- Software Statement (OPTIONAL)  |  |  v  v+-----------+                   +---------------+|      |--(C)- Client Registration Request -->|  Client   || Client or |                   | Registration || Developer |<-(D)- Client Information Response ---|  Endpoint  ||      |    or Client Error Response   +---------------++-----------+

圖中所示的抽象OAuth 2.0客戶機(jī)動態(tài)注冊流描述了客戶機(jī)或開發(fā)人員與此規(guī)范中定義的端點之間的交互。此圖沒有顯示錯誤條件。這個流程包括以下步驟

1. 可選地，向客戶端或開發(fā)人員發(fā)出初始訪問令牌，允許訪問客戶端注冊端點。向客戶端或開發(fā)人員發(fā)出初始訪問令牌的方法超出了本規(guī)范的范圍。
2. 客戶端或開發(fā)人員可以選擇發(fā)布一個軟件聲明，以便與客戶端注冊端點一起使用。向客戶端或開發(fā)人員發(fā)出軟件聲明的方法超出了本規(guī)范的范圍。
3. 客戶端或開發(fā)人員使用客戶端所需的注冊元數(shù)據(jù)調(diào)用客戶端注冊端點，如果授權(quán)服務(wù)器需要初始訪問令牌，則可以選擇包含來自(A)的初始訪問令牌。
4. 授權(quán)服務(wù)器注冊客戶機(jī)并返回客戶端注冊的元數(shù)據(jù)， 在服務(wù)器上唯一的客戶端標(biāo)識符，以及一組客戶端憑據(jù)，如客戶端機(jī)密(如果適用于此客戶端)。

授權(quán)類型與響應(yīng)類型之間的關(guān)系

描述的grant類型和響應(yīng)類型值是部分正交的，因為它們引用傳遞到OAuth協(xié)議中不同端點的參數(shù)。但是，它們是相關(guān)的，因為客戶機(jī)可用的grant類型影響客戶機(jī)可以使用的響應(yīng)類型，反之亦然。例如，包含授權(quán)代碼的授權(quán)類型值意味著包含代碼的響應(yīng)類型值，因為這兩個值都定義為OAuth 2.0授權(quán)代碼授權(quán)的一部分。因此，支持這些字段的服務(wù)器應(yīng)該采取步驟，以確保客戶機(jī)不能將自己注冊到不一致的狀態(tài)，例如，通過向不一致的注冊請求返回?zé)o效的客戶機(jī)元數(shù)據(jù)錯誤響應(yīng)。

下表列出了這兩個字段之間的相關(guān)性。

+-----------------------------------------------+-------------------+| grant_types value includes:          | response_types  ||                        | value includes:  |+-----------------------------------------------+-------------------+| authorization_code              | code       || implicit                   | token       || password                   | (none)      || client_credentials              | (none)      || refresh_token                 | (none)      || urn:ietf:params:oauth:grant-type:jwt-bearer  | (none)      || urn:ietf:params:oauth:grant-type:saml2-bearer | (none)      |+-----------------------------------------------+-------------------+

向授予類型或響應(yīng)類型參數(shù)引入新值的此文檔的擴(kuò)展和概要文件必須記錄這兩種參數(shù)類型之間的所有通信。

如果發(fā)送任何人類可讀的字段時沒有使用語言標(biāo)記，那么使用該字段的各方不能對字符串值的語言、字符集或腳本做出任何假設(shè)，而且字符串值必須按照在用戶界面中顯示的位置使用。為了促進(jìn)互操作性，建議客戶端和服務(wù)器除了使用任何特定于語言的字段外，還使用不使用任何語言標(biāo)記的人可讀字段，并且建議發(fā)送的任何不使用語言標(biāo)記的人可讀字段包含適合在各種系統(tǒng)上顯示的值。

例如，軟件聲明可以包含以下聲明：

{ "software_id": "4NRB1-0XZABZI9E6-5SM3R", "client_name": "Example Statement-based Client", "client_uri": "https://client.example.net/"}

以下非標(biāo)準(zhǔn)示例JWT包括這些聲明，并且使用RS256(僅用于顯示目的)進(jìn)行了非對稱簽名。并等到如下加密字符串。

eyJhbGciOiJSUzI1NiJ9.eyJzb2Z0d2FyZV9pZCI6IjROUkIxLTBYWkFCWkk5RTYtNVNNM1IiLCJjbGllbnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVudCIsImNsaWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ.GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHazdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn05X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxYfHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxskU5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJfIjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA

加密字符串由頭，載荷以及密鑰通過一系列的速算法生成，加密字符串與頭，載荷以及密鑰息息相關(guān)，一但加密字符串稍有改動，則無法解析正確解析無法通過驗證。

通過加密字符串向授權(quán)服務(wù)器注冊客戶端。授權(quán)服務(wù)器為該客戶端分配一個惟一的客戶端標(biāo)識符，可選地分配一個客戶端機(jī)密，并將請求中提供的元數(shù)據(jù)與已發(fā)布的客戶端標(biāo)識符關(guān)聯(lián)起來。該請求包括在注冊期間為客戶端指定的任何客戶端元數(shù)據(jù)參數(shù)。授權(quán)服務(wù)器可以為客戶端元數(shù)據(jù)中遺漏的任何項提供默認(rèn)值。

注冊端點，內(nèi)容類型為application/json。該HTTP Entity Payload是一個由JSON組成的JSON文檔對象和所有請求的客戶端元數(shù)據(jù)值作為頂級成員那個JSON對象。

示例：

const Koa = require("koa");const Router = require("koa-router");const jwt = require("jsonwebtoken");const jwtAuth = require("koa-jwt");const secret = "it's a secret";   // 密鑰const app = new Koa();const router = new Router();router.get('/api/login',async (ctx) => {  const {username,passwd} = ctx.query;  if(username === "aaron" && passwd == "123456"){    const token = jwt.sign({      data:{name:"Aaron",userId:"1"},     // 用戶信息      exp:Math.floor(Date.now()/1000)+60*60  // 過期時間    },secret);    ctx.body = {code:200,token};  }  else{    ctx.status = 401;    ctx.body = {code:0,message: "用戶名密碼錯誤"};  }});router.get("/api/userinfo",jwtAuth({secret}),async (ctx) => {  // jwtAuth受保護(hù)路由  ctx.body = {code:200,data:{name:"Aaron",age:18}}});app.use(router.routes());app.listen(3000);

因為最后生成的token是通過base64加密的，有些內(nèi)容是可以反解的，所以千萬不要在數(shù)據(jù)里面添加有關(guān)數(shù)據(jù)的敏感信息。注意注意。。。

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持VeVb武林網(wǎng)。