6月安卓手機(jī)好評(píng)榜：魅族20 Pro蟬聯(lián)冠軍
性能榜和性?xún)r(jià)比榜之后，我們來(lái)看最后的安卓手機(jī)好評(píng)榜，數(shù)據(jù)來(lái)源安兔兔評(píng)測(cè)，收集時(shí)間2023年6月1日至6月30日，僅限國(guó)內(nèi)市場(chǎng)。第一名：魅族20 Pro好評(píng)率：95%5月份的時(shí)候魅族20 Pro就是
在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ā)修煉之路的第一步。
身份認(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)題。
身份認(rèn)證需要被認(rèn)證方提供一些身份信息輸入，這些代表身份信息的輸入被稱(chēng)為身份認(rèn)證要素（authentication factor）。這些要素有很多，大致可分為三類(lèi)：
即基于被認(rèn)證方知道的特定信息來(lái)驗(yàn)證身份，最常見(jiàn)的如密碼等。
基于被認(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)要素。
即基于被認(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)看一下。
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í)行操作。
Web應(yīng)用通常會(huì)返回html/js/css等瀏覽器可解析執(zhí)行的代碼，而API服務(wù)通常返回結(jié)構(gòu)化數(shù)據(jù)，常見(jiàn)的如JSON或XML等。
Web應(yīng)用主要面向人類(lèi)用戶(hù)的使用，用戶(hù)通過(guò)瀏覽器進(jìn)行操作。而API服務(wù)主要被其他程序調(diào)用，為程序之間提供接口與數(shù)據(jù)支撐。
Web應(yīng)用在服務(wù)端保存會(huì)話(huà)狀態(tài)，瀏覽器通過(guò)cookie等保存用戶(hù)狀態(tài)。而API服務(wù)通常是無(wú)狀態(tài)的，每次請(qǐng)求都需要攜帶用于身份認(rèn)證的信息，比如訪問(wèn)令牌或API Key等。
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)證方式。
在對(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.gofunc 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.gofunc 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)證。
基于密碼的認(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ō)起。
這是最常見(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.gofunc 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ì)話(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ì)話(huà)。
接下來(lái)，我們就來(lái)簡(jiǎn)單看看基于Session的后續(xù)認(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.govar 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.gofunc 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ī)制。
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)建通常分兩步。
服務(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.gofunc 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.gofunc 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)證方式。
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.gofunc 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ù)生成HA1func 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ù)生成responsefunc 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.gofunc 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)證方式。
基于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)中使用最廣的一種。
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.gopackage mainimport ( "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.goimport ( "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ù)往下看。
在前面講解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.gofunc 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.gofunc 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ì)話(huà)式(session)認(rèn)證相比，JWT是無(wú)狀態(tài)的，更適用于分布式微服務(wù)架構(gòu)。與Basic auth和digest相比，jwt在使用體驗(yàn)上又領(lǐng)先一籌。憑借其無(wú)需在服務(wù)端保存會(huì)話(huà)狀態(tài)、天生適合分布式架構(gòu)、令牌內(nèi)容可以自定義擴(kuò)展等優(yōu)勢(shì)，現(xiàn)階段，jwt已廣泛應(yīng)用于以下場(chǎng)合：
不過(guò)JWT認(rèn)證方式也有不足，比如：客戶(hù)端要承擔(dān)令牌存儲(chǔ)成本、如果令牌泄露未及時(shí)失效可能被濫用等。
講到這里，從基本的用戶(hù)名密碼認(rèn)證，到加上密碼散列的Digest認(rèn)證，再到應(yīng)用會(huì)話(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)證。
一次性密碼（One Time Password, OTP）是一種只能使用一次的密碼，它在使用后立即失效。OTP生成密碼的算法基于時(shí)間，在很短的時(shí)間內(nèi)(一般分鐘內(nèi)或更短時(shí)間內(nèi))只能使用一次；每次驗(yàn)證都需要生成和輸入新的密碼，不能重復(fù)使用。
一次性密碼的優(yōu)勢(shì)主要有以下幾點(diǎn)：
信息論已經(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)證碼的工作流程如下：
短信驗(yàn)證碼的優(yōu)勢(shì)是方便快捷。目前國(guó)內(nèi)大多數(shù)主流Web應(yīng)用都支持手機(jī)驗(yàn)證碼登錄。短信驗(yàn)證碼通常用于以下場(chǎng)景：
不過(guò)手機(jī)驗(yàn)證碼這種一次性密碼的安全性相對(duì)較低，因?yàn)槎绦趴梢员唤孬@，攻擊者可以通過(guò)截獲短信來(lái)獲取驗(yàn)證碼。
除短信驗(yàn)證碼外，還有其他常見(jiàn)的OTP實(shí)現(xiàn)形式:
總體來(lái)說(shuō)，OTP越來(lái)越多地被用到用戶(hù)身份認(rèn)證上來(lái)，隨著以后技術(shù)的進(jìn)步，其應(yīng)用的廣度和深度會(huì)進(jìn)一步擴(kuò)大，安全性也會(huì)得到進(jìn)一步提升。基于傳統(tǒng)密碼的認(rèn)證方式早晚會(huì)被扔到歷史的舊物箱中。一些大廠，如Google都在研究替代傳統(tǒng)密碼的技術(shù)，比如Passkey[13]等，一些Web標(biāo)準(zhǔn)組織也在做無(wú)密碼認(rèn)證的規(guī)范，比如WebAuthn[14]等。
就寫(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]下載。
本文鏈接：http://www.www897cc.com/showinfo-26-15216-0.html通過(guò)實(shí)例理解Go Web身份認(rèn)證的幾種方式
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
上一篇： 聊聊Java中線程的生命周期
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)