在2023年Q1 Go官方用戶(hù)調(diào)查報(bào)告[1]中，API/RPC services、Websites/web services都位于使用Go開(kāi)發(fā)的應(yīng)用類(lèi)別的頭部(如下圖)：

我個(gè)人使用Go開(kāi)發(fā)已很多年，但一直從事底層基礎(chǔ)設(shè)施、分布式中間件等方向，Web應(yīng)用開(kāi)發(fā)領(lǐng)域涉及較少，像Web應(yīng)用領(lǐng)域常見(jiàn)的CRUD更是少有涉獵，不能不說(shuō)是一種“遺憾”^_^。未來(lái)一段時(shí)間，團(tuán)隊(duì)會(huì)接觸到Web應(yīng)用的開(kāi)發(fā)，我打算對(duì)Go Web應(yīng)用開(kāi)發(fā)的重點(diǎn)環(huán)節(jié)做一個(gè)快速系統(tǒng)的梳理。

而身份認(rèn)證(Authentication，簡(jiǎn)稱(chēng)AuthN)是Web應(yīng)用開(kāi)發(fā)中一個(gè)關(guān)鍵的環(huán)節(jié)，也是首個(gè)環(huán)節(jié)，它負(fù)責(zé)驗(yàn)證用戶(hù)身份，讓用戶(hù)可以以認(rèn)證過(guò)的身份訪問(wèn)系統(tǒng)中的資源和信息。

Go語(yǔ)言作為一門(mén)優(yōu)秀的Web開(kāi)發(fā)語(yǔ)言，提供了豐富的機(jī)制來(lái)實(shí)現(xiàn)Web應(yīng)用的用戶(hù)身份認(rèn)證。在這篇文章中，我就通過(guò)Go示例和大家一起探討一下當(dāng)前Web應(yīng)用開(kāi)發(fā)中幾種常見(jiàn)的主流身份認(rèn)證方式，幫助自己和各位讀者邁出Web應(yīng)用開(kāi)發(fā)修煉之路的第一步。

1.身份認(rèn)證簡(jiǎn)介

1.1 身份認(rèn)證解決的問(wèn)題

身份認(rèn)證不局限于Web應(yīng)用，各種系統(tǒng)都會(huì)有身份認(rèn)證，但本文我們聚焦Web應(yīng)用領(lǐng)域的身份認(rèn)證技術(shù)。

幾乎所有Web應(yīng)用的安全性都是從身份認(rèn)證開(kāi)始的，身份認(rèn)證是驗(yàn)證用戶(hù)身份真實(shí)性的過(guò)程，是我們首先要部署的策略。位于下游的安全控制，如授權(quán)(Authorization, AuthZ)、審計(jì)日志(Audit log)等，幾乎都需要用戶(hù)的身份。

身份認(rèn)證的英文是Authentication，簡(jiǎn)寫(xiě)為AuthN，大家不要將之與授權(quán)Authorization(AuthZ)混淆(在后續(xù)系列文章中會(huì)繼續(xù)探討AuthZ相關(guān)的內(nèi)容)，他們所要解決的問(wèn)題相似，但有不同，也有先后。通常先AuthN，再AuthZ。我們可以用下面的比喻來(lái)形象地解釋二者的聯(lián)系與差異:

AuthN就像是進(jìn)入公司大樓的安檢，負(fù)責(zé)檢查員工的身份是否合法，是否具有進(jìn)入公司的資格，它解決的是驗(yàn)證員工身份的問(wèn)題。

AuthZ更像是公司內(nèi)部的權(quán)限管理，某個(gè)員工進(jìn)入了公司后(AuthN后)想訪問(wèn)一些重要資料，這時(shí)還需要確認(rèn)該員工是否有相應(yīng)的訪問(wèn)權(quán)限。它解決的是授權(quán)訪問(wèn)控制的問(wèn)題。

簡(jiǎn)單來(lái)說(shuō)，AuthN是驗(yàn)證你是誰(shuí)，authZ是驗(yàn)證你有哪些權(quán)限。AuthN解決認(rèn)證問(wèn)題，AuthZ解決授權(quán)問(wèn)題，這兩個(gè)都重要，AuthN解決外部的安全問(wèn)題，authZ解決內(nèi)部的安全與合規(guī)問(wèn)題。

1.2 身份認(rèn)證的三要素

身份認(rèn)證需要被認(rèn)證方提供一些身份信息輸入，這些代表身份信息的輸入被稱(chēng)為身份認(rèn)證要素（authentication factor）。這些要素有很多，大致可分為三類(lèi)：

• 你知道的東西(What you know)

即基于被認(rèn)證方知道的特定信息來(lái)驗(yàn)證身份，最常見(jiàn)的如密碼等。

• 你擁有的東西(What you have)

基于被認(rèn)證方所擁有的特定物件來(lái)驗(yàn)證身份，最常見(jiàn)的利用數(shù)字證書(shū)、令牌卡等。N年前，在移動(dòng)端應(yīng)用還沒(méi)有發(fā)展起來(lái)時(shí)，一些人在銀行辦理電子銀行業(yè)務(wù)時(shí)會(huì)拿到一個(gè)U盾(又稱(chēng)為USBKey)，其中存放著用于用戶(hù)身份識(shí)別的數(shù)字證書(shū)，這個(gè)U盾就屬于此類(lèi)要素。

上面比喻中進(jìn)入大樓時(shí)使用的員工卡也屬于這類(lèi)要素。

• 你本身就具有的(What you are)

即基于被認(rèn)證方所擁有的生物特征要素(biometric factor)來(lái)驗(yàn)證身份，最常見(jiàn)的人臉識(shí)別、指紋/聲紋/虹膜識(shí)別和解鎖等。理論上來(lái)說(shuō)，具備個(gè)人生物特征的身份認(rèn)證標(biāo)志具有不可仿冒性、唯一性。

如果上面比喻中的大樓已經(jīng)開(kāi)啟了人臉識(shí)別功能，那么基于人臉識(shí)別的認(rèn)證就屬于這類(lèi)要素的認(rèn)證。

通常我們會(huì)基于單個(gè)要素設(shè)計(jì)身份認(rèn)證方案，一旦使用兩個(gè)或兩個(gè)以上不同類(lèi)的要素，就可以被稱(chēng)為**雙因素認(rèn)證(2FA)[2]或多因素認(rèn)證(MFA)**了。不過(guò)，2FA和MFA都比較復(fù)雜，不再本篇文章討論范圍之內(nèi)。

基于上述要素，我們就可以設(shè)計(jì)和實(shí)現(xiàn)各種適合不同類(lèi)別Web應(yīng)用或API服務(wù)的身份認(rèn)證方法了。Web應(yīng)用和API服務(wù)都需要身份認(rèn)證，它們有什么差異呢？這些差異是否會(huì)對(duì)身份認(rèn)證方案產(chǎn)生影響呢？我們接下來(lái)看一下。

1.3 Web應(yīng)用身份認(rèn)證 vs. API服務(wù)身份認(rèn)證

Web應(yīng)用和API服務(wù)主要有以下幾點(diǎn)區(qū)別:

• 交互方式不同

Web應(yīng)用是瀏覽器與服務(wù)器之間的交互，用戶(hù)通過(guò)瀏覽器訪問(wèn)Web應(yīng)用。而API服務(wù)是程序/應(yīng)用與服務(wù)器之間的交互，通過(guò)API請(qǐng)求獲取數(shù)據(jù)或執(zhí)行操作。

• 返回?cái)?shù)據(jù)格式不同

Web應(yīng)用通常會(huì)返回html/js/css等瀏覽器可解析執(zhí)行的代碼，而API服務(wù)通常返回結(jié)構(gòu)化數(shù)據(jù)，常見(jiàn)的如JSON或XML等。

• 使用場(chǎng)景不同

Web應(yīng)用主要面向人類(lèi)用戶(hù)的使用，用戶(hù)通過(guò)瀏覽器進(jìn)行操作。而API服務(wù)主要被其他程序調(diào)用，為程序之間提供接口與數(shù)據(jù)支撐。

• 狀態(tài)管理不同

Web應(yīng)用在服務(wù)端保存會(huì)話狀態(tài)，瀏覽器通過(guò)cookie等保存用戶(hù)狀態(tài)。而API服務(wù)通常是無(wú)狀態(tài)的，每次請(qǐng)求都需要攜帶用于身份認(rèn)證的信息，比如訪問(wèn)令牌或API Key等。

• 安全方面的關(guān)注點(diǎn)不同

Web應(yīng)用更關(guān)注XSS[3]、CSRF[4]等輸入驗(yàn)證安全，而API服務(wù)更關(guān)注身份認(rèn)證(authN)、授權(quán)(authZ)、準(zhǔn)入(admission)、限流等訪問(wèn)控制安全。

總之，Web應(yīng)用注重界面的展示和用戶(hù)交互；而API服務(wù)注重?cái)?shù)據(jù)和服務(wù)的提供，它們有不同的使用場(chǎng)景、交互方式和安全關(guān)注點(diǎn)。

Web應(yīng)用和API服務(wù)的這些差異也導(dǎo)致了Web應(yīng)用和API服務(wù)適合使用的身份認(rèn)證方案上會(huì)有所不同。但前后端分離架構(gòu)的出現(xiàn)和普及，讓前后端責(zé)任分離：前端專(zhuān)注于視圖和交互，后端專(zhuān)注數(shù)據(jù)和業(yè)務(wù)，并且前后端通過(guò)標(biāo)準(zhǔn)化的API接口進(jìn)行數(shù)據(jù)交互。這可以讓后端提供統(tǒng)一的認(rèn)證接口，不同的前端可以共享。像基于Token這樣的無(wú)狀態(tài)易理解的身份驗(yàn)證機(jī)制逐漸成為主流。也就是說(shuō)，架構(gòu)模式的變化，使得Web應(yīng)用和API服務(wù)在身份驗(yàn)證(authN)方案上出現(xiàn)了一些融合的現(xiàn)象，因此在身份認(rèn)證方法上，Web應(yīng)用和API服務(wù)也存在一些交集。

下面維韋恩圖列出了三類(lèi)身份認(rèn)證方法，包括僅適用于Web應(yīng)用的、僅適用于API服務(wù)的以及兩者都適用的：

圖片

本文聚焦Web應(yīng)用的身份認(rèn)證方式，接下來(lái)會(huì)重點(diǎn)說(shuō)說(shuō)上圖中綠色背景色的幾種身份認(rèn)證方式。

2. 安全信道是身份認(rèn)證的前提和基礎(chǔ)

在對(duì)具體的Web身份認(rèn)證方式進(jìn)行說(shuō)明之前，我們先來(lái)了解一下身份認(rèn)證的前提和基礎(chǔ) - 安全信道。

在Web應(yīng)用身份認(rèn)證的過(guò)程中，無(wú)論采用何種認(rèn)證方式，用戶(hù)的身份要素信息(用戶(hù)名/密碼、token、生物特征信息)都要傳遞給服務(wù)器，這時(shí)候如果傳遞此類(lèi)信息的通信信道不安全，這些重要的認(rèn)證要素信息就很容易被中間人截取、破解、篡改并被冒充，從而獲得Web應(yīng)用的使用權(quán)。從服務(wù)端角度來(lái)看，如果沒(méi)有安全信道，服務(wù)器身份也容易被偽裝，導(dǎo)致用戶(hù)連接到“冒牌服務(wù)器”并導(dǎo)致嚴(yán)重后果。因此，沒(méi)有建立在安全信道上的身份認(rèn)證是不安全，不具備實(shí)際應(yīng)用價(jià)值的，甚至是完全沒(méi)有意義的。

此外，安全信道不僅對(duì)登錄階段的身份認(rèn)證環(huán)節(jié)有重要意義，在用戶(hù)已登錄并訪問(wèn)Web應(yīng)用其他功能頁(yè)面時(shí)，安全通道也可以對(duì)數(shù)據(jù)的傳輸以及類(lèi)似訪問(wèn)令牌或Cookie數(shù)據(jù)的傳輸起到加密和保護(hù)作用。

在Web應(yīng)用領(lǐng)域，最常用的安全信道建立方式是基于HTTPS(HTTP over TLS)或直接建立在TLS之上的自定義通信，TLS利用證書(shū)對(duì)通信進(jìn)行加密、驗(yàn)證服務(wù)器身份（甚至是客戶(hù)端身份的驗(yàn)證），保障信息的機(jī)密性和完整性。各大安全規(guī)范和標(biāo)準(zhǔn)如PCI DSS(Payment Card Industry Data Security Standard)[5]、OWASP[6]也強(qiáng)制要求使用HTTPS保障認(rèn)證安全。

基于安全信道，我們還可以實(shí)施第一波的身份認(rèn)證，這就是我們通常所說(shuō)的基于HTTPS(或TLS)的雙向身份認(rèn)證。

注：在我的《Go語(yǔ)言精進(jìn)之路vol2》[7]一書(shū)中，對(duì)TLS的機(jī)制以及基于Go標(biāo)準(zhǔn)庫(kù)的TLS的雙向認(rèn)證[8]有系統(tǒng)全面的說(shuō)明，歡迎各位童鞋閱讀反饋。

這種認(rèn)證方式采用的是身份認(rèn)證要素中的第二類(lèi)要素：What you have。客戶(hù)端帶著歸屬于自己的專(zhuān)有證書(shū)去服務(wù)端做身份驗(yàn)證。如果client證書(shū)通過(guò)服務(wù)端的驗(yàn)簽后，便可允許client進(jìn)入“大樓”。

下面是一個(gè)基于TLS證書(shū)做身份認(rèn)證的客戶(hù)端與服務(wù)端交互的示意圖：

圖片

我們先看看對(duì)應(yīng)上述示意圖中的客戶(hù)端的代碼：

// authn-examples/tls-authn/client/main.go

func main() {

 // 1. 讀取客戶(hù)端證書(shū)文件
 clientCert, err := tls.LoadX509KeyPair("client-cert.pem", "client-key.pem")
 if err != nil {
  log.Fatal(err)
 }

 // 2. 讀取中間CA證書(shū)文件
 caCert, err := os.ReadFile("inter-cert.pem")
 if err != nil {
  log.Fatal(err)
 }
 certPool := x509.NewCertPool()
 certPool.AppendCertsFromPEM(caCert)

 // 3. 發(fā)送請(qǐng)求

 client := &http.Client{
  Transport: &http.Transport{
   TLSClientConfig: &tls.Config{
    Certificates: []tls.Certificate{clientCert},
    RootCAs:      certPool,
   },
  },
 }

 req, err := http.NewRequest("GET", "https://server.com:8443", nil)
 if err != nil {
  log.Fatal(err)
 }
 resp, err := client.Do(req)
 if err != nil {
  log.Fatal(err)
 }

 // 4. 打印響應(yīng)信息
 fmt.Println("Response Status:", resp.Status)
 // fmt.Println("Response Headers:", resp.Header)
 body, _ := io.ReadAll(resp.Body)
 fmt.Println("Response Body:", string(body))
}

客戶(hù)端加載client-cert.pem作為后續(xù)與服務(wù)端通信的身份憑證，加載inter-cert.pem用于校驗(yàn)服務(wù)端在tls握手過(guò)程發(fā)來(lái)的服務(wù)端證書(shū)(server-cert.pem)，避免連接到“冒牌站點(diǎn)”。通過(guò)驗(yàn)證后，客戶(hù)端向服務(wù)端發(fā)起Get請(qǐng)求并輸出響應(yīng)的內(nèi)容。

下面是服務(wù)端的代碼：

// authn-examples/tls-authn/server/main.go

func main() {
 var validClients = map[string]struct{}{
  "client.com": struct{}{},
 }

 // 1. 加載證書(shū)文件
 cert, err := tls.LoadX509KeyPair("server-cert.pem", "server-key.pem")
 if err != nil {
  log.Fatal(err)
 }

 caCert, err := os.ReadFile("inter-cert.pem")
 if err != nil {
  log.Fatal(err)
 }
 certPool := x509.NewCertPool()
 certPool.AppendCertsFromPEM(caCert)

 // 2. 配置TLS
 tlsConfig := &tls.Config{
  Certificates: []tls.Certificate{cert},
  ClientAuth:   tls.RequireAndVerifyClientCert, // will trigger the invoke of VerifyPeerCertificate
  ClientCAs:    certPool,
 }

 // tls.Config設(shè)置
 tlsConfig.VerifyPeerCertificate = func(rawCerts [][]byte, verifiedChains [][]*x509.Certificate) error {
  // 獲取客戶(hù)端證書(shū)
  cert := verifiedChains[0][0]

  // 提取CN作為客戶(hù)端標(biāo)識(shí)
  clientID := cert.Subject.CommonName
  fmt.Println(clientID)

  _, ok := validClients[clientID]
  if !ok {
   return errors.New("invalid client id")
  }

  return nil
 }
 // 添加處理器
 http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
  w.Write([]byte("Hello World!"))
 })

 // 3. 創(chuàng)建服務(wù)器
 srv := &http.Server{
  Addr:      ":8443",
  TLSConfig: tlsConfig,
 }

 // 4. 啟動(dòng)服務(wù)器
 err = srv.ListenAndServeTLS("", "")
 if err != nil {
  log.Fatal(err)
 }
}

注：在你的實(shí)驗(yàn)環(huán)境中，需要在/etc/hosts文件中添加server.com的映射ip為127.0.0.1。

服務(wù)端代碼也不復(fù)雜，比較“套路化”：加載服務(wù)端證書(shū)和中間CA證書(shū)(用于驗(yàn)簽client端的證書(shū))，這里將tls.Config.ClientAuth設(shè)置為RequireAndVerifyClientCert，這會(huì)觸發(fā)服務(wù)端對(duì)客戶(hù)端證書(shū)的驗(yàn)簽，同時(shí)在tlsConfig.VerifyPeerCertificate不為nil的情況下，觸發(fā)對(duì)tlsConfig.VerifyPeerCertificate的函數(shù)的調(diào)用，在示例代碼中，我們?yōu)閠lsConfig.VerifyPeerCertificate賦值了一個(gè)匿名函數(shù)實(shí)現(xiàn)，在這個(gè)函數(shù)中，我們提取了客戶(hù)端證書(shū)中的客戶(hù)端標(biāo)識(shí)CN，并查看其是否在可信任的客戶(hù)端ID表中。

在這個(gè)示例中，這個(gè)tlsConfig.VerifyPeerCertificate執(zhí)行的驗(yàn)證有些多余，但我們?cè)趯?shí)際代碼中可以使用tlsConfig.VerifyPeerCertificate來(lái)設(shè)置黑名單，攔截那些尚未過(guò)期、但可以驗(yàn)簽通過(guò)的客戶(hù)端，實(shí)現(xiàn)一種客戶(hù)端證書(shū)過(guò)期前的作廢機(jī)制。

此外，上述示例中客戶(hù)端、服務(wù)端以及中間CA證書(shū)的制作代碼與《Go TLS服務(wù)端綁定證書(shū)的幾種方式》[9]一文中的證書(shū)制作很類(lèi)似，大家可以直接參考本文示例代碼中的tls-authn/make-certs下面的代碼，這里就不贅述了。

通過(guò)這種基于安全信道的身份驗(yàn)證方式，客戶(hù)端證書(shū)可以強(qiáng)制認(rèn)證用戶(hù)，理論上不需要額外再用用戶(hù)名密碼。認(rèn)證之后客戶(hù)端在這個(gè)TLS連接上發(fā)送的所有信息都將綁定其身份。

不過(guò)通過(guò)頒發(fā)客戶(hù)端專(zhuān)用證書(shū)的方式僅適合一些像網(wǎng)絡(luò)銀行之類(lèi)的專(zhuān)有業(yè)務(wù)，大多數(shù)Web應(yīng)用會(huì)與客戶(hù)端間建立安全信道，但不會(huì)采用客戶(hù)端證書(shū)來(lái)認(rèn)證用戶(hù)身份，在這樣的情況下，下面要說(shuō)的這些身份認(rèn)證方式就可以發(fā)揮作用了。

我們先來(lái)看一下最傳統(tǒng)的基于密碼的認(rèn)證。

3. 基于密碼的認(rèn)證

基于密碼的認(rèn)證屬于基于第一類(lèi)身份認(rèn)證要素：你知道的東西(What you know)的認(rèn)證方式，這類(lèi)認(rèn)證也是Web應(yīng)用中最經(jīng)典、最常見(jiàn)的認(rèn)證方式。我們先從基于傳統(tǒng)表單承載用戶(hù)名/密碼說(shuō)起。

3.1. 基于用戶(hù)名+密碼的認(rèn)證(傳統(tǒng)表單方式)

這是最常見(jiàn)的Web應(yīng)用認(rèn)證方式：用戶(hù)通過(guò)提交包含用戶(hù)名和密碼的表單(Form)，服務(wù)端Web應(yīng)用進(jìn)行驗(yàn)證。下面使用這種方式的客戶(hù)端與服務(wù)單的交互示意圖：

圖片

接下來(lái)，我們看看對(duì)應(yīng)上述示意圖的實(shí)現(xiàn)代碼。我們先建立一個(gè)html文件，該文件非常簡(jiǎn)單，就是一個(gè)可輸入用戶(hù)名和密碼的表單，點(diǎn)擊登錄按鈕將表單信息發(fā)送到服務(wù)端：

// authn-examples/password/classic/login.html

<!DOCTYPE html>
<html>
<head>
  <title>登錄</title>
</head>
<body>

<form actinotallow="http://server.com:8080/login" method="post">

  <label>用戶(hù)名:</label>
  <input type="text" name="username"/>

  <label>密碼:</label>
  <input type="password" name="password"/>

  <button type="submit">登錄</button>

</form>

</body>
</html>

發(fā)送的HTTP Post請(qǐng)求的包體(Body)中會(huì)包含頁(yè)面輸入的username和password的值，形式如下：

username=admin&password=123456

而我們的服務(wù)端的代碼如下：

// authn-examples/password/classic/main.go

func main() {
    http.HandleFunc("/login", login)
    http.ListenAndServe(":8080", nil)
}

func login(w http.ResponseWriter, r *http.Request) {
    username := r.FormValue("username")
    password := r.FormValue("password")

    if isValidUser(username, password) {
        w.Write([]byte("Welcome!"))
        return
    }

    http.Error(w, "Invalid username or password", http.StatusUnauthorized) // 401
}

var credentials = map[string]string{
    "admin": "123456",
}

func isValidUser(username, password string) bool {
    // 驗(yàn)證用戶(hù)名密碼
    v, ok := credentials[username]
    if !ok {
        return false
    }

    if v != password {
        return false
    }
    return true
}

服務(wù)端通過(guò)Request的FormValue方法獲得username和password的值，并與credentials存儲(chǔ)的合法用戶(hù)信息比對(duì)(當(dāng)然這只是演示代碼中的臨時(shí)手段，生產(chǎn)中不要這么存儲(chǔ)用戶(hù)信息)，比對(duì)成功，返回"Welcome"應(yīng)答；比對(duì)失敗，返回401 Unauthorized錯(cuò)誤。

注：包括本示例在內(nèi)的后續(xù)所有示例的客戶(hù)端和服務(wù)端都在非安全信道上通信，目的是簡(jiǎn)化示例代碼的編寫(xiě)。大家在生產(chǎn)環(huán)境務(wù)必建立安全信道后再做后續(xù)的身份驗(yàn)證。

基于傳統(tǒng)的表單用戶(hù)名和密碼可以作為Web應(yīng)用服務(wù)端身份驗(yàn)證的方案，但問(wèn)題來(lái)了：服務(wù)端認(rèn)證成功后，用戶(hù)后續(xù)向Web應(yīng)用服務(wù)端發(fā)起的請(qǐng)求是否還要繼續(xù)帶上用戶(hù)和密碼信息呢？如果不帶上用戶(hù)和密碼信息，服務(wù)端又如何驗(yàn)證這些請(qǐng)求是來(lái)自之前已經(jīng)認(rèn)證成功后的用戶(hù)；如果后續(xù)每個(gè)請(qǐng)求都帶上以Form形式承載的用戶(hù)名和密碼，使用起來(lái)又非常不方便，還影響后續(xù)請(qǐng)求的正常數(shù)據(jù)的傳輸(對(duì)Body數(shù)據(jù)有侵入)。

于是便有了Session(會(huì)話)機(jī)制，它可以被認(rèn)為是基于經(jīng)典的用戶(hù)名密碼(表單承載)認(rèn)證方式的“延續(xù)”，使得密碼認(rèn)證的成果不再局限在缺乏連續(xù)性的單一請(qǐng)求級(jí)別上，而是擴(kuò)展到后續(xù)的一段時(shí)間內(nèi)或一系列與Web應(yīng)用的互操作過(guò)程中，變成了連續(xù)、持久的登錄會(huì)話。

接下來(lái)，我們就來(lái)簡(jiǎn)單看看基于Session的后續(xù)認(rèn)證方式是如何工作的。

3.2 使用Session：有狀態(tài)的認(rèn)證方式

基于Session的認(rèn)證方式是一種有狀態(tài)的方案，服務(wù)端會(huì)為每個(gè)身份認(rèn)證成功的用戶(hù)建立并保存相關(guān)session信息，同時(shí)服務(wù)端也會(huì)要求客戶(hù)端在瀏覽器側(cè)持久化與該Session有關(guān)少量信息，通?？蛻?hù)端會(huì)通過(guò)開(kāi)啟Cookie的方式來(lái)保存與用戶(hù)Session相關(guān)的信息。

服務(wù)端保存Session有多種方式，可以在進(jìn)程內(nèi)存中、文件中、數(shù)據(jù)庫(kù)、緩存(Redis)等，不同方式各有優(yōu)缺點(diǎn)，比如將Session保存在內(nèi)存中，最大的好處就是實(shí)現(xiàn)簡(jiǎn)單且速度快，但由于不能持久化，服務(wù)實(shí)例重啟后就會(huì)丟失，此外當(dāng)服務(wù)端有多副本時(shí)，session信息無(wú)法在多實(shí)例共享；使用關(guān)系數(shù)據(jù)庫(kù)來(lái)保存session，可以方便持久化，也方便與服務(wù)端多實(shí)例用戶(hù)數(shù)據(jù)共享，但數(shù)據(jù)庫(kù)交互成本較大；而使用緩存(Redis)存儲(chǔ)session信息是目前比較主流的方式，簡(jiǎn)單、安全、快速，還可以很好地適合分布式環(huán)境下session的共享。

下面是一個(gè)常見(jiàn)的基于cookie實(shí)現(xiàn)的session機(jī)制的客戶(hù)端與服務(wù)端的交互示意圖：

圖片

這里也給出上述示意圖的一個(gè)參考實(shí)現(xiàn)示例（代碼僅用作演示，很多值設(shè)置并不規(guī)范和安全，不要用于生產(chǎn)）。

session機(jī)制的開(kāi)啟從用戶(hù)登錄開(kāi)始，這個(gè)示例里的login.html與上一個(gè)示例是一樣的：

// authn-examples/password/session/login.html

<!DOCTYPE html>
<html>
<head>
  <title>登錄</title>
</head>
<body>

<form actinotallow="http://server.com:8080/login" method="post">

  <label>用戶(hù)名:</label>
  <input type="text" name="username"/>

  <label>密碼:</label>
  <input type="password" name="password"/>

  <button type="submit">登錄</button>
  
</form>

</body>
</html>

服務(wù)端負(fù)責(zé)的login Handler代碼如下：

// authn-examples/password/session/main.go

var store = sessions.NewCookieStore([]byte("session-key"))

func main() {
 http.HandleFunc("/login", login)
 http.HandleFunc("/calc", calc)
 http.HandleFunc("/calcAdd", calcAdd)

 http.ListenAndServe(":8080", nil)
}

var credentials = map[string]string{
 "admin": "123456",
 "test":  "654321",
}

func isValid(username, password string) bool {
 // 驗(yàn)證用戶(hù)名密碼
 v, ok := credentials[username]
 if !ok {
  return false
 }

 if v != password {
  return false
 }
 return true
}

func base64Encode(src string) string {
 encoded := base64.StdEncoding.EncodeToString([]byte(src))
 return encoded
}

func base64Decode(encoded string) string {
 decoded, _ := base64.StdEncoding.DecodeString(encoded)
 return string(decoded)
}

func randomStr() string {
 // 生成隨機(jī)數(shù)
 rand.Seed(time.Now().UnixNano())
 random := rand.Intn(100000)

 // 格式化為05位字符串
 str := fmt.Sprintf("%05d", random)

 return str
}

func login(w http.ResponseWriter, r *http.Request) {
 username := r.FormValue("username")
 password := r.FormValue("password")

 if isValid(username, password) {
  session, err := store.Get(r, "server.com_"+username)
  if err != nil {
   fmt.Println("get session from session store error:", err)
   http.Error(w, "Internal error", http.StatusInternalServerError)
  }

  // 設(shè)置session數(shù)據(jù)
  random := randomStr()
  usernameB64 := base64Encode(username + "-" + random)
  session.Values["random"] = random
  session.Save(r, w)

  // 設(shè)置cookie
  cookie := http.Cookie{Name: "server.com-session", Value: usernameB64}
  http.SetCookie(w, &cookie)

  // 登錄成功,跳轉(zhuǎn)到calc頁(yè)面
  http.Redirect(w, r, "/calc", http.StatusSeeOther)
 } else {
  http.Error(w, "Invalid username or password", http.StatusUnauthorized) // 401
 }
}

我們使用了gorilla/sessions這個(gè)Go社區(qū)廣泛使用的session庫(kù)來(lái)實(shí)現(xiàn)服務(wù)端session的相關(guān)操作。以admin用戶(hù)登錄為例，當(dāng)用戶(hù)名和密碼認(rèn)證成功后，我們?cè)趕ession store中創(chuàng)建一個(gè)新的session：server.com_admin。然后生成一個(gè)隨機(jī)數(shù)，將隨機(jī)數(shù)存儲(chǔ)在該session的名為"random"的key的下面。之后，讓客戶(hù)端設(shè)置cookie，name為server.com-session。值為username和random按特定格式組合后的base64編碼值。

登錄成功后，瀏覽器會(huì)跳到calc頁(yè)面，這里我們輸入兩個(gè)整數(shù)，并點(diǎn)擊"calc"按鈕提交，提交動(dòng)作會(huì)發(fā)送請(qǐng)求到calcAdd Handler中：

// authn-examples/password/session/main.go

func calcAdd(w http.ResponseWriter, r *http.Request) {
 // 1. 獲取Cookie中的Session
 cookie, err := r.Cookie("server.com-session")
 if err != nil {
  http.Error(w, "找不到cookie，請(qǐng)重新登錄", 401)
  return
 }
 fmt.Printf("found cookie: %#v\n", cookie)

 // 2. 獲取Session對(duì)象
 usernameB64 := cookie.Value
 usernameWithRandom := base64Decode(usernameB64)

 ss := strings.Split(usernameWithRandom, "-")
 username := ss[0]
 random := ss[1]
 session, err := store.Get(r, "server.com_"+username)
 if err != nil {
  http.Error(w, "找不到session, 請(qǐng)重新登錄", 401)
  return
 }

 randomInSs := session.Values["random"]
 if random != randomInSs {
  http.Error(w, "session中信息不匹配, 請(qǐng)重新登錄", 401)
  return
 }

 // 3. 轉(zhuǎn)換為整型參數(shù)
 a, err := strconv.Atoi(r.FormValue("a"))
 if err != nil {
  http.Error(w, "參數(shù)錯(cuò)誤", 400)
  return
 }

 b, err := strconv.Atoi(r.FormValue("b"))
 if err != nil {
  http.Error(w, "參數(shù)錯(cuò)誤", 400)
  return
 }

 // 4. 計(jì)算并返回結(jié)果
 result := a + b
 w.Write([]byte(fmt.Sprintf("%d", result)))
}

calcAdd Handler會(huì)提取Cookie "server.com-session"中的值，根據(jù)值信息查找服務(wù)端本地是否存儲(chǔ)了對(duì)應(yīng)的session，并校驗(yàn)與session中存儲(chǔ)的隨機(jī)碼是否一致。驗(yàn)證通過(guò)后，直接返回結(jié)算結(jié)果；否則提醒客戶(hù)端重新登錄。

前面說(shuō)過(guò)，session是一種有狀態(tài)的輔助身份認(rèn)證機(jī)制，需要客戶(hù)端和服務(wù)端的配合完成，一旦客戶(hù)端禁用了Cookie機(jī)制，上述的示例實(shí)現(xiàn)就失效了。當(dāng)然有讀者會(huì)說(shuō)，Session可以不基于Cookie來(lái)實(shí)現(xiàn)，可以用URL重寫(xiě)、隱藏表單字段、將Session ID放入U(xiǎn)RL路徑等方式來(lái)實(shí)現(xiàn)，客戶(hù)端也可以用LocalStorage等前端存儲(chǔ)機(jī)制來(lái)替代Cookie。但無(wú)論哪種實(shí)現(xiàn)，這種有狀態(tài)機(jī)制帶來(lái)的復(fù)雜性都不低，并且在分布式環(huán)境中需要session共享和同步機(jī)制，影響了scaling。

隨著微服務(wù)架構(gòu)的廣泛使用，無(wú)需在服務(wù)端存儲(chǔ)額外信息、天然支持后端服務(wù)分布式多實(shí)例的無(wú)狀態(tài)的連續(xù)身份認(rèn)證機(jī)制受到了更多的青睞。

其實(shí)基于HTTP的無(wú)狀態(tài)認(rèn)證機(jī)制早已有之，最常見(jiàn)的莫過(guò)于Basic Auth了，接下來(lái)，我們就從Basic Auth開(kāi)始，說(shuō)幾種無(wú)狀態(tài)身份認(rèn)證機(jī)制。

3.3 Basic Auth：最早的無(wú)狀態(tài)認(rèn)證方式

Basic Auth是HTTP最原始的身份驗(yàn)證方式，在HTTP1.0規(guī)范中就已存在，其原因是HTTP是無(wú)狀態(tài)協(xié)議，每次請(qǐng)求都需要進(jìn)行身份驗(yàn)證才能訪問(wèn)受保護(hù)資源。

Basic Auth的原理也十分簡(jiǎn)單，客戶(hù)端與服務(wù)端的交互如下圖：

圖片

Basic Auth通過(guò)在客戶(hù)端的請(qǐng)求報(bào)文中添加HTTP Authorization Header的形式向服務(wù)器端發(fā)送認(rèn)證憑據(jù)。HTTP Authorization Header的構(gòu)建通常分兩步。

• 將“username:password”的組合字符串進(jìn)行Base64編碼，編碼值記作b64Token。
• 將Authorization: Basic b64Token作為HTTP header的一個(gè)字段發(fā)送給服務(wù)器端。

服務(wù)端收到請(qǐng)請(qǐng)求后提取出Authorization字段并做Base64解碼，得到username和password，然后與存儲(chǔ)的信息作比對(duì)進(jìn)行客戶(hù)端身份認(rèn)證。

我們來(lái)看一個(gè)與上圖對(duì)應(yīng)的示例的代碼，先看客戶(hù)端：

// authn-examples/password/basic/client/main.go

func main() {
 client := &http.Client{}
 req, _ := http.NewRequest("POST", "http://server.com:8080/", nil)

 // 發(fā)送默認(rèn)請(qǐng)求
 response, err := client.Do(req)
 if err != nil {
  fmt.Println(err)
  return
 }

 // 解析響應(yīng)頭
 authHeader := response.Header.Get("WWW-Authenticate")
 loginReq, _ := http.NewRequest("POST", "http://server.com:8080/login", nil)
 username := "admin"
 password := "123456"

 // 判斷認(rèn)證類(lèi)型
 if !strings.Contains(authHeader, "Basic") {
  // 不支持的認(rèn)證類(lèi)型
  fmt.Println("Unsupported authentication type:", authHeader)
  return
 }

 // 使用Basic Auth, 添加Basic Auth頭
 loginReq.SetBasicAuth(username, password)
 response, err = client.Do(loginReq)

 // 打印響應(yīng)狀態(tài)
 fmt.Println(response.StatusCode)

 // 打印響應(yīng)包體
 defer response.Body.Close()
 body, err := io.ReadAll(response.Body)
 if err != nil {
  fmt.Println(err)
  return
 }
 fmt.Println(string(body))
}

客戶(hù)端的代碼比較簡(jiǎn)單，并且流程與圖中的交互流程是完全一樣的。而服務(wù)端就是一個(gè)簡(jiǎn)單的http server，對(duì)來(lái)自客戶(hù)端的帶有basic auth的請(qǐng)求進(jìn)行身份認(rèn)證：

// authn-examples/password/basic/server/main.go

func main() {
 // 創(chuàng)建一個(gè)基本的HTTP服務(wù)器
 mux := http.NewServeMux()

 username := "admin"
 password := "123456"

 // 針對(duì)/的handler
 mux.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
  // 返回401 Unauthorized響應(yīng)
  w.Header().Set("WWW-Authenticate", "Basic realm=\"server.com\"")
  w.WriteHeader(http.StatusUnauthorized)
 })

 // login handler
 mux.HandleFunc("/login", func(w http.ResponseWriter, req *http.Request) {
  // 從請(qǐng)求頭中獲取Basic Auth認(rèn)證信息
  user, pass, ok := req.BasicAuth()
  if !ok {
   // 認(rèn)證失敗
   w.WriteHeader(http.StatusUnauthorized)
   return
  }

  // 驗(yàn)證用戶(hù)名密碼
  if user == username && pass == password {
   // 認(rèn)證成功
   w.WriteHeader(http.StatusOK)
   w.Write([]byte("Welcome to the protected resource!"))
  } else {
   // 認(rèn)證失敗
   http.Error(w, "Invalid username or password", http.StatusUnauthorized)
  }
 })

 // 監(jiān)聽(tīng)8080端口
 err := http.ListenAndServe(":8080", mux)
 if err != nil {
  log.Fatal(err)
 }
}

采用Basic Auth身份認(rèn)證方案的客戶(hù)端在每個(gè)請(qǐng)求中都要在Header中加上Basic Auth形式的身份信息，但服務(wù)端無(wú)需像Session那樣存儲(chǔ)任何額外的信息。

不過(guò)很顯然，Basic Auth這種采用明文傳輸身份信息的方式在安全性方面飽受詬病，為了避免在Header傳輸明文的安全問(wèn)題，RFC 2617(以及后續(xù)更新版RFC 7616)定義了HTTP Digest身份認(rèn)證方式。Digest訪問(wèn)認(rèn)證不再明文傳輸密碼，而是傳遞用hash算法處理后密碼摘要，相對(duì)Basic Auth驗(yàn)證安全性更高。接下來(lái)，我們就來(lái)看看HTTP Digest認(rèn)證方式。

3.4 基于HTTP Digest認(rèn)證

Digest是一種HTTP摘要認(rèn)證，你可以把它看作是Basic Auth的改良版本，針對(duì)Base64明文發(fā)送的風(fēng)險(xiǎn)，Digest認(rèn)證把用戶(hù)名和密碼加鹽（一個(gè)被稱(chēng)為Nonce的隨機(jī)值作為鹽值）后，再通過(guò)MD5/SHA等哈希算法取摘要放到請(qǐng)求的Header中發(fā)送出去。Digest的認(rèn)證過(guò)程如下圖：

圖片

相對(duì)于Basic Auth，Digest Auth的一些值的生成過(guò)程還是略復(fù)雜的，這里給出一個(gè)示例性質(zhì)的代碼示例，可能不完全符合Digest規(guī)范，大家通過(guò)示例理解Digest的認(rèn)證過(guò)程就可以了。

注：如要使用符合RFC 7616的Digest規(guī)范（或老版RFC 2617規(guī)范)，可以找一些第三方包，比如https://github.com/abbot/go-http-auth（只滿(mǎn)足RFC 2617）。

// authn-examples/password/digest/client/main.go

func main() {
 client := &http.Client{}
 req, _ := http.NewRequest("POST", "http://server.com:8080/", nil)

 // 發(fā)送默認(rèn)請(qǐng)求
 response, err := client.Do(req)
 if err != nil {
  fmt.Println(err)
  return
 }

 // 解析響應(yīng)頭
 authHeader := response.Header.Get("WWW-Authenticate")
 loginReq, _ := http.NewRequest("POST", "http://server.com:8080/login", nil)
 username := "admin"
 password := "123456"

 // 判斷認(rèn)證類(lèi)型
 if !strings.Contains(authHeader, "Digest") {
  // 不支持的認(rèn)證類(lèi)型
  fmt.Println("Unsupported authentication type:", authHeader)
  return
 }

 // 使用Digest Auth

 //隨機(jī)數(shù)
 cnonce := GenNonce()

 //生成HA1
 ha1 := GetHA1(username, password, cnonce)

 //構(gòu)建Authorization頭
 auth := "Digest username=\"" + username + "\", nnotallow=\"" + cnonce + "\", algorithm=MD5, respnotallow=\"" + GetResponse(ha1, cnonce) + "\""

 loginReq.Header.Set("Authorization", auth)
 response, err = client.Do(loginReq)

 // 打印響應(yīng)狀態(tài)
 fmt.Println(response.StatusCode)

 // 打印響應(yīng)包體
 defer response.Body.Close()
 body, err := io.ReadAll(response.Body)
 if err != nil {
  fmt.Println(err)
  return
 }
 fmt.Println(string(body))
}

// 生成隨機(jī)數(shù)
func GenNonce() string {
 h := md5.New()
 io.WriteString(h, fmt.Sprint(rand.Int()))
 return hex.EncodeToString(h.Sum(nil))
}

// 根據(jù)用戶(hù)名密碼和隨機(jī)數(shù)生成HA1
func GetHA1(username, password, cnonce string) string {
 h := md5.New()
 io.WriteString(h, username+":"+cnonce+":"+password)
 return hex.EncodeToString(h.Sum(nil))
}

// 根據(jù)HA1,隨機(jī)數(shù)生成response
func GetResponse(ha1, cnonce string) string {
 h := md5.New()
 io.WriteString(h, strings.ToUpper("md5")+":"+ha1+":"+cnonce+"::"+strings.ToUpper("md5"))
 return hex.EncodeToString(h.Sum(nil))
}

客戶(hù)端使用username、password和隨機(jī)數(shù)生成摘要以及一個(gè)response碼，并通過(guò)請(qǐng)求的頭Authorization字段發(fā)給服務(wù)端。

服務(wù)端解析Authorization字段中的各個(gè)值，然后采用同樣的算法算出一個(gè)新response，與請(qǐng)求中的response比對(duì)，如果一致，則認(rèn)為認(rèn)證成功：

// authn-examples/password/digest/server/main.go

func main() {
 mux := http.NewServeMux()

 password := "123456"

 // 針對(duì)/的handler
 mux.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
  // 返回401 Unauthorized響應(yīng)
  w.Header().Set("WWW-Authenticate", "Digest realm=\"server.com\"")
  w.WriteHeader(http.StatusUnauthorized)
 })

 // login handler
 mux.HandleFunc("/login", func(w http.ResponseWriter, req *http.Request) {
  fmt.Println(req.Header)

  //驗(yàn)證參數(shù)
  if Verify(req, password) {
   fmt.Fprintln(w, "Verify Success!")
  } else {
   w.WriteHeader(401)
   fmt.Fprintln(w, "Verify Failed!")
  }
 })

 // 監(jiān)聽(tīng)8080端口
 err := http.ListenAndServe(":8080", mux)
 if err != nil {
  log.Fatal(err)
 }
}

func Verify(r *http.Request, password string) bool {
 auth := r.Header.Get("Authorization")
 params := strings.Split(auth, ",")
 var username, cnonce, response string

 for _, p := range params {
  p := strings.Trim(p, " ")
  kv := strings.Split(p, "=")
  if kv[0] == "Digest username" {
   username = strings.Trim(kv[1], "\"")
  }
  if kv[0] == "nonce" {
   cnonce = strings.Trim(kv[1], "\"")
  }
  if kv[0] == "response" {
   response = strings.Trim(kv[1], "\"")
  }
 }

 if username == "" {
  return false
 }

 //根據(jù)用戶(hù)名密碼及隨機(jī)數(shù)生成HA1
 ha1 := GetHA1(username, password, cnonce)

 //自己生成response與請(qǐng)求中response對(duì)比
 return response == GetResponse(ha1, cnonce)
}

雖然實(shí)現(xiàn)了無(wú)狀態(tài)，安全性也高于Basic Auth，但Digest方式的用戶(hù)體驗(yàn)依然有限：每次向服務(wù)端發(fā)送請(qǐng)求，客戶(hù)端都要進(jìn)行一次復(fù)雜計(jì)算，服務(wù)端也要再做一次相同的驗(yàn)算和比對(duì)。

那么是否有一種體驗(yàn)更為良好的無(wú)狀態(tài)身份認(rèn)證方式呢？我們接下來(lái)看看基于Token的認(rèn)證方式。

4. 無(wú)狀態(tài)：基于Token的認(rèn)證

基于Token的認(rèn)證方式的備受青睞得益于Web領(lǐng)域前后端分離架構(gòu)的發(fā)展以及微服務(wù)架構(gòu)的流行，在API調(diào)用和網(wǎng)站間需要輕量級(jí)的認(rèn)證機(jī)制來(lái)傳遞用戶(hù)信息。Token認(rèn)證機(jī)制正好滿(mǎn)足這一需求，而JWT(JSON Web Token)[10]是目前Token格式標(biāo)準(zhǔn)中使用最廣的一種。

4.1 JWT原理

JWT由頭部(Header)、載荷(Payload)和簽名(Signature)三部分組成，三部分之間用圓點(diǎn)連接，其形式如下：

xxxxx.yyyyy.zzzzz

一個(gè)真實(shí)的JWT token的例子如下面來(lái)自jwt.io[11]站點(diǎn)的截圖)：

圖片

JWT token的生成過(guò)程也非常清晰，下圖展示了上述截圖中jwt token的生成過(guò)程：

圖片

如果你不想依賴(lài)第三方庫(kù)，也可以自己實(shí)現(xiàn)生成token的函數(shù)，下面是一個(gè)示例：

// authn-examples/jwt/scratch/main.go

package main

import (
 "crypto/hmac"
 "crypto/sha256"
 "encoding/base64"
 "encoding/json"
 "fmt"
)

type Header struct {
 Alg string `json:"alg"`
 Typ string `json:"typ"`
}

type Claims struct {
 Sub  string `json:"sub"`
 Name string `json:"name"`
 Iat  int64  `json:"iat"`
}

// GenerateToken：不依賴(lài)第三方庫(kù)的JWT生成實(shí)現(xiàn)
func GenerateToken(claims *Claims, key string) (string, error) {
 header, _ := json.Marshal(Header{
  Alg: "HS256",
  Typ: "JWT",
 })
 // 序列化Payload
 payload, err := json.Marshal(claims)
 if err != nil {
  return "", err
 }

 // 拼接成JWT字符串
 headerEncoded := base64.RawURLEncoding.EncodeToString(header)
 payloadEncoded := base64.RawURLEncoding.EncodeToString([]byte(payload))

 encodedToSign := headerEncoded + "." + payloadEncoded

 // 使用HMAC+SHA256簽名
 hash := hmac.New(sha256.New, []byte(key))
 hash.Write([]byte(encodedToSign))
 sig := hash.Sum(nil)
 sigEncoded := base64.RawURLEncoding.EncodeToString(sig)

 var token string
 token += headerEncoded
 token += "."
 token += payloadEncoded
 token += "."
 token += sigEncoded

 return token, nil
}

func main() {
 var claims = &Claims{
  Sub:  "1234567890",
  Name: "John Doe",
  Iat:  1516239022,
 }

 result, _ := GenerateToken(claims, "iamtonybai")
 fmt.Println(result)
}

對(duì)照著上面圖示的流程，理解這個(gè)示例非常容易。當(dāng)然jwt.io官方也維護(hù)了一個(gè)使用簡(jiǎn)單且靈活性更好的Go module：golang-jwt/jwt[12]，用這個(gè)go module生成上述token的示例代碼如下：

// authn-examples/jwt/golang-jwt/main.go

import (
    "fmt"
    "time"

    jwt "github.com/golang-jwt/jwt/v5"
)

type MyCustomClaims struct {
    Sub                  string `json:"sub"`
    Name                 string `json:"name"`
    jwt.RegisteredClaims        // use its Subject and IssuedAt
}

func main() {
    mySigningKey := []byte("iamtonybai")

    // Create claims with multiple fields populated
    claims := MyCustomClaims{
        Name: "John Doe",
        Sub:  "1234567890",
        RegisteredClaims: jwt.RegisteredClaims{
            IssuedAt: jwt.NewNumericDate(time.Unix(1516239022, 0)), //  1516239022
        },
    }

    token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
    ss, _ := token.SignedString(mySigningKey)
    fmt.Println(ss)

    _, err := verifyToken(ss, "iamtonybai")
    if err != nil {
        fmt.Println("invalid token:", err)
        return
    }

    fmt.Println("valid token")
}

這段代碼中還包含了一個(gè)對(duì)jwt token驗(yàn)證合法性的函數(shù)verifyToken，服務(wù)端每次收到客戶(hù)端請(qǐng)求中攜帶的token時(shí)，都可以使用verifyToken來(lái)驗(yàn)證token是否合法，下面是verifyToken的實(shí)現(xiàn)邏輯：

// authn-examples/jwt/golang-jwt/main.go

// verifyToken 驗(yàn)證JWT函數(shù)
func verifyToken(tokenString, key string) (*jwt.Token, error) {
    // 解析Token
    token, err := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
        return []byte(key), nil
    })

    if err != nil {
        return nil, err
    }

    // 驗(yàn)證簽名
    if _, ok := token.Method.(*jwt.SigningMethodHMAC); !ok {
        return nil, jwt.ErrSignatureInvalid
    }

    return token, nil
}

服務(wù)端驗(yàn)證token的邏輯是先解析token，得到header、payload對(duì)應(yīng)的base64UrlEncoded后的結(jié)果，然后用key重新生成簽名，對(duì)比生成的簽名與token攜帶的簽名是否一致。

那么在Web應(yīng)用中如何實(shí)現(xiàn)基于jwt token的身份認(rèn)證呢？我們繼續(xù)往下看。

4.2 使用JWT token做身份認(rèn)證

在前面講解Basic Auth、Digest Auth時(shí)，Basic Auth、Digest等服務(wù)端認(rèn)證方式利用了HTTP Header的Authorization字段，基于JWT token的認(rèn)證也是基于Authorization字段，只不過(guò)前綴從Basic、Digest換成了Bearer：

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE2OTc4NjE5MzIsInVzZXJuYW1lIjoiYWRtaW4ifQ.go6NhfmYPZbtHEuJ1oULG890neo0yVdtFJwfAvHhxyE

基于JWT token的身份認(rèn)證方式的客戶(hù)端與服務(wù)端的交互流程如下圖：

圖片

在這幅示意圖中，客戶(hù)端先用basic auth方式登錄服務(wù)端，服務(wù)端驗(yàn)證通過(guò)后，在登錄應(yīng)答中寫(xiě)入一個(gè)jwt token作為后續(xù)客戶(hù)端訪問(wèn)服務(wù)端其他功能的依據(jù)?？蛻?hù)端從登錄應(yīng)答的包體中解析出jwt token后，可以將該token存放在LocalStorage中，然后在后續(xù)的發(fā)向該服務(wù)端的所有請(qǐng)求中都帶上這個(gè)jwt token。服務(wù)端對(duì)這些請(qǐng)求都會(huì)校驗(yàn)其攜帶的jwt token，只有驗(yàn)證通過(guò)的請(qǐng)求才能被正確處理。

下面來(lái)看看對(duì)應(yīng)示意圖的示例源碼，先來(lái)看一下客戶(hù)端：

// authn-examples/jwt-authn/client/main.go

func main() {
 client := &http.Client{}
 req, _ := http.NewRequest("POST", "http://server.com:8080/", nil)

 // 發(fā)送默認(rèn)請(qǐng)求
 response, err := client.Do(req)
 if err != nil {
  fmt.Println(err)
  return
 }

 // 解析響應(yīng)頭
 authHeader := response.Header.Get("WWW-Authenticate")
 loginReq, _ := http.NewRequest("POST", "http://server.com:8080/login", nil)
 username := "admin"
 password := "123456"

 // 判斷認(rèn)證類(lèi)型
 if !strings.Contains(authHeader, "Basic") {
  // 不支持的認(rèn)證類(lèi)型
  fmt.Println("Unsupported authentication type:", authHeader)
  return
 }

 // 使用Basic Auth, 添加Basic Auth頭
 loginReq.SetBasicAuth(username, password)
 response, err = client.Do(loginReq)

 fmt.Println(response.StatusCode)

 // 從響應(yīng)包體中獲取服務(wù)端分配的jwt token
 defer response.Body.Close()
 body, err := io.ReadAll(response.Body)
 if err != nil {
  fmt.Println(err)
  return
 }

 token := string(body)
 fmt.Println("token=", token)

 // 基于token訪問(wèn)服務(wù)端其他功能
 apiReq, _ := http.NewRequest("POST", "http://server.com:8080/calc", nil)
 apiReq.Header.Set("Authorization", "Bearer "+token)
 response, err = client.Do(apiReq)
 fmt.Println(response.StatusCode)
 defer response.Body.Close()
 body, err = io.ReadAll(response.Body)
 if err != nil {
  fmt.Println(err)
  return
 }
 fmt.Println(string(body))
}

客戶(hù)端的操作流程與示意圖一樣，先用basic auth登錄server，通過(guò)驗(yàn)證后，拿到服務(wù)端生成的token。后續(xù)到該服務(wù)端的所有請(qǐng)求只需在Header中帶上token即可。

服務(wù)端的代碼如下：

// authn-examples/jwt-authn/server/main.go

func main() {
 // 創(chuàng)建一個(gè)基本的HTTP服務(wù)器
 mux := http.NewServeMux()

 username := "admin"
 password := "123456"
 key := "iamtonybai"

 // 針對(duì)/的handler
 mux.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
  // 返回401 Unauthorized響應(yīng)
  w.Header().Set("WWW-Authenticate", "Basic realm=\"server.com\"")
  w.WriteHeader(http.StatusUnauthorized)
 })

 // login handler
 mux.HandleFunc("/login", func(w http.ResponseWriter, req *http.Request) {
  // 從請(qǐng)求頭中獲取Basic Auth認(rèn)證信息
  user, pass, ok := req.BasicAuth()
  if !ok {
   // 認(rèn)證失敗
   w.WriteHeader(http.StatusUnauthorized)
   return
  }

  // 驗(yàn)證用戶(hù)名密碼
  if user == username && pass == password {
   // 認(rèn)證成功，生成token
   token := jwt.NewWithClaims(jwt.SigningMethodHS256, jwt.MapClaims{
    "username": username,
    "iat":      jwt.NewNumericDate(time.Now().Add(time.Hour * 24)),
   })
   signedToken, _ := token.SignedString([]byte(key))
   w.Write([]byte(signedToken))
  } else {
   // 認(rèn)證失敗
   http.Error(w, "Invalid username or password", http.StatusUnauthorized)
  }
 })

 // calc handler
 mux.HandleFunc("/calc", func(w http.ResponseWriter, req *http.Request) {
  // 讀取并校驗(yàn)jwt token
  token := req.Header.Get("Authorization")[len("Bearer "):]
  fmt.Println(token)
  if _, err := verifyToken(token, key); err != nil {
   // 認(rèn)證失敗
   http.Error(w, "Invalid token", http.StatusUnauthorized)
   return
  }
  w.Write([]byte("invoke calc ok"))
 })

 // 監(jiān)聽(tīng)8080端口
 err := http.ListenAndServe(":8080", mux)
 if err != nil {
  log.Fatal(err)
 }
}

我們看到，除了在login handler中使用basic auth做用戶(hù)密碼驗(yàn)證外，其他功能handler(如calc)中都使用token進(jìn)行身份驗(yàn)證。

與傳統(tǒng)會(huì)話式(session)認(rèn)證相比，JWT是無(wú)狀態(tài)的，更適用于分布式微服務(wù)架構(gòu)。與Basic auth和digest相比，jwt在使用體驗(yàn)上又領(lǐng)先一籌。憑借其無(wú)需在服務(wù)端保存會(huì)話狀態(tài)、天生適合分布式架構(gòu)、令牌內(nèi)容可以自定義擴(kuò)展等優(yōu)勢(shì)，現(xiàn)階段，jwt已廣泛應(yīng)用于以下場(chǎng)合：

• 前后端分離的Web應(yīng)用和API認(rèn)證
• 跨域單點(diǎn)登錄(SSO)
• 微服務(wù)架構(gòu)下服務(wù)間認(rèn)證
• 無(wú)狀態(tài)和移動(dòng)應(yīng)用認(rèn)證

不過(guò)JWT認(rèn)證方式也有不足，比如：客戶(hù)端要承擔(dān)令牌存儲(chǔ)成本、如果令牌泄露未及時(shí)失效可能被濫用等。

講到這里，從基本的用戶(hù)名密碼認(rèn)證，到加上密碼散列的Digest認(rèn)證，再到應(yīng)用會(huì)話管理的Session認(rèn)證，以及基于令牌的JWT認(rèn)證，我們見(jiàn)證了認(rèn)證機(jī)制的不斷進(jìn)步和發(fā)展。

這些方法主要依賴(lài)賬號(hào)密碼這單一要素，提供了不同程度的安全性。但是隨著互聯(lián)網(wǎng)的快速發(fā)展，開(kāi)發(fā)人員也在考慮改善用戶(hù)名密碼這種方式的使用體驗(yàn)，一些一次性密碼認(rèn)證方式便走入了我們的生活。接下來(lái)我們就來(lái)簡(jiǎn)單說(shuō)一下一次性密碼驗(yàn)證。

5. 基于一次性密碼驗(yàn)證

一次性密碼（One Time Password, OTP）是一種只能使用一次的密碼，它在使用后立即失效。OTP生成密碼的算法基于時(shí)間，在很短的時(shí)間內(nèi)(一般分鐘內(nèi)或更短時(shí)間內(nèi))只能使用一次；每次驗(yàn)證都需要生成和輸入新的密碼，不能重復(fù)使用。

一次性密碼的優(yōu)勢(shì)主要有以下幾點(diǎn)：

• 安全性高：一次性密碼只能使用一次，因此即使攻擊者獲得了密碼，也無(wú)法重復(fù)使用。
• 易用性強(qiáng)：一次性密碼通常是數(shù)字或字母組成的短語(yǔ)，易于記憶和輸入。
• 成本低：一次性密碼的生成和驗(yàn)證成本相對(duì)較低。

信息論已經(jīng)從理論上證明了：一次性密碼本是無(wú)條件安全的，在理論上是無(wú)法破譯的。不過(guò)現(xiàn)實(shí)中，還沒(méi)有一種理想的一次性密碼，大多數(shù)一次性密碼還處于身份認(rèn)證的輔助地位，多作為第二要素。

短信驗(yàn)證碼就是一種我們生活中常見(jiàn)的一次性密碼，它是利用移動(dòng)運(yùn)營(yíng)商的短信通道傳輸?shù)囊淮涡悦艽a。短信驗(yàn)證碼通常由6位數(shù)字組成，有效期為幾分鐘，并且只能使用一次，通過(guò)短信發(fā)送給用戶(hù)，非常方便用戶(hù)使用，用戶(hù)無(wú)需有記住密碼的煩惱。

短信驗(yàn)證碼的工作流程如下：

• 客戶(hù)端發(fā)起認(rèn)證請(qǐng)求，如登錄或注冊(cè)；
• 服務(wù)器生成6位隨機(jī)數(shù)字作為驗(yàn)證碼，通過(guò)文本短信發(fā)送到用戶(hù)注冊(cè)的手機(jī)號(hào)；
• 用戶(hù)接收短信并輸入驗(yàn)證碼進(jìn)行驗(yàn)證；
• 服務(wù)器通過(guò)時(shí)間戳驗(yàn)證此驗(yàn)證碼是否有效(一般在5分鐘內(nèi))。
• 驗(yàn)證碼只能使用一次，服務(wù)器會(huì)將此條記錄標(biāo)記為使用。

短信驗(yàn)證碼的優(yōu)勢(shì)是方便快捷。目前國(guó)內(nèi)大多數(shù)主流Web應(yīng)用都支持手機(jī)驗(yàn)證碼登錄。短信驗(yàn)證碼通常用于以下場(chǎng)景：

• 用戶(hù)注冊(cè)
• 用戶(hù)登錄
• 支付或交易
• 輔助密碼找回等

不過(guò)手機(jī)驗(yàn)證碼這種一次性密碼的安全性相對(duì)較低，因?yàn)槎绦趴梢员唤孬@，攻擊者可以通過(guò)截獲短信來(lái)獲取驗(yàn)證碼。

除短信驗(yàn)證碼外，還有其他常見(jiàn)的OTP實(shí)現(xiàn)形式:

• 手機(jī)應(yīng)用軟件OTP：使用專(zhuān)門(mén)的手機(jī)APP軟件生成OTP碼，如Google Authenticator、Microsoft Authenticator等。
• 電子郵件OTP：類(lèi)似短信驗(yàn)證碼，但通過(guò)郵件發(fā)送6-8位數(shù)字驗(yàn)證碼到用戶(hù)注冊(cè)的郵箱。
• 語(yǔ)音驗(yàn)證碼OTP：服務(wù)端調(diào)用第三方語(yǔ)音平臺(tái)，使用文本到語(yǔ)音功能給用戶(hù)自動(dòng)撥打認(rèn)證電話，提示驗(yàn)證碼。

總體來(lái)說(shuō)，OTP越來(lái)越多地被用到用戶(hù)身份認(rèn)證上來(lái)，隨著以后技術(shù)的進(jìn)步，其應(yīng)用的廣度和深度會(huì)進(jìn)一步擴(kuò)大，安全性也會(huì)得到進(jìn)一步提升?；趥鹘y(tǒng)密碼的認(rèn)證方式早晚會(huì)被扔到歷史的舊物箱中。一些大廠，如Google都在研究替代傳統(tǒng)密碼的技術(shù)，比如Passkey[13]等，一些Web標(biāo)準(zhǔn)組織也在做無(wú)密碼認(rèn)證的規(guī)范，比如WebAuthn[14]等。

6. 小結(jié)

就寫(xiě)到這里吧，篇幅有些長(zhǎng)了，關(guān)于OAuth、OpenID等身份認(rèn)證技術(shù)就不在這里寫(xiě)了，后續(xù)找機(jī)會(huì)單獨(dú)梳理。

本文我們介紹了多種Web應(yīng)用的身份認(rèn)證技術(shù)方案，各種認(rèn)證技術(shù)會(huì)依據(jù)對(duì)安全性、使用性和擴(kuò)展性的不同需求而存在和發(fā)展。了解每種技術(shù)的原理和優(yōu)劣勢(shì)，可幫助我們更好地選擇適合的方案。

首次梳理這么多Web應(yīng)用身份認(rèn)證的資料，可能有些描述并不完全正確，歡迎指正。在撰寫(xiě)本文時(shí)，大語(yǔ)言模型幫助編寫(xiě)部分文字素材和代碼。

本文示例所涉及的Go源碼可以在這里[15]下載。

7. 參考資料

• 《API安全實(shí)戰(zhàn)》[16] - https://book.douban.com/subject/36039150/
• 《API安全技術(shù)與實(shí)戰(zhàn)》[17] - https://book.douban.com/subject/35429043/
• 《深入淺出密碼學(xué)》[18] - https://book.douban.com/subject/36179106/
• Web Authentication Methods Compared[19] - https://testdriven.io/blog/web-authentication-methods/
• 認(rèn)證：系統(tǒng)如何正確分辨操作用戶(hù)的真實(shí)身份？[20] - https://time.geekbang.org/column/article/329954
• 如何實(shí)現(xiàn)零信任網(wǎng)絡(luò)下安全的服務(wù)訪問(wèn)？[21] - https://time.geekbang.org/column/article/345593
• 憑證：系統(tǒng)如何保證與用戶(hù)之間的承諾是準(zhǔn)確完整且不可抵賴(lài)的？[22] - https://time.geekbang.org/column/article/333272
• 谷歌正推出Passkey，密碼將成歷史[23] - https://blog.google/technology/safety-security/the-beginning-of-the-end-of-the-password/
• What is authentication?[24] - https://www.microsoft.com/zh-cn/security/business/security-101/what-is-authentication
• Authentication(wikipedia)[25] - https://en.wikipedia.org/wiki/Authentication.html
• RFC 7617: The 'Basic' HTTP Authentication Scheme[26] - https://datatracker.ietf.org/doc/html/rfc7617
• RFC 7616: HTTP Digest Access Authentication[27] - https://datatracker.ietf.org/doc/html/rfc7616
• RFC 7519: JSON Web Token(JWT)[28] - https://datatracker.ietf.org/doc/html/rfc7519
• Introduction to JSON Web Tokens[29] - https://jwt.io/introduction