Angular之jwt令牌身份驗(yàn)證

demo https://gitee.com/powersky/jwt

介紹

Json web token (JWT), 是為了在網(wǎng)絡(luò)應(yīng)用環(huán)境間傳遞聲明而執(zhí)行的一種基于JSON的開(kāi)放標(biāo)準(zhǔn)（(RFC 7519).該token被設(shè)計(jì)為緊湊且安全的，特別適用于分布式站點(diǎn)的單點(diǎn)登錄（SSO）場(chǎng)景。JWT的聲明一般被用來(lái)在身份提供者和服務(wù)提供者間傳遞被認(rèn)證的用戶身份信息，以便于從資源服務(wù)器獲取資源，也可以增加一些額外的其它業(yè)務(wù)邏輯所必須的聲明信息，該token也可直接被用于認(rèn)證，也可被加密。

起源

在講 JWT 之前一定要講講基于 token 和 session 的區(qū)別。

傳統(tǒng)的session認(rèn)證

http 協(xié)議本身是一種無(wú)狀態(tài)的協(xié)議，就是意味著如果用戶向我們的應(yīng)用提供了用戶名和密碼來(lái)進(jìn)行用戶認(rèn)證，那么下一次請(qǐng)求時(shí)，用戶還要再一次進(jìn)行用戶認(rèn)證才行，因?yàn)楦鶕?jù)http協(xié)議，我們并不能知道是哪個(gè)用戶發(fā)出的請(qǐng)求，所以為了讓我們的應(yīng)用能識(shí)別是哪個(gè)用戶發(fā)出的請(qǐng)求，我們只能在服務(wù)器存儲(chǔ)一份用戶登錄的信息，這份登錄信息會(huì)在響應(yīng)時(shí)傳遞給瀏覽器，告訴其保存為 cookie,以便下次請(qǐng)求時(shí)發(fā)送給我們的應(yīng)用，這樣我們的應(yīng)用就能識(shí)別請(qǐng)求來(lái)自哪個(gè)用戶了,這就是傳統(tǒng)的基于 session 認(rèn)證。

但是這種基于 session 的認(rèn)證使應(yīng)用本身很難得到擴(kuò)展，隨著不同客戶端用戶的增加，獨(dú)立的服務(wù)器已無(wú)法承載更多的用戶，而這時(shí)候基于 session 認(rèn)證應(yīng)用的問(wèn)題就會(huì)暴露出來(lái)。

工作原理

當(dāng) client 通過(guò)用戶名、密碼請(qǐng)求server并通過(guò)身份認(rèn)證后，server就會(huì)生成身份認(rèn)證相關(guān)的 session 數(shù)據(jù)，并且保存在內(nèi)存或者內(nèi)存數(shù)據(jù)庫(kù)。并將對(duì)應(yīng)的 sesssion_id返回給 client，client會(huì)把保存session_id（可以加密簽名下防止篡改）在cookie。此后client的所有請(qǐng)求都會(huì)附帶該session_id（畢竟默認(rèn)會(huì)把cookie傳給server），以確定server是否存在對(duì)應(yīng)的session數(shù)據(jù)以及檢驗(yàn)登錄狀態(tài)以及擁有什么權(quán)限，如果通過(guò)校驗(yàn)就該干嘛干嘛，否則就重新登錄。

前端退出的話就清cookie。后端強(qiáng)制前端重新認(rèn)證的話就清或者修改session。

優(yōu)點(diǎn)與弊端

優(yōu)點(diǎn)：

• 相比JWT，最大的優(yōu)勢(shì)就在于可以主動(dòng)清除session。
• session保存在服務(wù)器端，相對(duì)較為安全。
• 結(jié)合cookie使用，較為靈活，兼容性較好。

弊端：

每個(gè)用戶經(jīng)過(guò)我們的應(yīng)用認(rèn)證之后，我們的應(yīng)用都要在服務(wù)端做一次記錄，以方便用戶下次請(qǐng)求的鑒別，通常而言session都是保存在內(nèi)存中，而隨著認(rèn)證用戶的增多，服務(wù)端的開(kāi)銷(xiāo)會(huì)明顯增大。

用戶認(rèn)證之后，服務(wù)端做認(rèn)證記錄，如果認(rèn)證的記錄被保存在內(nèi)存中的話，這意味著用戶下次請(qǐng)求還必須要請(qǐng)求在這臺(tái)服務(wù)器上,這樣才能拿到授權(quán)的資源，這樣在分布式的應(yīng)用上，相應(yīng)的限制了負(fù)載均衡器的能力。這也意味著限制了應(yīng)用的擴(kuò)展能力。

如果是分布式部署，需要做多機(jī)共享session機(jī)制，實(shí)現(xiàn)方法可將session存儲(chǔ)到數(shù)據(jù)庫(kù)中或者redis中

容易被CSRF，因?yàn)槭腔赾ookie來(lái)進(jìn)行用戶識(shí)別的, cookie如果被截獲，用戶就會(huì)很容易受到跨站請(qǐng)求偽造的攻擊。

cookie + session在跨域場(chǎng)景表現(xiàn)并不好

session、cookie、sessionStorage、localstorage的區(qū)別

session:

主要存放在服務(wù)器端，相對(duì)安全。

cookie：

可設(shè)置有效時(shí)間，默認(rèn)是關(guān)閉瀏覽器后失效，主要存放在客戶端，并且不是很安全，可存儲(chǔ)大小約為4kb。

sessionStorage：

僅在當(dāng)前會(huì)話下有效，關(guān)閉頁(yè)面或?yàn)g覽器后被清除。

localstorage：

除非被清除，否則永久保存。

基于JWT token的驗(yàn)證機(jī)制

JWT基本上由“.”分隔的三部分組成，分別是頭部，有效載荷和簽名。 一個(gè)簡(jiǎn)單的JWT的例子，如下所示：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySUQiOjEsImlhdCI6MTU4MTMyMjE4MCwiZXhwIjoxNTgxMzI5MzgwfQ.6PVma3dLCbiXYgBJld5McFJ-q-QydCY7YVtrKPBsRi8

這部分字符串實(shí)際上是由三部分構(gòu)成的，重點(diǎn)使用點(diǎn)符號(hào)分割的，在JWT中分別代表：Header、Payload、Signature。

Header

JWT 的 Header 通常包含兩個(gè)字段，分別是：typ(type) 和 alg(algorithm)。

typ: token的類(lèi)型，這里固定為 JWT。

alg: 加密的算法，通常直接使用 HMAC SHA256。

完整的頭部聲明如下：

{
 'typ': 'JWT',
 'alg': 'HS256'
}

然后將頭部進(jìn)行base64加密（該加密是可以對(duì)稱解密的),構(gòu)成了第一部分。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Playload

載荷就是存放有效信息的地方，這些有效信息包含如下三個(gè)部分：

• 標(biāo)準(zhǔn)注冊(cè)聲明
• 公共聲明
• 私有聲明

標(biāo)準(zhǔn)注冊(cè)聲明

• iss: jwt簽發(fā)者
• sub: jwt所面向的用戶
• aud: 接收jwt的一方
• exp: jwt的過(guò)期時(shí)間，這個(gè)過(guò)期時(shí)間必須要大于簽發(fā)時(shí)間。
• nbf: 定義在什么時(shí)間之前，該 JWT 都是不可用的。
• iat: jwt的簽發(fā)時(shí)間
• jti: jwt的唯一身份標(biāo)識(shí)，主要用來(lái)作為一次性token,從而回避重放攻擊。
  

時(shí)間戳一般使用 unix 時(shí)間戳表示。

公共聲明

公共的聲明可以添加任何的信息，一般添加用戶的相關(guān)信息或其他業(yè)務(wù)需要的必要信息，但不建議添加敏感信息，因?yàn)樵摬糠衷诳蛻舳丝山饷堋?/p>

私有聲明

私有聲明是提供者和消費(fèi)者所共同定義的聲明，一般不建議存放敏感信息，因?yàn)閎ase64是對(duì)稱解密的，意味著該部分信息可以歸類(lèi)為明文信息。

定義一個(gè)簡(jiǎn)單的 payload，如下：

{
  userID: '1',
  exp: '1581329380',
  iat: '1581322180'
}

然后將其進(jìn)行base64加密，得到JWT的第二部分。

eyJ1c2VySUQiOjEsImlhdCI6MTU4MTMyMjE4MCwiZXhwIjoxNTgxMzI5MzgwfQ

在線base64轉(zhuǎn)換工具 地址。

Signature

JWT的第三部分是一個(gè)簽證信息，這個(gè)簽證信息由三部分組成：

• header (base64加密后的)
• payload (base64加密后的)
• secret

這個(gè)部分需要base64加密后的header和base64加密后的payload使用.連接組成的字符串，然后通過(guò)header中聲明的加密方式進(jìn)行和secret組合加密，然后就構(gòu)成了JWT的第三部分。

例如：

// javascript
var encodedString = base64UrlEncode(header) + '.' + base64UrlEncode(payload);

var signature = HMACSHA256(encodedString, 'secret');

secret是保存在服務(wù)器端的，JWT的簽發(fā)生成也是在服務(wù)器端的，secret就是用來(lái)進(jìn)行JWT的簽發(fā)和JWT的驗(yàn)證，所以，它就是你服務(wù)端的私鑰，在任何場(chǎng)景都不應(yīng)該流露出去。一旦客戶端得知這個(gè)secret, 那就意味著客戶端是可以自我簽發(fā)JWT了，那么你的程序?qū)⒖赡軙?huì)招到攻擊。

優(yōu)點(diǎn)與弊端

優(yōu)點(diǎn)：

• 因?yàn)閖son的通用性，所以JWT是可以進(jìn)行跨語(yǔ)言支持的，像JAVA,JavaScript,NodeJS,PHP等很多語(yǔ)言都可以使用。
• 因?yàn)橛辛藀ayload部分，所以JWT可以在自身存儲(chǔ)一些其他業(yè)務(wù)邏輯所必要的非敏感信息。
• 便于傳輸，jwt的構(gòu)成非常簡(jiǎn)單，字節(jié)占用很小，所以它是非常便于傳輸?shù)摹?/li>
• 它不需要在服務(wù)端保存會(huì)話信息, 所以它易于應(yīng)用的擴(kuò)展。
  

弊端：

• 需要設(shè)計(jì)token續(xù)簽問(wèn)題
• 需要設(shè)計(jì)用戶退出后token依然有效等問(wèn)題
• 密碼修改后token依然有效等問(wèn)題
• 還有很多小問(wèn)題，但是我覺(jué)得是利大于弊吧

一般是在請(qǐng)求頭里加入Authorization，并加上Bearer標(biāo)注：

fetch('api/user/1', {
 headers: {
  'Authorization': 'Bearer ' + token
 }
})

工作原理如圖：

Angular中使用JWT進(jìn)行身份驗(yàn)證

這里使用一TODO案例來(lái)進(jìn)行演示。

設(shè)計(jì)API

• /auth POST 提交用戶名 username 和密碼 password 進(jìn)行登陸認(rèn)證，返回 JWT 字符串。
• /todos GET 返回待辦事項(xiàng)清單。
• /todos/{id} GET 返回指定的待辦事項(xiàng)。
• /users GET 返回用戶列表。

程序操作流程簡(jiǎn)述

首先程序有一個(gè)登錄界面，用戶需要輸入用戶和用戶密碼。當(dāng)提交表單后，前端會(huì)將數(shù)據(jù)發(fā)送到后端的 /auth 路徑。后端采取合適的查詢方式對(duì)這個(gè)用戶進(jìn)行驗(yàn)證，驗(yàn)證成功后會(huì)返回token 字符串。

后端數(shù)據(jù)聲明

// 定義用戶
const USERS = [
  { id: 1, username: 'vincent', password: '123456'},
  { id: 2, username: 'bob', password: '123456'},
  { id: 3, username: 'peter', password: '123456'},
];

// 創(chuàng)建TODO列表,json格式
const TODOS = [
  { id: 1, userId: 1, name: "Play LOL", completed: false },
  { id: 2, userId: 1, name: "Do homework", completed: true },
  { id: 3, userId: 2, name: "Play basketball", completed: false },
  { id: 4, userId: 3, name: "Finish Angular JWT", completed: false },
];

密碼切記不能放在 payload 中的，因?yàn)檫@樣很不安全。

后端代碼實(shí)現(xiàn)

導(dǎo)入所需要的庫(kù)

const _ = require('lodash');
const express = require('express')
const bodyParser = require('body-parser');
const jwt = require('jsonwebtoken');
const expressJwt = require('express-jwt');

定義函數(shù)

// 獲取用戶相關(guān)的所有Todo事項(xiàng)函數(shù)
function getTodos(userID) {
  var todos = _.filter(TODOS, ['userId', userID]);
  return todos;
}

// 獲取指定id的todo事項(xiàng)
function getTodo(todoID) {
  var todo = _.find(TODOS, (todo) => { return todo.id == todoID; })

  return todo;
}

// 獲取所有用戶
function getUsers() {
  let users = Array(USERS.length);
  for (let i = 0; i < USERS.length; i++) {
    users[i] = {id: USERS[i].id, username: USERS[i].username};
  }
  return users;
}

使用 expressJwt 生成 token

todo-shared-secret是秘鑰字符串，這個(gè)注意一定要存儲(chǔ)在后端。
具體代碼可以到 https://gitee.com/powersky/jwt 這里來(lái)找。

實(shí)現(xiàn)其他的API

前端代碼實(shí)現(xiàn)

前端主要分為以下幾個(gè)部分:

服務(wù)：

• user service 用于獲取用戶數(shù)據(jù)
• todo service 用于獲取todo數(shù)據(jù)
• auth service 用于驗(yàn)證用戶獲取token
• auth guard 用于路由守衛(wèi)，判斷是否能夠進(jìn)行路由跳轉(zhuǎn)

組件:

• user list 用戶展示界面
• todo list 用戶展示todo待辦事項(xiàng)界面
• login 用戶登錄界面

下面依次展示。

user.service.ts

todo.service.ts

auth.service.ts

auth.guard.ts

UserListComponent和html

TodoListComponent和html

LoginComponent和html

AppComponent和html

AppRoutingModule

為了能夠使用代理需要增加一個(gè)配置文件：

proxy.conf.json

{
 "/api/*": {
  "target": "http://localhost:4000",
  "secure": false,
  "logLevel": "debug",
  "changeOrigin": true
 }
}

然后在package.json中加入：

"name": "jwt",
"version": "0.0.0",
"scripts": {
"ng": "ng",
"start": "ng serve --proxy-config proxy.conf.json",
"build": "ng build",
"test": "ng test",
"lint": "ng lint",
"e2e": "ng e2e"
},

然后命令行執(zhí)行下面命令開(kāi)啟前端：

npm start

執(zhí)行下面命令啟動(dòng)后端:

node server/app.js

到此這個(gè)案例就結(jié)束了。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。