介紹幾種常用的web安全認證方式

本文為大家介紹了五種常用的web安全認證方式，具有一定的參考價(jià)值，希望能對大家有所幫助。

1、Http Basic Auth

這是一種最古老的安全認證方式，這種方式就是簡(jiǎn)單的訪(fǎng)問(wèn)API的時(shí)候，帶上訪(fǎng)問(wèn)的username和password，由于信息會(huì )暴露出去，所以現在也越來(lái)越少用了，現在都用更加安全保密的認證方式，可能某些老的平臺還在用。

如下圖所示，彈出一個(gè)框，讓你填寫(xiě)用戶(hù)名密碼。這就是Tomcat自帶的HTTPBasic認證。

這就是你訪(fǎng)問(wèn)應用的憑據了，那段xxxXXX字符串是我寫(xiě)的表示這是一段密文，這是一段什么密文呢，就是講用戶(hù)名和密碼進(jìn)行一個(gè)Base64加密后得到的密文。所以你現在是不是也有同感了---這tm也太容易盜取了，所以現在新的應用幾乎不怎么用這種方式了，雖然簡(jiǎn)單，但是安全級別太低了。

2、OAuth2

本人之前的博客介紹過(guò)OAuth2 以及使用Azure AD實(shí)現OAuth2認證方式，在這里呢，還是把那篇博客部分內容摳出來(lái)，方便大家總結查看。

https://blog.csdn.net/aHardDreamer/article/details/88650939

OAuth 即：Open Authrization(開(kāi)放授權)， 它是一個(gè)開(kāi)放標準，允許用戶(hù)讓第三方應用訪(fǎng)問(wèn)該用戶(hù)在某一網(wǎng)站上存儲的私密資源，而無(wú)需將用戶(hù)名和密碼提供給第三方。比如我們熟知的通過(guò)qq/微信/微博等登錄第三方平臺。OAuth 1.0版本發(fā)布后有許多安全漏洞，所以在OAuth2.0里面完全廢止了OAuth1.0，它關(guān)注客戶(hù)端開(kāi)發(fā)者的簡(jiǎn)易性，要么通過(guò)組織在資源擁有者和HTTP服務(wù)商之間的被批準的交互動(dòng)作代表用戶(hù)，要么允許第三方應用代表用戶(hù)獲得訪(fǎng)問(wèn)的權限。讀起來(lái)有點(diǎn)繞口，其實(shí)原理也非常簡(jiǎn)單，請看下面講解。

一、首先我們要了解在OAuth2 認證和授權的過(guò)程中有這三個(gè)角色：

1. 服務(wù)提供方：顧名思義，提供受保護的服務(wù)和資源的，用戶(hù)在這里面存了很多東西。

2. 用戶(hù)： 存了東西（照片，資料等）在服務(wù)提供方的人。

3. 客戶(hù)端：服務(wù)調用方，它要訪(fǎng)問(wèn)服務(wù)提供方的資源，需要在服務(wù)提供方進(jìn)行注冊，不然服務(wù)提供方不鳥(niǎo)它呀。

二、OAuth2 認證和授權的過(guò)程：

1）用戶(hù)想操作存放在服務(wù)提供方的資源；

2）用戶(hù)登錄客戶(hù)端，客戶(hù)端向服務(wù)提供方請求一個(gè)臨時(shí)token;

3）服務(wù)提供方驗證客戶(hù)端的身份后，給它一個(gè)臨時(shí)token;

4）客戶(hù)端獲得臨時(shí)token之后，將用戶(hù)引導至服務(wù)提供方的授權頁(yè)面，并請求用戶(hù)授權。（在這個(gè)過(guò)程中會(huì )將臨時(shí)token和客戶(hù)端的回調鏈接/接口 發(fā)送給服務(wù)提供方 ---很明顯服務(wù)提供方到時(shí)會(huì )回來(lái)call這個(gè)接口在用戶(hù)認證并授權之后）

5）用戶(hù)輸入用戶(hù)名密碼登錄，登錄成功之后，可以授權客戶(hù)端訪(fǎng)問(wèn)服務(wù)提供方的資源；

6）授權成功后，服務(wù)提供方將用戶(hù)引導至客戶(hù)端的網(wǎng)頁(yè)（call第4步里面的回調鏈接/接口）；

7）客戶(hù)端根據臨時(shí)token從服務(wù)提供方那里獲取正式的access token；

8）服務(wù)提供方根據臨時(shí)token以及用戶(hù)的授權情況授予客戶(hù)端access token;

9）客戶(hù)端使用access token訪(fǎng)問(wèn)用戶(hù)存放在服務(wù)提供方的受保護的資源。

三、拿access token的方法（Grant Type）有下面四種，每一種都有適用的應用場(chǎng)景：

1、Authorization Code （授權碼模式）

結合普通服務(wù)器端應用使用。

1）用戶(hù)訪(fǎng)問(wèn)客戶(hù)端，后者將前者導向認證服務(wù)器，假設用戶(hù)給予授權，認證服務(wù)器將用戶(hù)導向客戶(hù)端事先指定的"重定向URI"（redirection URI），同時(shí)附上一個(gè)授權碼。

2)客戶(hù)端收到授權碼，附上早先的"重定向URI"，向認證服務(wù)器申請令牌：GET /oauth/token?response_type=code&client_id=test&redirect_uri=重定向頁(yè)面鏈接。請求成功返回code授權碼，一般有效時(shí)間是10分鐘。

3）認證服務(wù)器核對了授權碼和重定向URI，確認無(wú)誤后，向客戶(hù)端發(fā)送訪(fǎng)問(wèn)令牌（access token）和更新令牌（refresh token）。POST /oauth/token?response_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=重定向頁(yè)面鏈接。請求成功返回access Token和refresh Token。

（免費學(xué)習視頻分享：）

2、Implicit（簡(jiǎn)化模式）

結合移動(dòng)應用或 Web App 使用。

Access Token直接從授權服務(wù)器返回(只有前端渠道)

不支持refresh tokens

假定資源所有者和公開(kāi)客戶(hù)應用在同一個(gè)設備上

最容易受安全攻擊

3、Resource Owner Password Credentials

適用于受信任客戶(hù)端應用，例如同個(gè)組織的內部或外部應用。

使用用戶(hù)名密碼登錄的應用，例如桌面App

使用用戶(hù)名/密碼作為授權方式從授權服務(wù)器上獲取access token

一般不支持refresh token

假定資源擁有者和公開(kāi)客戶(hù)在相同設備上

4、Client Credentials

適用于客戶(hù)端調用主服務(wù)API型應用（比如百度API Store，不同項目之間的微服務(wù)互相調用）

只有后端渠道，使用客戶(hù)憑證獲取一個(gè)access token

因為客戶(hù)憑證可以使用對稱(chēng)或者非對稱(chēng)加密，該方式支持共享密碼或者ssl/' target='_blank'>證書(shū)

3、Cookie-Session Auth

Cookie-Session 認證機制在我們初學(xué)J2EE的時(shí)候接觸的比較多，就是為一次請求認證在服務(wù)端創(chuàng )建一個(gè)Session對象，同時(shí)在客戶(hù)端的瀏覽器端創(chuàng )建了一個(gè)Cookie對象；通過(guò)客戶(hù)端帶上來(lái)Cookie對象來(lái)與服務(wù)器端的session對象匹配來(lái)實(shí)現狀態(tài)管理的。默認的，當我們關(guān)閉瀏覽器的時(shí)候，cookie會(huì )被刪除。但可以通過(guò)修改cookie 的expire time使cookie在一定時(shí)間內有效；

但是這種基于cookie-session的認證使應用本身很難得到擴展，隨著(zhù)不同客戶(hù)端用戶(hù)的增加，獨立的服務(wù)器已無(wú)法承載更多的用戶(hù)，而這時(shí)候基于session認證應用的問(wèn)題就會(huì )暴露出來(lái)。

基于session認證所顯露的問(wèn)題：

1）Session 增多會(huì )增加服務(wù)器開(kāi)銷(xiāo)

每個(gè)用戶(hù)經(jīng)過(guò)我們的應用認證之后，我們的應用都要在服務(wù)端做一次記錄，以方便用戶(hù)下次請求的鑒別，通常而言session都是保存在內存中，而隨著(zhù)認證用戶(hù)的增多，服務(wù)端的開(kāi)銷(xiāo)會(huì )明顯增大。

2）分布式或多服務(wù)器環(huán)境中適應性不好

用戶(hù)認證之后，服務(wù)端做認證記錄，如果認證的記錄被保存在內存中的話(huà)，這意味著(zhù)用戶(hù)下次請求還必須要請求在這臺服務(wù)器上,這樣才能拿到授權的資源，這樣在分布式的應用上，相應的限制了負載均衡器的能力。這也意味著(zhù)限制了應用的擴展能力。不過(guò)，現在某些服務(wù)器可以通過(guò)設置粘性Session，來(lái)做到每臺服務(wù)器之間的Session共享。

3）容易遭到CSRF攻擊

因為是基于cookie來(lái)進(jìn)行用戶(hù)識別的, cookie如果被截獲，用戶(hù)就會(huì )很容易受到跨站請求偽造的攻擊

4、Token Auth

基于token的鑒權機制類(lèi)似于http協(xié)議也是無(wú)狀態(tài)的，它不需要在服務(wù)端去保留用戶(hù)的認證信息或者會(huì )話(huà)信息。這就意味著(zhù)基于token認證機制的應用不需要去考慮用戶(hù)在哪一臺服務(wù)器登錄了，這就為應用的擴展提供了便利。

流程：

用戶(hù)使用用戶(hù)名密碼來(lái)請求服務(wù)器

服務(wù)器進(jìn)行驗證用戶(hù)的信息

服務(wù)器通過(guò)驗證發(fā)送給用戶(hù)一個(gè)token

客戶(hù)端存儲token，并在每次請求時(shí)附送上這個(gè)token值

服務(wù)端驗證token值，并返回數據

這個(gè)token必須要在每次請求時(shí)傳遞給服務(wù)端，它應該保存在請求頭里， 另外，服務(wù)端要支持CORS(跨來(lái)源資源共享)策略，一般我們在服務(wù)端這么做就可以了Access-Control-Allow-Origin。

5、JWT 認證機制（Json Web Token）

JWT作為一個(gè)開(kāi)放的標準（RFC 7519），定義了一種簡(jiǎn)潔的，自包含的方法用于通信雙方之間以Json對象的形式安全的傳遞信息。因為數字簽名的存在，這些信息是可信的，JWT可以使用HMAC算法或者是RSA的公私秘鑰對進(jìn)行簽名。

簡(jiǎn)潔性

可以通過(guò)URL，POST參數或者在HTTP header發(fā)送，因為數據量小，傳輸速度也很快

自包含性

負載中包含了所有用戶(hù)所需要的信息，避免了多次查詢(xún)數據庫

下列場(chǎng)景中使用JSON Web Token是很有用的：

Authorization (授權) : 這是使用JWT的最常見(jiàn)場(chǎng)景。一旦用戶(hù)登錄，后續每個(gè)請求都將包含JWT，允許用戶(hù)訪(fǎng)問(wèn)該令牌允許的路由、服務(wù)和資源。單點(diǎn)登錄是現在廣泛使用的JWT的一個(gè)特性，因為它的開(kāi)銷(xiāo)很小，并且可以輕松地跨域使用。

Information Exchange (信息交換) : 對于安全的在各方之間傳輸信息而言，JSON Web Tokens無(wú)疑是一種很好的方式。因為JWTs可以被簽名，例如，用公鑰/私鑰對，你可以確定發(fā)送人就是它們所說(shuō)的那個(gè)人。另外，由于簽名是使用頭和有效負載計算的，您還可以驗證內容沒(méi)有被篡改。

JWT的結構：

通過(guò)這張圖，很清晰看出JWT的結構分為三部分，他們之間用“.”連接：

Header：

header典型的由兩部分組成：token的類(lèi)型（“JWT”）和算法名稱(chēng)（比如：HMAC SHA256或者RSA等等）。

例如：

然后，用Base64對這個(gè)JSON編碼就得到JWT的第一部分

Payload:

JWT的第二部分是payload，它包含聲明（要求）。聲明是關(guān)于實(shí)體(通常是用戶(hù))和其他數據的聲明。聲明有三種類(lèi)型: registered, public 和 private。

Registered claims : 這里有一組預定義的聲明，它們不是強制的，但是推薦。比如：iss (issuer), exp (expiration time), sub (subject), aud (audience)等。

Public claims : 可以隨意定義。

Private claims : 用于在同意使用它們的各方之間共享信息，并且不是注冊的或公開(kāi)的聲明。

下面是一個(gè)例子：

對payload進(jìn)行Base64編碼就得到JWT的第二部分

注意，不要在JWT的payload或header中放置敏感信息，除非它們是加密的。

Signature:

為了得到簽名部分，你必須有編碼過(guò)的header、編碼過(guò)的payload、一個(gè)秘鑰，簽名算法是header中指定的那個(gè)，然對它們簽名即可。

例如：

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

簽名是用于驗證消息在傳遞過(guò)程中有沒(méi)有被更改，并且，對于使用私鑰簽名的token，它還可以驗證JWT的發(fā)送方是否為它所稱(chēng)的發(fā)送方。

碰到JWT token可以去JWT官網(wǎng)解密看看，下面這是官網(wǎng)解密出來(lái)的數據，可以很清楚的看到它的三部分內容：

更多關(guān)于JWT的內容，可以前往這個(gè)博客：

https://www.cnblogs.com/cjsblog/p/9277677.html

參考：

https://www.jianshu.com/p/f8c43dcd8b69

https://blog.csdn.net/alan_liuyue/article/details/88183267

https://www.cnblogs.com/cjsblog/p/9277677.html

相關(guān)推薦：