您好,登錄后才能下訂單哦!
以前的開(kāi)發(fā)模式是以MVC為主,但是隨著互聯(lián)網(wǎng)行業(yè)快速的發(fā)展逐漸的演變成了前后端分離,若項(xiàng)目中需要做登錄的話,那么token成為前后端唯一的一個(gè)憑證。
token即標(biāo)志、記號(hào)的意思,在IT領(lǐng)域也叫作令牌。在計(jì)算機(jī)身份認(rèn)證中是令牌(臨時(shí))的意思,在詞法分析中是標(biāo)記的意思。一般作為邀請(qǐng)、登錄系統(tǒng)使用。
token其實(shí)說(shuō)的更通俗點(diǎn)可以叫暗號(hào),在一些數(shù)據(jù)傳輸之前,要先進(jìn)行暗號(hào)的核對(duì),不同的暗號(hào)被授權(quán)不同的數(shù)據(jù)操作。例如在USB1.1協(xié)議中定義了4類數(shù)據(jù)包:token包、data包、handshake包和special包。主機(jī)和USB設(shè)備之間連續(xù)數(shù)據(jù)的交換可以分為三個(gè)階段,第一個(gè)階段由主機(jī)發(fā)送token包,不同的token包內(nèi)容不一樣(暗號(hào)不一樣)可以告訴設(shè)備做不同的工作,第二個(gè)階段發(fā)送data包,第三個(gè)階段由設(shè)備返回一個(gè)handshake包。
在HTTP請(qǐng)求中使用承載令牌來(lái)訪問(wèn)OAuth 2.0受保護(hù)的資源。擁有承載令牌的任何一方(“承載方”)都可以使用它訪問(wèn)相關(guān)資源(無(wú)需證明擁有加密密鑰)。為了防止誤用,需要防止在存儲(chǔ)和傳輸中泄露承載令牌。
OAuth允許客戶端通過(guò)獲取訪問(wèn)令牌,它在“OAuth 2.0授權(quán)”中定義框架“[RFC6749]作為”表示訪問(wèn)的字符串而不是使用資源直接服務(wù)的憑證。
該令牌由服務(wù)端允許的情況下,由客戶端通過(guò)某種方式向服務(wù)端發(fā)出請(qǐng)求,由服務(wù)端向客戶端發(fā)出,客戶機(jī)使用訪問(wèn)令牌訪問(wèn)由資源服務(wù)器承載的受保護(hù)的資源。該規(guī)范描述了當(dāng)OAuth訪問(wèn)令牌是承載令牌時(shí),如何發(fā)出受保護(hù)的資源請(qǐng)求。
客戶端只需要擁有token可以以任何一種方法傳遞token,客戶端需要知道參數(shù)加密的密鑰,只需要存儲(chǔ)token即可。
OAuth為客戶端提供了一種方法來(lái)代表資源所有者訪問(wèn)受保護(hù)的資源。在一般情況下,客戶機(jī)在訪問(wèn)受保護(hù)的資源之前,必須首先從資源所有者獲得授權(quán),然后將授權(quán)交換為訪問(wèn)令牌。訪問(wèn)令牌表示授權(quán)授予授予的范圍、持續(xù)時(shí)間和其他屬性??蛻魴C(jī)通過(guò)向資源服務(wù)器顯示訪問(wèn)令牌來(lái)訪問(wèn)受保護(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頭字段的語(yǔ)法遵循[RFC2617]第2節(jié)中定義的基本方案的用法。注意,與Basic一樣,它不符合[RFC2617]第1.2節(jié)中定義的通用語(yǔ)法,但與正在為HTTP 1.1 [HTTP- auth]開(kāi)發(fā)的通用身份驗(yàn)證框架兼容,盡管它沒(méi)有遵循其中列出的反映現(xiàn)有部署的首選實(shí)踐。承載憑證的語(yǔ)法如下
b64toke = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"=" credentials = "Bearer" 1*SP b64token
客戶端應(yīng)該使用帶有承載HTTP授權(quán)方案的Authorization請(qǐng)求頭字段使用承載令牌發(fā)出經(jīng)過(guò)身份驗(yàn)證的請(qǐng)求。資源服務(wù)器必須支持此方法。
在Internet Engineering Task Force (IETF)的白皮書(shū)中介紹Bearer Token的使用方法,那么我們平時(shí)使用token的時(shí)候姿勢(shì)是否正確。應(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; });
照白皮書(shū)所說(shuō)這樣才是正確使用token的姿勢(shì)。小伙伴們平時(shí)你們使用token的時(shí)候是這樣的嗎?
那么除了前端有明確的使用規(guī)范,那么服務(wù)端又應(yīng)該怎樣有效的做好后端數(shù)據(jù)防護(hù)?在白皮書(shū)中同樣也有提到過(guò)。
根據(jù)OAuth 2.0動(dòng)態(tài)客戶端注冊(cè)協(xié)議該規(guī)范定義了向授權(quán)服務(wù)器動(dòng)態(tài)注冊(cè)O(shè)Auth 2.0客戶端的機(jī)制。注冊(cè)請(qǐng)求向授權(quán)服務(wù)器發(fā)送一組所需的客戶端元數(shù)據(jù)值(token)。結(jié)果的注冊(cè)響應(yīng)返回要在授權(quán)服務(wù)器上使用的客戶機(jī)標(biāo)識(shí)符和為客戶機(jī)注冊(cè)的客戶機(jī)元數(shù)據(jù)值。然后,客戶機(jī)可以使用此注冊(cè)信息使用OAuth 2.0協(xié)議與授權(quán)服務(wù)器通信。該規(guī)范還定義了一組通用客戶端元數(shù)據(jù)字段和值,供客戶端在注冊(cè)期間使用。
為了讓OAuth 2.0 [RFC6749]客戶機(jī)利用OAuth 2.0授權(quán)服務(wù)器,客戶機(jī)需要與服務(wù)器交互的特定信息,包括在該服務(wù)器上使用的OAuth 2.0客戶端標(biāo)識(shí)符。該規(guī)范描述了如何通過(guò)授權(quán)服務(wù)器動(dòng)態(tài)注冊(cè)O(shè)Auth 2.0客戶端來(lái)獲取此信息。
抽象的動(dòng)態(tài)客戶端注冊(cè)流程
+--------(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ī)動(dòng)態(tài)注冊(cè)流描述了客戶機(jī)或開(kāi)發(fā)人員與此規(guī)范中定義的端點(diǎn)之間的交互。此圖沒(méi)有顯示錯(cuò)誤條件。這個(gè)流程包括以下步驟
授權(quán)類型與響應(yīng)類型之間的關(guān)系
描述的grant類型和響應(yīng)類型值是部分正交的,因?yàn)樗鼈円脗鬟f到OAuth協(xié)議中不同端點(diǎn)的參數(shù)。但是,它們是相關(guān)的,因?yàn)榭蛻魴C(jī)可用的grant類型影響客戶機(jī)可以使用的響應(yīng)類型,反之亦然。例如,包含授權(quán)代碼的授權(quán)類型值意味著包含代碼的響應(yīng)類型值,因?yàn)檫@兩個(gè)值都定義為OAuth 2.0授權(quán)代碼授權(quán)的一部分。因此,支持這些字段的服務(wù)器應(yīng)該采取步驟,以確??蛻魴C(jī)不能將自己注冊(cè)到不一致的狀態(tài),例如,通過(guò)向不一致的注冊(cè)請(qǐng)求返回?zé)o效的客戶機(jī)元數(shù)據(jù)錯(cuò)誤響應(yīng)。
下表列出了這兩個(gè)字段之間的相關(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ā)送任何人類可讀的字段時(shí)沒(méi)有使用語(yǔ)言標(biāo)記,那么使用該字段的各方不能對(duì)字符串值的語(yǔ)言、字符集或腳本做出任何假設(shè),而且字符串值必須按照在用戶界面中顯示的位置使用。為了促進(jìn)互操作性,建議客戶端和服務(wù)器除了使用任何特定于語(yǔ)言的字段外,還使用不使用任何語(yǔ)言標(biāo)記的人可讀字段,并且建議發(fā)送的任何不使用語(yǔ)言標(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)行了非對(duì)稱簽名。并等到如下加密字符串。
eyJhbGciOiJSUzI1NiJ9. eyJzb2Z0d2FyZV9pZCI6IjROUkIxLTBYWkFCWkk5RTYtNVNNM1IiLCJjbGll bnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVudCIsImNs aWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ. GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0 5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA
加密字符串由頭,載荷以及密鑰通過(guò)一系列的速算法生成,加密字符串與頭,載荷以及密鑰息息相關(guān),一但加密字符串稍有改動(dòng),則無(wú)法解析正確解析無(wú)法通過(guò)驗(yàn)證。
通過(guò)加密字符串向授權(quán)服務(wù)器注冊(cè)客戶端。授權(quán)服務(wù)器為該客戶端分配一個(gè)惟一的客戶端標(biāo)識(shí)符,可選地分配一個(gè)客戶端機(jī)密,并將請(qǐng)求中提供的元數(shù)據(jù)與已發(fā)布的客戶端標(biāo)識(shí)符關(guān)聯(lián)起來(lái)。該請(qǐng)求包括在注冊(cè)期間為客戶端指定的任何客戶端元數(shù)據(jù)參數(shù)。授權(quán)服務(wù)器可以為客戶端元數(shù)據(jù)中遺漏的任何項(xiàng)提供默認(rèn)值。
注冊(cè)端點(diǎn),內(nèi)容類型為application/json。該HTTP Entity Payload是一個(gè)由JSON組成的JSON文檔對(duì)象和所有請(qǐng)求的客戶端元數(shù)據(jù)值作為頂級(jí)成員那個(gè)JSON對(duì)象。
示例:
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 // 過(guò)期時(shí)間 },secret); ctx.body = {code:200,token}; } else{ ctx.status = 401; ctx.body = {code:0,message: "用戶名密碼錯(cuò)誤"}; } }); 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);
因?yàn)樽詈笊傻膖oken是通過(guò)base64加密的,有些內(nèi)容是可以反解的,所以千萬(wàn)不要在數(shù)據(jù)里面添加有關(guān)數(shù)據(jù)的敏感信息。注意注意。。。
以上就是本文的全部?jī)?nèi)容,希望對(duì)大家的學(xué)習(xí)有所幫助,也希望大家多多支持億速云。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。