15 Go 鑒權(quán)（一）：鑒權(quán)機制概述

在現(xiàn)代web開發(fā)中，系統(tǒng)鑒權(quán)服務(wù)已是基本標配模塊，有些開發(fā)框架甚至內(nèi)置了鑒權(quán)模塊的實現(xiàn)，或者提供一些鑒權(quán)的工具類，然而鑒權(quán)的方式也分為多種，了解各種鑒權(quán)方式的特點及使用場景可以幫助我們構(gòu)建更健壯的web系統(tǒng)。以下列出四種常見的鑒權(quán)方式，我們來認識一下：

專注于為中小企業(yè)提供成都網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè)服務(wù),電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)淄川免費做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了近1000家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。

HTTP 基本身份驗證，允許客戶端在標準的 HTTP 頭中發(fā)送用戶名和密碼。服務(wù)端可以驗證這些信息，并確認客戶端是否有權(quán)訪問服務(wù)。這樣做的好處在于，這是一種非常容易理解且得到廣泛支持的協(xié)議。問題在于，通過 HTTP 有很高的風險，因為用戶名和密碼并沒有以安全的方式發(fā)送。任何中間方都可以看到 HTTP 頭的信息并讀取里面的數(shù)據(jù)。因此，HTTP 基本身份驗證通常應(yīng)該通過 HTTPS 進行通信。

當使用 HTTPS 時，客戶端獲得強有力的保證，它所通信的服務(wù)端就是客戶端想要通信的服務(wù)端。它給予我們額外的保護，避免人們竊聽客戶端和服務(wù)端之間的通信，或篡改有效負載。

服務(wù)端需要管理自己的SSL證書，當需要管理多臺機器時會出現(xiàn)問題。一些組織自己承擔簽發(fā)證書的過程，這是一個額外的行政和運營負擔。管理這方面的自動化工具遠不夠成熟，使用它們后你會發(fā)現(xiàn)，需要自己處理的事情就不止證書簽發(fā)了。自簽名證書不容易撤銷，因此需要對災難情景有更多的考慮?？纯茨闶欠衲軌虮苊庾院灻员荛_所有的這些工作。

SSL 之上的流量不能被反向代理服務(wù)器（比如 Varnish 或 Squid）所緩存，這是使用 HTTPS 的另一個缺點。這意味著，如果你需要緩存信息，就不得不在服務(wù)端或客戶端內(nèi)部實現(xiàn)。你可以在負載均衡中把 Https 的請求轉(zhuǎn)成 Http 的請求，然后在負載均衡之后就可以使用緩存了。

還需要考慮，如果我們已經(jīng)在使用現(xiàn)成的 SSO 方案（比如包含用戶名密碼信息的 SAML），該怎么辦。我們想要基本身份驗證使用同一套認證信息，然后在同一個進程里頒發(fā)和撤銷嗎？讓服務(wù)與實現(xiàn) SSO 所使用的那個目錄服務(wù)進行通信即可做到這一點?；蛘?，我們可以在服務(wù)內(nèi)部存儲用戶名和密碼，但需要承擔存在重復行為的風險。

注意：使用這種方法，服務(wù)器只知道客戶端有用戶名和密碼。我們不知道這個信息是否來自我們期望的機器；它可能來自網(wǎng)絡(luò)中的其他人。

HTTP 基本身份驗證是一種簡單但不那么安全的認證方式，不太建議用于公開的商業(yè)應(yīng)用，在此便不再展開，我們關(guān)注以下幾種認證方式。

http協(xié)議是一種無狀態(tài)的協(xié)議，如果沒有任何認證機制，服務(wù)端對任何客戶端的請求都是無差別的。在Web2.0時代，為了加強B/S交互的安全性，衍生出了Session-Cookie鑒權(quán)機制，通過在服務(wù)端開啟會話，客戶端存儲SessionID，在每次請求時通過cookie傳輸SessionID的形式實現(xiàn)服務(wù)端基本鑒權(quán)。

cookie是保存在本地終端的數(shù)據(jù)。cookie由服務(wù)器生成，發(fā)送給瀏覽器，瀏覽器把cookie以kv形式保存到某個目錄下的文本文件內(nèi)，下一次請求同一網(wǎng)站時會把該cookie發(fā)送給服務(wù)器。由于cookie是存在客戶端上的，所以瀏覽器加入了一些限制確保cookie不會被惡意使用，同時不會占據(jù)太多磁盤空間，所以每個域的cookie數(shù)量是有限的。

cookie的組成有：名稱(key)、值(value)、有效域(domain)、路徑(域的路徑，一般設(shè)置為全局:"")、失效時間、安全標志(指定后，cookie只有在使用SSL連接時才發(fā)送到服務(wù)器(https))。

Session的中文翻譯是“會話”，當用戶打開某個web應(yīng)用時，便與web服務(wù)器產(chǎn)生一次session。服務(wù)器使用session把用戶的信息臨時保存在了服務(wù)器上，用戶離開網(wǎng)站后session會被銷毀。這種用戶信息存儲方式相對cookie來說更安全，可是session有一個缺陷：如果web服務(wù)器做了負載均衡，那么下一個操作請求到了另一臺服務(wù)器的時候session會丟失。

當程序需要為某個客戶端的請求創(chuàng)建一個session時，服務(wù)器首先檢查這個客戶端的請求里是否已包含了一個session標識（稱為SessionID），如果已包含則說明以前已經(jīng)為此客戶端創(chuàng)建過Session，服務(wù)器就按照SessionID把這個Session檢索出來使用（檢索不到，會新建一個），如果客戶端請求不包含SessionID，則為此客戶端創(chuàng)建一個Session并且生成一個與此Session相關(guān)聯(lián)的SessionID，SessionID的值應(yīng)該是一個既不會重復，又不容易被找到規(guī)律以仿造的字符串，這個SessionID將被在本次響應(yīng)中返回給客戶端保存。

保存這個SessionID的方式可以采用Cookie，這樣在交互過程中瀏覽器可以自動的按照規(guī)則把這個標識發(fā)揮給服務(wù)器。一般這個Cookie的名字都是類似于SEEESIONID。但Cookie可以被人為的禁止，則必須有其他機制以便在Cookie被禁止時仍然能夠把SessionID傳遞回服務(wù)器。

客戶端第一次發(fā)送請求給服務(wù)器，此時服務(wù)器啟動Session會話，產(chǎn)生一個唯一的SessionID，并通過Response的SetCookie返回給客戶端，保存于客戶端(一般為瀏覽器)，并與一個瀏覽器窗口對應(yīng)著,由于HTTP協(xié)議的特性，這一次Request-Response

后連接就斷開了。以后此客戶端再發(fā)送請求給服務(wù)器的時候，就會在請求Request頭中攜帶cookie,由于cookie中帶有Key為sessionID的數(shù)據(jù),所以服務(wù)器就知道這是剛才那個客戶端。

正如我們前面所討論的，如果擔心用戶名和密碼被泄露，HTTP基本身份驗證使用普通 HTTP 并不是非常明智的。傳統(tǒng)的替代方式是使用HTTPS路由通信，但也有一些缺點。除了需要管理證書，HTTPS通信的開銷使得服務(wù)器壓力增加，而且通信難以被輕松地緩存。另外Session-Cookie機制也會有被客戶限制的隱患，如果用戶禁用Cookie則必須由其它方式實現(xiàn)鑒權(quán)。

所謂Token，即令牌?？蛻舳诵枰b權(quán)訪問私人信息時，會首次向服務(wù)端發(fā)送身份驗證信息（如用戶名、密碼），服務(wù)端校驗正確后會根據(jù)一定的加密算法生成Token令牌發(fā)放給客戶端，此后客戶端只需通過Token，服務(wù)端只需驗證Token就可識別客戶并進行交互，Token可存放于HTTP Header也可存放與Cookie。

以上為一個簡單的Token鑒權(quán)過程。

關(guān)于Token機制，業(yè)界有一種叫JWT（JsonWebToken）的實現(xiàn)機制，下面我們來了解JWT。

JWT.io 對JSON Web Tokens進行了很好的介紹，

國內(nèi)阮一峰的 《JSON Web Token 入門教程》 也講得非常好懂，可以出門右拐了解一下。

簡而言之，它是一個簽名的JSON對象，可以執(zhí)行一些有用的操作（例如，身份驗證）。它是一組字串，分Header（頭部）、Payload（負載）、Signature（簽名）三部分，由'.'號連接，看起來就像下面這樣：

用戶發(fā)送認證信息給服務(wù)端后，服務(wù)端通過JWT生成規(guī)則，生成JWT字串作為Token發(fā)放給用戶，用戶以后每次訪問都在HTTP Header攜帶JWT字串，已達到鑒權(quán)目的。由于其內(nèi)部攜帶用戶信息，部分使用者已經(jīng)發(fā)現(xiàn)其安全隱患，但其安全度不至于太過容易破解，在移動應(yīng)用中的鑒權(quán)機制使用較多，除此之外，一些分布式的微服務(wù)應(yīng)用也通過JWT進行模塊間的鑒權(quán)，還是有一定的使用場景的。

Go開源社區(qū)已有比較成熟的JWT包實現(xiàn)： jwt-go ，內(nèi)附有JWT編解碼的使用用例，還是很好懂的，感興趣的可get來使用。在另一篇中也做了Go 使用JWT鑒權(quán)的示例： 《Go 鑒權(quán)（三）：JWT》 ,感興趣可閱讀以下，自己也在項目中實踐一下。

OAUTH協(xié)議為用戶資源的授權(quán)提供了一個安全的、開放而又簡易的標準。同時，任何第三方都可以使用OAUTH認證服務(wù)，任何服務(wù)提供商都可以實現(xiàn)自身的OAUTH認證服務(wù)，因而OAUTH是開放的。

OpenID Connect 是 OAuth 2.0 具體實現(xiàn)中的一個標準。它使用簡單的 REST 調(diào)用，因為提高了其易用性。對于一個面向公眾的網(wǎng)站，你或許可以使用Google、Facebook、Github等作為提供者，國內(nèi)可以使用QQ、微信、淘寶等作為提供者。但對于內(nèi)部系統(tǒng)，或?qū)τ跀?shù)據(jù)需要有更多控制權(quán)的系統(tǒng)而言，你會希望有自己的內(nèi)部身份提供者。

OAuth2.0有四種授權(quán)模式，具體可看阮一峰的 《理解OAuth2.0》 ,其內(nèi)容非常詳細且好理解。

我們這里說一下最完整的授權(quán)碼模式：

以上為OAuth2.0的認證過程。

各大廠都有提供基于OAuth2.0的三方授權(quán)服務(wù)，如QQ、微信、淘寶等等，有需要可移步到各自的開放平臺查看文檔，大都有提供Go的接口實現(xiàn)；另你也可參考使用Go官方提供實現(xiàn)的包 ，里面包含多數(shù)熱門的OAuth客戶端。

推薦使用 這個開源項目，幫助你構(gòu)建自己的OAuth服務(wù)

有沒有人用golang實現(xiàn)過restful框架的實例

通過beego快速創(chuàng)建一個Restful風格API項目及API文檔自動化:

Go 語言構(gòu)建 RESTful Web 服務(wù):

Golang中使用 JWT認證來 保障Restful JSON API的安全（英文）:

polaris: 一個用go實現(xiàn)的支持restful的web框架:

關(guān)于RESTFUL API 安全認證方式的一些總結(jié):

有沒有人用golang實現(xiàn)過restful框架的實例:

Micro 一個用Go語言實現(xiàn)的微服務(wù)框架:

基于微服務(wù)庫的可插拔RPC go-micro:

golang適合做web開發(fā)嗎？:

a-survey-of-5-go-web-frameworks:

Ozzo Framework:

avelino/awesome-go:

Beego Framework:

golang其實不適合做web開發(fā):

Go語言現(xiàn)有Web開發(fā)框架:

使用Golang快速構(gòu)建WEB應(yīng)用:

Martini 極好的 Go WEB 框架:

golang 有哪些比較穩(wěn)定的 web 開發(fā)框架？:

jwt-go庫介紹

這個庫已經(jīng)沒人維護了，他們現(xiàn)在新搞了一個，具體可以去github上看

jwt(json web token)是一種用于前后端身份認證的方法,一個jwt由header，payload，和signature組成。

1.Claims

claims是一個實現(xiàn)了Valid方法的interface，Valid方法用于判斷該claim是否合法

2.Keyfunc

Keyfunc在使用時一般都是返回secret密鑰，可以根據(jù)Token的種類不同返回不同的密鑰.

官方文檔:This allows you to use properties in the Header of the token (such as 'kid') to identify which key to use.

3.Mapclaims

一個用于放decode出來的claim的map,有Vaild和一系列VerifyXXX的方法

4.Parser

用來將tokenstr轉(zhuǎn)換成token

5.SigningMethod

簽名方法的接口，可以通過實現(xiàn)這個接口自定義簽名方法，jwt-go內(nèi)置一些實現(xiàn)了SigningMethod的結(jié)構(gòu)體

6.StandardClaims

jwt官方規(guī)定的一些預定義的payload:

7.Token

Token的結(jié)構(gòu)體

8.ValidationError

定義解析Token時遇到的一些錯誤

首先我們先來看Parse()

實際上是調(diào)用了ParseWithClaims,第二個參數(shù)就是一個map[string]interface,這個函數(shù)的源碼如下,這個函數(shù)內(nèi)部調(diào)用的ParseUnverified,我們先來看看這個函數(shù)

官方的解釋是，這個函數(shù)不校驗簽名的有效性，只單純負責把tokenStr變成Token對象，而之后的事情就是交給ParseWithClaims來做啦

可以看到，ParseUnverified這個方法真的只是單純的解碼Header段和Claim段，然后檢查一下用的alg是不是合法，就返回了，讓我們繼續(xù)往下看驗證的邏輯

ok,關(guān)于解析token的主要方法我們已經(jīng)看完了，接下來我們來看看如何生成一個token，其實就是反著操作一遍

先看New函數(shù)，選擇一種SigningMethod，新建一個token，內(nèi)部調(diào)用NewWithClaims

再看NewWithClaims,發(fā)現(xiàn)就是簡單的給JwtToken的三個部分賦值

最后是SignedString，即使用alg的算法給token加密，生成最終的tokenStr,內(nèi)部調(diào)用了SigningString，所以先看SigningString

發(fā)現(xiàn)SigningString就是把token的頭部先變成json然后base64url編碼，但是沒有生成jwtToken的最后一個部分

所以SignedString作用就是用給定的加密方法和你的SecretKey對前面兩部分加密，添在token的最后一段，至此token生成完畢