Hello，大家好，我是 Sunday

在前端項(xiàng)目開發(fā)中，驗(yàn)證用戶身份主要有 4 種方式：Session、JWT、SSO 和 OAuth 2.0。

那么這四種方式各有什么優(yōu)缺點(diǎn)呢？今天，咱們就來對(duì)比下！

01：基于 Session 的經(jīng)典身份驗(yàn)證方案

什么是基于Session的身份驗(yàn)證？

基于 Session 的身份驗(yàn)證是一種在前端和后端系統(tǒng)中常用的用戶認(rèn)證方法。

它主要依賴于服務(wù)器端創(chuàng)建和管理用戶會(huì)話。

Session 運(yùn)行的基本原理

Session 的運(yùn)行流程分為 6 步：

1. 用戶登錄：用戶在登錄頁面輸入憑據(jù)（如用戶名和密碼）。這些憑據(jù)通過前端發(fā)送到后端服務(wù)器進(jìn)行驗(yàn)證。
2. 創(chuàng)建會(huì)話：后端服務(wù)器驗(yàn)證憑據(jù)后，創(chuàng)建一個(gè)會(huì)話（session）。這個(gè)會(huì)話通常包括一個(gè)唯一的會(huì)話 ID，該 ID 被存儲(chǔ)在服務(wù)器端的會(huì)話存儲(chǔ)中。
3. 返回會(huì)話 ID：服務(wù)器將會(huì)話 ID 返回給前端，通常是通過設(shè)置一個(gè) cookie。這個(gè) cookie 被發(fā)送到用戶的瀏覽器，并在后續(xù)的請(qǐng)求中自動(dòng)發(fā)送回服務(wù)器。
4. 保存會(huì)話 ID：瀏覽器保存這個(gè) cookie，并在用戶每次向服務(wù)器發(fā)起請(qǐng)求時(shí)都會(huì)自動(dòng)包含這個(gè) cookie。這樣，服務(wù)器就能識(shí)別出該用戶的會(huì)話，從而實(shí)現(xiàn)身份驗(yàn)證。
5. 會(huì)話驗(yàn)證：服務(wù)器根據(jù)會(huì)話 ID 查找和驗(yàn)證該用戶的會(huì)話信息，并確定用戶的身份。服務(wù)器可以使用會(huì)話信息來確定用戶的權(quán)限和訪問控制。
6. 會(huì)話過期與管理：服務(wù)器可以設(shè)置會(huì)話過期時(shí)間，定期清除過期的會(huì)話。用戶注銷或會(huì)話超時(shí)后，服務(wù)器會(huì)刪除或使會(huì)話失效。

通過以上流程，我們可以發(fā)現(xiàn)：基于 Session 的身份驗(yàn)證，前端是不需要主動(dòng)參與的。核心是 瀏覽器 和 服務(wù)器 進(jìn)行處理

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

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

• 簡單易用：對(duì)開發(fā)者而言，管理會(huì)話和驗(yàn)證用戶身份相對(duì)簡單。
• 兼容性好：大多數(shù)瀏覽器支持 cookie，能夠自動(dòng)發(fā)送和接收 cookie。

缺點(diǎn)：

• 擴(kuò)展性差：在分布式系統(tǒng)中，多個(gè)服務(wù)器可能需要共享會(huì)話存儲(chǔ)，這可能會(huì)增加復(fù)雜性。
• 必須配合 HTTPS：如果 cookie 被竊取，可能會(huì)導(dǎo)致會(huì)話劫持。因此需要使用 HTTPS 來保護(hù)傳輸過程中的安全性，并實(shí)施其他安全措施（如設(shè)置 cookie 的 HttpOnly 和 Secure 屬性）。

示例代碼

接下來，我們通過 Express 實(shí)現(xiàn)一個(gè)基本的 Session 驗(yàn)證示例

const express = require('express'); 
const session = require('express-session'); 
const app = express(); 

// 配置和使用 express-session 中間件
app.use(session({
  secret: 'your-secret-key', // 用于簽名 Session ID cookie 的密鑰，確保會(huì)話的安全
  resave: false, // 是否每次請(qǐng)求都重新保存 Session，即使 Session 沒有被修改
  saveUninitialized: true, // 是否保存未初始化的 Session
  cookie: { 
    secure: true, // 是否只通過 HTTPS 發(fā)送 cookie，設(shè)置為 true 需要 HTTPS 支持
    maxAge: 24 * 60 * 60 * 1000 // 設(shè)置 cookie 的有效期，這里設(shè)置為 24 小時(shí)
  }
}));

// 登錄路由處理
app.post('/login', (req, res) => {
  // 進(jìn)行用戶身份驗(yàn)證（這里假設(shè)用戶已經(jīng)通過驗(yàn)證）
  // 用戶 ID 應(yīng)該從數(shù)據(jù)庫或其他存儲(chǔ)中獲取
  const user = { id: 123 }; // 示例用戶 ID
  req.session.userId = user.id; // 將用戶 ID 存儲(chǔ)到 Session 中
  res.send('登錄成功'); 
});


app.get('/dashboard', (req, res) => {
  if (req.session.userId) {
    // 如果 Session 中存在用戶 ID，說明用戶已登錄
    res.send('返回內(nèi)容...');
  } else {
    // 如果 Session 中沒有用戶 ID，說明用戶未登錄
    res.send('請(qǐng)登錄...'); // 提示用戶登錄
  }
});

app.listen(3000, () => {
  console.log('服務(wù)器正在監(jiān)聽 3000 端口...');
});

02：基于 JWT（JSON Web Token） 的身份驗(yàn)證方案

什么是基于 JWT 的身份驗(yàn)證？

這應(yīng)該是我們目前 最常用 的身份驗(yàn)證方式。

服務(wù)端返回 Token 表示用戶身份令牌。在請(qǐng)求中，把 token 添加到請(qǐng)求頭中，以驗(yàn)證用戶信息。

因?yàn)?nbsp;HTTP 請(qǐng)求本身是無狀態(tài)的，所以這種方式也被成為是 無狀態(tài)身份驗(yàn)證方案

JWT 運(yùn)行的基本原理

1. 用戶登錄：用戶在登錄頁面輸入憑據(jù)（如用戶名和密碼），這些憑據(jù)通過前端發(fā)送到后端服務(wù)器進(jìn)行驗(yàn)證。
2. 生成 JWT：后端服務(wù)器驗(yàn)證用戶憑據(jù)后，生成一個(gè) JWT。這個(gè) JWT 通常包含用戶的基本信息（如用戶 ID）和一些元數(shù)據(jù)（如過期時(shí)間）。
3. 返回 JWT：服務(wù)器將生成的 JWT 發(fā)送回前端，通常通過響應(yīng)的 JSON 數(shù)據(jù)返回。
4. 存儲(chǔ) JWT：前端將 JWT 存儲(chǔ)在客戶端（Token），通常是 localStorage 。極少數(shù)的情況下會(huì)保存在 cookie 中（但是需要注意安全風(fēng)險(xiǎn)，如：跨站腳本攻擊（XSS）和跨站請(qǐng)求偽造（CSRF））
5. 使用 JWT 進(jìn)行請(qǐng)求：在用戶進(jìn)行 API 調(diào)用時(shí)，前端將 JWT（Token） 附加到請(qǐng)求的 Authorization 頭部（格式為 Bearer <token>）發(fā)送到服務(wù)器。
6. 驗(yàn)證 JWT：服務(wù)器接收到請(qǐng)求后，提取 JWT（Token） 并驗(yàn)證其有效性。驗(yàn)證過程包括檢查簽名、過期時(shí)間等。如果 JWT 合法，服務(wù)器會(huì)處理請(qǐng)求并返回相應(yīng)的資源或數(shù)據(jù)。
7. 響應(yīng)請(qǐng)求：服務(wù)器處理請(qǐng)求并返回結(jié)果，前端根據(jù)需要展示或處理這些結(jié)果。

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

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

• 無狀態(tài)：JWT 是自包含的，不需要在服務(wù)器端存儲(chǔ)會(huì)話信息，簡化了擴(kuò)展性和負(fù)載均衡。
• 跨域支持：JWT 可以在跨域請(qǐng)求中使用（例如，API 與前端分離的場(chǎng)景）。

缺點(diǎn)

• 安全性：JWT 的安全性取決于密鑰的保護(hù)和有效期的管理。JWT 一旦被盜用，可能會(huì)帶來安全風(fēng)險(xiǎn)。

示例代碼

接下來，我們通過 Express 實(shí)現(xiàn)一個(gè)基本的 JWT 驗(yàn)證示例

const express = require('express');
const jwt = require('jsonwebtoken');
const bodyParser = require('body-parser');
const app = express();

app.use(bodyParser.json());

const secretKey = 'your-secret-key'; // JWT 的密鑰，用于簽名和驗(yàn)證

// 登錄路由，生成 JWT
app.post('/login', (req, res) => {
  const { username, password } = req.body;
  // 用戶身份驗(yàn)證（假設(shè)驗(yàn)證通過）
  const user = { id: 1, username: 'user' }; // 示例用戶信息
  const token = jwt.sign(user, secretKey, { expiresIn: '24h' }); // 生成 JWT
  res.json({ token }); // 返回 JWT
});

// 受保護(hù)的路由
app.get('/dashboard', (req, res) => {
  const token = req.headers['authorization']?.split(' ')[1];
  if (!token) {
    return res.status(401).send('沒有提供令牌');
  }
  jwt.verify(token, secretKey, (err, decoded) => {
    if (err) {
      return res.status(401).send('無效的令牌');
    }
    res.send('返回儀表板內(nèi)容'); 
  });
});

app.listen(3000, () => {
  console.log('服務(wù)器正在監(jiān)聽 3000 端口...');
});

03：基于 SSO 的身份驗(yàn)證方案

什么是基于 SSO（Single Sign-On，單點(diǎn)登錄） 的身份驗(yàn)證？

SSO 身份驗(yàn)證多用在 “成套” 的應(yīng)用程序中，通過 登錄中心 的方式，可以實(shí)現(xiàn) 一次登錄，在多個(gè)應(yīng)用中均可以獲取身份

SSO 運(yùn)行的基本原理

1. 用戶訪問應(yīng)用：用戶訪問一個(gè)需要登錄的應(yīng)用（稱為服務(wù)提供者或 SP）。
2. 重定向到身份提供者：由于用戶尚未登錄，應(yīng)用會(huì)將用戶重定向到 SSO 身份提供者（Identity Provider，簡稱 IdP）（一般稱為 登錄中心）。登錄中心 是負(fù)責(zé)處理用戶登錄和身份驗(yàn)證的系統(tǒng)。
3. 用戶登錄：用戶在 登錄中心 輸入憑據(jù)進(jìn)行登錄。如果用戶已經(jīng)在 IdP 處登錄過（例如，已登錄到公司內(nèi)部的 SSO 系統(tǒng)），則可能直接跳過登錄步驟。
4. 生成 SSO 令牌：SSO 身份提供者驗(yàn)證用戶身份后，生成一個(gè) SSO 令牌（如 OAuth 令牌或 SAML 斷言），并將用戶重定向回原應(yīng)用，同時(shí)附帶令牌。
5. 令牌驗(yàn)證：原應(yīng)用（服務(wù)提供者）接收到令牌后，會(huì)將其發(fā)送到 SSO 身份提供者進(jìn)行驗(yàn)證。SSO 身份提供者返回用戶的身份信息。
6. 用戶訪問應(yīng)用：一旦身份驗(yàn)證成功，原應(yīng)用會(huì)根據(jù)用戶的身份信息提供訪問權(quán)限。用戶現(xiàn)在可以訪問應(yīng)用中的受保護(hù)資源，而無需再次登錄。
7. 訪問其他應(yīng)用：如果用戶訪問其他應(yīng)用，這些應(yīng)用會(huì)重定向用戶到相同的 登錄中心 進(jìn)行身份驗(yàn)證。由于用戶已經(jīng)登錄，登錄中心 會(huì)自動(dòng)驗(yàn)證并將用戶重定向回目標(biāo)應(yīng)用，從而實(shí)現(xiàn)無縫登錄。

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

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

• 簡化用戶體驗(yàn)：用戶只需登錄一次，即可訪問多個(gè)應(yīng)用或系統(tǒng)，減少了重復(fù)登錄的麻煩。
• 集中管理：管理員可以集中管理用戶的身份和訪問權(quán)限，提高了管理效率和安全性。
• 提高安全性：減少了密碼泄露的風(fēng)險(xiǎn)，因?yàn)橛脩糁恍栌涀∫粋€(gè)密碼，并且可以使用更強(qiáng)的認(rèn)證機(jī)制（如多因素認(rèn)證）。

缺點(diǎn)

• 單點(diǎn)故障：如果 登錄中心 出現(xiàn)問題，可能會(huì)影響所有依賴該 SSO 服務(wù)的應(yīng)用。
• 復(fù)雜性：SSO 解決方案的部署和維護(hù)可能較為復(fù)雜，需要確保安全配置和互操作性。

常見的 SSO 實(shí)現(xiàn)技術(shù)

• SAML（Security Assertion Markup Language）：

• 一個(gè) XML-based 標(biāo)準(zhǔn)，用于在身份提供者和服務(wù)提供者之間傳遞認(rèn)證和授權(quán)數(shù)據(jù)。
• 常用于企業(yè)環(huán)境中的 SSO 實(shí)現(xiàn)。

• OAuth 2.0 和 OpenID Connect：

• OAuth 2.0 是一種授權(quán)框架，用于授權(quán)第三方訪問用戶資源。

• OpenID Connect 是建立在 OAuth 2.0 之上的身份層，提供用戶身份認(rèn)證功能。

• 常用于 Web 和移動(dòng)應(yīng)用中的 SSO 實(shí)現(xiàn)。

• CAS（Central Authentication Service）：

• 一個(gè)用于 Web 應(yīng)用的開源 SSO 解決方案，允許用戶通過一次登錄訪問多個(gè) Web 應(yīng)用。

04：基于 OAuth 2.0 的身份驗(yàn)證方案

什么是基于 OAuth 2.0 的身份驗(yàn)證？

基于 OAuth 2.0 的身份驗(yàn)證是一種用于授權(quán)第三方應(yīng)用訪問用戶資源的標(biāo)準(zhǔn)協(xié)議。常見的有：微信登錄、QQ 登錄、APP 掃碼登錄等

OAuth 2.0 主要用于授權(quán)，而不是身份驗(yàn)證，但通常與身份驗(yàn)證結(jié)合使用來實(shí)現(xiàn)用戶登錄功能。

OAuth 2.0 運(yùn)行的基本原理

OAuth 2.0 比較復(fù)雜，在了解它的原理之前，我們需要先明確一些基本概念。

OAuth 2.0 的基本概念

1. 資源擁有者（Resource Owner）：通常是用戶，擁有需要保護(hù)的資源（如個(gè)人信息、文件等）。
2. 資源服務(wù)器（Resource Server）：提供資源的服務(wù)器，需要保護(hù)這些資源免受未經(jīng)授權(quán)的訪問。
3. 客戶端（Client）：需要訪問資源的應(yīng)用程序或服務(wù)?？蛻舳诵枰@得資源擁有者的授權(quán)才能訪問資源。
4. 授權(quán)服務(wù)器（Authorization Server）：責(zé)認(rèn)證資源擁有者并授權(quán)客戶端訪問資源。它頒發(fā)訪問令牌（Access Token）給客戶端，允許客戶端訪問資源服務(wù)器上的受保護(hù)資源。

運(yùn)行原理

1. 用戶授權(quán)：用戶使用客戶端應(yīng)用進(jìn)行操作時(shí)，客戶端會(huì)請(qǐng)求授權(quán)訪問用戶的資源。用戶會(huì)被重定向到授權(quán)服務(wù)器進(jìn)行授權(quán)。
2. 獲取授權(quán)碼（Authorization Code）：如果用戶同意授權(quán)，授權(quán)服務(wù)器會(huì)生成一個(gè)授權(quán)碼，并將其發(fā)送回客戶端（通過重定向 URL）。
3. 獲取訪問令牌（Access Token）：客戶端使用授權(quán)碼向授權(quán)服務(wù)器請(qǐng)求訪問令牌。授權(quán)服務(wù)器驗(yàn)證授權(quán)碼，并返回訪問令牌。
4. 訪問資源：客戶端使用訪問令牌向資源服務(wù)器請(qǐng)求訪問受保護(hù)的資源。資源服務(wù)器驗(yàn)證訪問令牌，并返回請(qǐng)求的資源。

常見的授權(quán)流程

1. 授權(quán)碼流程（Authorization Code Flow）：最常用的授權(quán)流程，適用于需要與用戶交互的客戶端（如 Web 應(yīng)用）。用戶在授權(quán)服務(wù)器上登錄并授權(quán)，客戶端獲取授權(quán)碼后再交換訪問令牌。
2. 隱式流程（Implicit Flow）：適用于公共客戶端（如單頁應(yīng)用）。用戶直接獲得訪問令牌，適用于不需要安全存儲(chǔ)的情況，但不推薦用于高度安全的應(yīng)用。
3. 資源所有者密碼憑據(jù)流程（Resource Owner Password Credentials Flow）：適用于信任客戶端的情況。用戶直接將用戶名和密碼提供給客戶端，客戶端直接獲得訪問令牌。這種流程不推薦用于公開的客戶端。
4. 客戶端憑據(jù)流程（Client Credentials Flow）：適用于機(jī)器對(duì)機(jī)器的情況?？蛻舳酥苯酉蚴跈?quán)服務(wù)器請(qǐng)求訪問令牌，用于訪問與客戶端本身相關(guān)的資源。

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

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

• 靈活性：OAuth 2.0 支持多種授權(quán)流程，適應(yīng)不同類型的客戶端和應(yīng)用場(chǎng)景。
• 安全性：通過分離授權(quán)和認(rèn)證，增強(qiáng)了系統(tǒng)的安全性。使用令牌而不是用戶名密碼來訪問資源。

缺點(diǎn)

• 復(fù)雜性：OAuth 2.0 的實(shí)現(xiàn)和配置可能較復(fù)雜，需要正確管理訪問令牌和刷新令牌。
• 安全風(fēng)險(xiǎn)：如果令牌泄露，可能會(huì)導(dǎo)致安全風(fēng)險(xiǎn)。因此需要采取適當(dāng)?shù)陌踩胧ㄈ缡褂?HTTPS 和適當(dāng)?shù)牧钆乒芾聿呗裕?/li>

示例代碼

接下來，我們通過 Express 實(shí)現(xiàn)一個(gè)基本的 OAuth 2.0 驗(yàn)證示例

const express = require('express');
const axios = require('axios');
const app = express();

// OAuth 2.0 配置
const clientId = 'your-client-id';
const clientSecret = 'your-client-secret';
const redirectUri = 'http://localhost:3000/callback';
const authorizationServerUrl = 'https://authorization-server.com';
const resourceServerUrl = 'https://resource-server.com';

// 登錄路由，重定向到授權(quán)服務(wù)器
app.get('/login', (req, res) => {
  const authUrl = `${authorizationServerUrl}/authorize?response_type=code&client_id=${clientId}&redirect_uri=${redirectUri}&scope=read`;
  res.redirect(authUrl);
});

// 授權(quán)回調(diào)路由，處理授權(quán)碼
app.get('/callback', async (req, res) => {
  const { code } = req.query;
  if (!code) {
    return res.status(400).send('Authorization code is missing');
  }
  
  try {
    // 請(qǐng)求訪問令牌
    const response = await axios.post(`${authorizationServerUrl}/token`, {
      grant_type: 'authorization_code',
      code,
      redirect_uri: redirectUri,
      client_id: clientId,
      client_secret: clientSecret
    });
    
    const { access_token } = response.data;
    
    // 使用訪問令牌訪問資源
    const resourceResponse = await axios.get(`${resourceServerUrl}/user-info`, {
      headers: { Authorization: `Bearer ${access_token}` }
    });
    
    res.json(resourceResponse.data);
  } catch (error) {
    res.status(500).send('Error during token exchange or resource access');
  }
});

app.listen(3000, () => {
  console.log('服務(wù)器正在監(jiān)聽 3000 端口...');
});

總結(jié)一下

目前這四種驗(yàn)證方案均有對(duì)應(yīng)的 優(yōu)缺點(diǎn)、應(yīng)用場(chǎng)景：

• Session：非常適合簡單的服務(wù)器呈現(xiàn)的應(yīng)用程序
• JWT：適用于現(xiàn)代無狀態(tài)架構(gòu)和移動(dòng)應(yīng)用
• SSO：非常適合具有多種相關(guān)服務(wù)的企業(yè)環(huán)境
• OAuth 2.0：第三方集成和 API 訪問的首選