概念介紹

認(rèn)證授權(quán)在業(yè)界已經(jīng)有很多成熟的方案，但對于前端開發(fā)來說，大部分情況都是調(diào)用服務(wù)端提供登錄接口完成認(rèn)證，后續(xù)請求帶上對于 token 即可。相信不少公司還會(huì)開發(fā) JS SDK，讓各個(gè)業(yè)務(wù)項(xiàng)目都能快速接入認(rèn)證授權(quán)，所以認(rèn)證授權(quán)的細(xì)節(jié)流程我們可能并沒有關(guān)注過。

本文將從前端視角介紹常見的認(rèn)證授權(quán)方案，同時(shí)提供簡單的實(shí)踐來體驗(yàn)流程。

認(rèn)證

認(rèn)證 (Identification) 是驗(yàn)證當(dāng)前用戶的身份。

常見的認(rèn)證技術(shù)：

• 身份證
• 用戶名和密碼
• 用戶手機(jī)：手機(jī)短信、手機(jī)二維碼掃描、手勢密碼
• 用戶的電子郵箱
• 用戶的生物學(xué)特征：指紋、語音、眼睛虹膜

授權(quán)

授權(quán) (Authorization) 指賦予用戶系統(tǒng)的訪問權(quán)限。認(rèn)證完用戶身份后，系統(tǒng)會(huì)授予用戶部分或者全部權(quán)限。系統(tǒng)要是沒有權(quán)限控制需求的話，一般認(rèn)證后用戶就有全部權(quán)限。

實(shí)現(xiàn)授權(quán)的方式有：

• cookie
• session
• token
• OAuth

鑒權(quán)

鑒權(quán) (Authentication) 是指系統(tǒng)鑒定用戶身份和權(quán)限。比如系統(tǒng)需要鑒定 session/cookie/token 的合法性和有效性。

認(rèn)證、授權(quán)和鑒權(quán)關(guān)系

這三個(gè)概念的關(guān)系也是很清晰，就是一個(gè)前后依次發(fā)生的關(guān)系：認(rèn)證 => 授權(quán) => 鑒權(quán)。比如我們登錄某個(gè)系統(tǒng)就完成了認(rèn)證和授權(quán)，后續(xù)使用功能時(shí)就需要系統(tǒng)鑒權(quán)。

了解相關(guān)概念后，就可以開始介紹常見的認(rèn)證授權(quán)方案。

認(rèn)證授權(quán)方案

HTTP 基本認(rèn)證

基本認(rèn)證 (Basic 認(rèn)證) 是 HTTP/1.0 就定義的認(rèn)證方式，主要通過用戶提供用戶名和密碼的方式，實(shí)現(xiàn)對用戶身份的驗(yàn)證。

基本認(rèn)證流程圖

認(rèn)證步驟解析

• 瀏覽器請求受保護(hù)的資源
• 服務(wù)器返回 401，同時(shí)響應(yīng)頭帶上 WWW-Authenticate: Basic realm=protected_docs，realm 代表資源的安全域，我們資源可能權(quán)限不同，放在不同的安全域中
• 瀏覽器彈窗請求用戶賬號密碼，用戶輸入后，瀏覽器 Base64 編碼賬號密碼，再次請求，請求頭帶上 Authorization: Basic Base64(賬號:密碼)
• 服務(wù)器認(rèn)證賬號密碼，認(rèn)證成功返回對應(yīng)資源，認(rèn)證失敗返回 403 forbidden

node 的簡單實(shí)現(xiàn)

const express = require('express')
const app = express()
const protectedPath = '/protected_docs'
const realms = {
  [protectedPath]: {
    users: ['root'],
  },
}
app.get(protectedPath, (req, res, next) => {
  const realm = realms[req.path]
  const authorization = req.get('authorization')
  if (!authorization) {
    // 告知用戶需要身份認(rèn)證
    res.statusCode = 401
    res.set('WWW-Authenticate', 'Basic realm=' + encodeURIComponent(realm))
    res.end()
    return
  }
  const usernamePasswd = authorization.split(' ')[1] // Basic Y2h5aW5ncDoxMjM0NTY
  const [usrname, passwd] = Buffer.from(usernamePasswd, 'base64')
    .toString()
    .split(':')
  if (!realm.users.includes(usrname)) {
    // 用戶不在realm里
    res.statusCode = 401
    res.set('WWW-Authenticate', 'Basic realm=' + encodeURIComponent(realm))
    res.end()
    return
  }
  const isValid = usrname === 'root' && passwd === '123456'
  if (!isValid) {
    // 用戶賬號、密碼驗(yàn)證不通過
    res.statusCode = 403
    res.end()
    return
  }
  res.end(`welecom ${usrname}`)
})
app.listen(3000)

小結(jié)

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

• 簡單，基本所有瀏覽器都支持

缺點(diǎn)：

• 不安全，HTTP 上傳輸，密碼只是 Base64 編碼，可以被解碼。
• 無法主動(dòng)注銷，除非標(biāo)簽頁或?yàn)g覽器關(guān)閉、或用戶清除歷史記錄，認(rèn)證信息一直存在。

使用場景：

• 內(nèi)部網(wǎng)絡(luò)，或者對安全要求不是很高的網(wǎng)絡(luò)。比如公司內(nèi)網(wǎng) wiki

這邊提一下，HTTP1.1 針對基本認(rèn)證缺點(diǎn)，提供了摘要認(rèn)證(Digest 認(rèn)證)，原理簡單來說就是服務(wù)端會(huì)給瀏覽器一個(gè) nonce 隨機(jī)數(shù)，瀏覽器會(huì)將賬號、密碼和 nonce 等參數(shù)進(jìn)行 md5 加密后傳給服務(wù)端（同時(shí)傳賬號數(shù)據(jù)，密碼不傳），服務(wù)端獲取到賬號后，從數(shù)據(jù)庫拿密碼同樣進(jìn)行 md5 加密，加密后值和瀏覽器傳的一樣就認(rèn)為認(rèn)證成功。

摘要認(rèn)證不再明文傳輸密碼、可以防重放和避免報(bào)文被篡改，但是需要和 Https 配合使用。

Session-Cookie

Session-Cookie 認(rèn)證是利用服務(wù)端的 Session（會(huì)話）和瀏覽器（客戶端）的 Cookie 來實(shí)現(xiàn)的前后端通信認(rèn)證模式。

什么是 Cookie

HTTP 是無狀態(tài)協(xié)議，服務(wù)端在接收到客戶端首次請求后，設(shè)置對應(yīng)的 Cookie，隨后瀏覽器在請求帶上 Cookie，服務(wù)端就可以知道當(dāng)前客戶端狀態(tài)。

Cookie 的特點(diǎn)：

• Cookie 存儲(chǔ)在客戶端，可能被修改，不安全
• 有大小限制，一般是 4KB
• Android 和 IOS 對 Cookie 支持不好
• Cookie 有跨域限制

什么是 Session

Session 的抽象概念是會(huì)話，是無狀態(tài)協(xié)議通信過程中，為了實(shí)現(xiàn)中斷/繼續(xù)操作，將用戶和服務(wù)器之間的交互進(jìn)行的一種抽象。

Session 一般流程是：服務(wù)端接收到客戶端首次請求后，設(shè)置一個(gè) Session 來跟蹤用戶的會(huì)話，同時(shí)會(huì)給客戶端一個(gè) Session ID，后續(xù)客戶端請求時(shí)在帶上 Session ID，服務(wù)端即可找到對應(yīng)的 Session，此時(shí)雙方通信就是有狀態(tài)的。

Session 特點(diǎn)：

• Session 數(shù)據(jù)保存在服務(wù)端，安全性高
• Session 數(shù)據(jù)大小可以超過 4KB，存儲(chǔ)數(shù)

Session-Cookie 流程

Session 流程中一般會(huì)設(shè)置 Session ID，通常 Session ID 會(huì)保存在 瀏覽器 Cookie 中，接下來看下整體流程。

認(rèn)證步驟解析

• 瀏覽器發(fā)送登錄請求
• 服務(wù)端校驗(yàn)賬號密碼，校驗(yàn)通過后生成 Session 和 Session ID，Session 保存在 Session 服務(wù)器中（一般保存在內(nèi)存或者 Redis 服務(wù)器）。隨后返回?cái)?shù)據(jù)給瀏覽器，同時(shí)設(shè)置一個(gè) Session ID 的 Cookie
• 瀏覽器請求資源，一般會(huì)自動(dòng)帶上 Session ID 的 Cookie
• 服務(wù)端獲取到 Session ID，通過 Session 服務(wù)器校驗(yàn) Session，Session 服務(wù)器校驗(yàn)成功，服務(wù)端處理數(shù)據(jù)邏輯
• 服務(wù)端返回?cái)?shù)據(jù)給瀏覽器

簡單代碼示例

const express = require("express");
const app = express();
const bodyParser = require("body-parser");
const port = 3000;
const session = require("express-session");
app.use(bodyParser());
app.use(
  session({
    key: 'SESSION_ID',
    secret: "your_secret_key",
    resave: false,
    saveUninitialized: false,
    cookie: { maxAge: 1000 * 60 * 60 * 8, signed: true },
  })
);
app.get("/", async function (req, res) {
  res.send(req.session);
});
app.get("/login", async function (req, res) {
  const authInfo = {
    id: '1',
    username: 'user',
  }
  const isValid = true
  if (isValid) {
    req.session.authInfo = authInfo
    res.send({
      success: true,
      info: "登錄成功",
    });
  } else {
    res.send({
      success: false,
      info: "登錄失敗",
    });
  }
});
app.listen(port, () => {
  console.log(`node listening at http://localhost:${port}`);
});

使用 node 起好服務(wù)器后，先訪問 /login，在訪問首頁 /, 可以看到首頁輸出用戶名。同時(shí)打開 F12，在 Cookie 中可以看到 SESSION_ID 的數(shù)據(jù)。

小結(jié)

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

• Cookie 簡單易用
• Session 數(shù)據(jù)保存在服務(wù)端，安全
• 支持 Session 管理，能主動(dòng)注銷 Session
• 只需后端操作，前端無感

缺點(diǎn)：

• 依賴 Cookie，禁用 Cookie 情況下無法使用
• 因?yàn)槭褂昧?Cookie ，所以可能有 CSRF 攻擊
• Session 存在服務(wù)端，用戶量大的情況下，服務(wù)端開銷增加，性能會(huì)下降
• 對移動(dòng)端的支持性不友好

使用場景：

• 一般中大型的網(wǎng)站都適用

Token

上述介紹中，我們知道了 Session-Cookie 的一些缺點(diǎn)，及 Session 的維護(hù)給服務(wù)端造成很大困擾，必須找地方存放它，又要考慮分布式的問題，所以 Token 方案就出來了。

什么是 Token

Token 是一個(gè)令牌，客戶端訪問服務(wù)器時(shí)，驗(yàn)證通過后服務(wù)端會(huì)為其簽發(fā)一張令牌，之后，客戶端就可以攜帶令牌訪問服務(wù)器，服務(wù)端只需要驗(yàn)證令牌的有效性即可。

一般 Token 的組成：

uid(用戶唯一的身份標(biāo)識) + time(當(dāng)前時(shí)間的時(shí)間戳) + sign(簽名，Token 的前幾位以哈希算法壓縮成的一定長度的十六進(jìn)制字符串)

Token 認(rèn)證流程

認(rèn)證步驟解析

• 客戶端發(fā)送登錄請求
• 服務(wù)端校驗(yàn)賬號密碼，生成 Token，并返回給客戶端
• 收到 Token 以后需要把它存儲(chǔ)起來，web 端一般會(huì)放在 localStorage 或 Cookie 中
• 客戶端請求 API 資源的時(shí)候，將 Token 通過 HTTP 請求頭 Authorization 字段或者其它方式發(fā)送給服務(wù)端
• 服務(wù)端拿到 Token，做解密和簽名校驗(yàn)，通過校驗(yàn)返回?cái)?shù)據(jù)，否則返回 401

Token的優(yōu)缺點(diǎn)

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

• 服務(wù)端無狀態(tài)化、可擴(kuò)展性好：Token 自身包含了其所標(biāo)識用戶的相關(guān)信息，這有利于在多個(gè)服務(wù)間共享用戶狀態(tài)
• 安全性好，可以避免 CSRF 攻擊
• 支持跨域調(diào)用

缺點(diǎn)：

• 性能問題，服務(wù)端需要對 Token 加解密等操作，所以會(huì)更耗性能
• 有效期短：為了避免 Token 被盜用，一般 Token 的有效期會(huì)設(shè)置的較短，所以就有了 Refresh Token
• 相比于 Session-Cookie，需要前后端配合處理

Refresh Token

業(yè)務(wù)接口用來鑒權(quán)的 Token，我們稱之為 Access Token，為了安全性，Access Token 有效期一般設(shè)置的比較短。Access Token 過期后，需要用戶重新登錄，但是這種體驗(yàn)較差。

所以有了 Refresh Token， 可以用 Refresh Token 去獲取 Access Token。

• Access Token：用來訪問業(yè)務(wù)接口，由于有效期足夠短，盜用風(fēng)險(xiǎn)小。

• Refresh Token：用來獲取 Access Token，有效期可以長一些，通過獨(dú)立服務(wù)和嚴(yán)格的請求方式增加安全性。

Refresh Token 的使用流程是在服務(wù)器校驗(yàn) Token， 發(fā)現(xiàn)過期后，客戶端可以使用 Refresh Token 發(fā)起請求，獲取新的 Access Token 和 Refresh Token。

JSON Web Token（JWT）

上述 Token 中，一般只有 uid 信息，需要更多登錄信息和其他數(shù)據(jù)的話，這時(shí)就需要查詢數(shù)據(jù)庫。每次都需要查詢數(shù)據(jù)庫，就會(huì)帶來一些性能消耗。所以業(yè)界常用的 JWT 方案就出來了。

JWT 是 Auth0 提出的通過對 JSON 進(jìn)行加密簽名來實(shí)現(xiàn)授權(quán)驗(yàn)證的方案, 它的特點(diǎn)是自包含的，用戶信息和認(rèn)證是在一起的，無需像 Cookie-Session 一樣需要 Session 服務(wù)器，或者像 Token 一樣訪問數(shù)據(jù)庫獲取用戶信息。

JWT 本質(zhì)上就是一組字串，通過（.）切分成三個(gè)為 Base64 編碼的部分：

• Header : 描述 JWT 的元數(shù)據(jù)，定義了生成簽名的算法以及 Token 的類型。
• Payload : 用來存放實(shí)際需要傳遞的數(shù)據(jù)，JWT 規(guī)定了 7 個(gè)官方字段，比如 iss、exp 等等，還可以自定義數(shù)據(jù)。
• Signature（簽名）：服務(wù)器通過 Payload、Header 和一個(gè)密鑰 (Secret) 使用 Header 里面指定的簽名算法（默認(rèn)是 HMAC SHA256）生成。

JWT 通常是這樣的：xxxxx.yyyyy.zzzzz。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJuYW1lIjoieGlhb21pbmciLCJkYXRhIjoiPT09PT09PT09PT09PSIsImlhdCI6MTY3OTgwNDA1NywiZXhwIjoxNjc5ODA0MTE3fQ
.FdJ6UD4Ff5zOz83f4hRDh1C86kN5f8aO_KeEtIwt3cM

JWT 認(rèn)證流程

其實(shí) JWT 的認(rèn)證流程與 Token 的認(rèn)證流程差不多，只是不需要再單獨(dú)去查詢數(shù)據(jù)庫查找用戶信息。

JWT 實(shí)例

const { expressjwt: jwt } = require('express-jwt')
const express = require('express')
const app = express()
const jsonwebtoken = require('jsonwebtoken')
const secretOrPrivateKey = 'hello' //加密token 校驗(yàn)token時(shí)要使用
app.use(
  jwt({
    secret: secretOrPrivateKey,
    algorithms: ['HS256'],
  }).unless({
    path: ['/getToken'], //除了這個(gè)地址，其他的URL都需要驗(yàn)證
  })
)
app.use(function (err, req, res, next) {
  if (err.name === 'UnauthorizedError') {
    res.status(401).send('invalid token...')
  }
})
app.get('/getToken', function (req, res) {
  res.json({
    result: 'ok',
    token: jsonwebtoken.sign(
      {
        name: 'xiaoming',
        data: '=============',
      },
      secretOrPrivateKey,
      {
        expiresIn: 60 * 1,
      }
    ),
  })
})
app.get('/getData', function (req, res) {
  res.send('data')
})
app.listen(3000)

服務(wù)啟動(dòng)后，訪問 /getToken 獲取 JWT，然后在 Postman 中請求 /getData, Header 部分加上 Authorization: Bearer your jwt，比如 Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoieGlhb21pbmciLCJkYXRhIjoiPT09PT09PT09PT09PSIsImlhdCI6MTY3OTgwNjkyOCwiZXhwIjoxNjc5ODA2OTg4fQ.qFOT9IS_T1ZNsWWheRXP9MxYPh1l3SBGWLtp8ocnKAE。

JWT 的優(yōu)缺點(diǎn)

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

• 不需要在服務(wù)端保存會(huì)話信息，所以易于應(yīng)用的擴(kuò)展
• JWT 中的 Payload 負(fù)載可以存儲(chǔ)常用信息，用于信息交換，有效地使用 JWT，可以降低服務(wù)端查詢數(shù)據(jù)庫的次數(shù)

缺點(diǎn)：

• 請求頭體積較大，Payload 數(shù)據(jù)量大的時(shí)候，請求頭體積也會(huì)對應(yīng)增大
• JWT 默認(rèn)是不加密，所以 Payload 一般不放敏感信息，不過也可以再次加密。
• 到期問題，JWT 一旦簽發(fā)后，除非到了過期時(shí)間，不然會(huì)一直有效，服務(wù)端無法主動(dòng)注銷掉。

使用場景：

• 一般對安全要求不高，對負(fù)載要求高的場景都會(huì)可以使用 JWT，安全敏感的場景推薦使用 token + redis
• 單點(diǎn)登錄

Oauth 2.0

OAuth 這種方式登錄相信大家都使用過，比如我們想登錄某個(gè)網(wǎng)站時(shí)，通常會(huì)發(fā)現(xiàn)可以通過第三方的 QQ 或者微信登錄，這個(gè)就是使用到了 OAuth。

OAuth 是一個(gè)開放標(biāo)準(zhǔn)，允許用戶授權(quán)第三方網(wǎng)站訪問他們存儲(chǔ)在另外的服務(wù)提供者上的信息，而不需要將用戶名和密碼提供給第三方網(wǎng)站。常見的提供 OAuth 認(rèn)證服務(wù)的廠商：支付寶、QQ、微信、微博

OAuth 認(rèn)證流程

認(rèn)證步驟解析

• 客戶端發(fā)起使用第三方登錄，服務(wù)端攜帶 client_id 直接重定向到授權(quán)服務(wù)器登錄頁面，授權(quán)服務(wù)器要求客戶端登錄。
• 客戶端完成第三方登錄并同意授權(quán)后，授權(quán)服務(wù)器重定向到服務(wù)端，并攜帶授權(quán)碼 code，服務(wù)器攜帶 client_id, client_secret, code 向授權(quán)服務(wù)器請求令牌。
• 授權(quán)服務(wù)器通過認(rèn)證，并返回令牌
• 服務(wù)端用令牌向授權(quán)服務(wù)器請求用戶基本信息，授權(quán)服務(wù)器認(rèn)證令牌通過后返回?cái)?shù)據(jù)
• 服務(wù)端返回用戶信息給客戶端

使用 github 登錄示例

準(zhǔn)備工作：

1、創(chuàng)建 OAuth App

2、填寫基本信息

3、獲取 client_id 和 client_secret

代碼示例

const express = require('express')
const app = express()
const querystring = require('querystring')
const axios = require('axios')
// GitHub登錄參數(shù)配置；配置授權(quán)應(yīng)用生成的Client ID和Client Secret
const config = {
  client_id: 'xxx',
  client_secret: 'xxxxxx'
}
// 登錄接口
app.get('/github/login', function (req, res) {
  // 重定向到GitHub認(rèn)證接口，并配置參數(shù)
  let path = 'https://github.com/login/oauth/authorize?client_id=' + config.client_id
  // 轉(zhuǎn)發(fā)到授權(quán)服務(wù)器
  res.redirect(path)
})
// GitHub授權(quán)登錄成功回調(diào)，地址必須與GitHub配置的回調(diào)地址一致
app.get('/passport/github/callback', async function (req, res) {
  console.log('callback...')
  // 服務(wù)器認(rèn)證成功，回調(diào)帶回認(rèn)證狀態(tài)code
  const code = req.query.code
  const params = {
    client_id: config.client_id,
    client_secret: config.client_secret,
    code: code
  }
  // 申請令牌token
  let tokenRes = await axios.post('https://github.com/login/oauth/access_token', params)
  const access_token = querystring.parse(tokenRes.data).access_token
  // 根據(jù)token獲取用戶信息
  userRes = await axios.get(`https://api.github.com/user`, {
    headers: {
      'Authorization': 'token ' + access_token
    }
  })
  // 渲染頁面
  res.end(`
    <h1>Hello ${userRes.data.login}</h1>
    <img src="${userRes.data.avatar_url}" alt="">
  `)
})
app.listen(7001, () => {
  console.log('listening port at 7001...')
})

服務(wù)啟動(dòng)后，訪問 /github/login，后續(xù)會(huì)跳轉(zhuǎn) github 登錄授權(quán)，完成后即可看到你的 github 用戶名和頭像。

總結(jié)

登錄的認(rèn)證授權(quán)方式有很多，上述講到的都是一些常見的方案，當(dāng)前方案的具體細(xì)節(jié)實(shí)施各個(gè)項(xiàng)目方還是會(huì)有差異的。

除了上述的內(nèi)容后，認(rèn)證授權(quán)這塊還有單點(diǎn)登錄（SSO）、掃描登錄、手機(jī)號一鍵登錄等等方式，后續(xù)有機(jī)會(huì)在講。

以上就是JS前端認(rèn)證授權(quán)技巧歸納總結(jié)的詳細(xì)內(nèi)容，更多關(guān)于JS前端認(rèn)證授權(quán)的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論