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

1、Http Basic Auth

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

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

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

2、OAuth2

本人之前的博客介紹過OAuth2 以及使用Azure AD實(shí)現(xiàn)OAuth2認(rèn)證方式，在這里呢，還是把那篇博客部分內(nèi)容摳出來，方便大家總結(jié)查看。https://blog.csdn.net/aHardDreamer/article/details/88650939

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

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

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

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

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

二、OAuth2 認(rèn)證和授權(quán)的過程：

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

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

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

4)客戶端獲得臨時(shí)token之后，將用戶引導(dǎo)至服務(wù)提供方的授權(quán)頁面，并請求用戶授權(quán)。(在這個(gè)過程中會將臨時(shí)token和客戶端的回調(diào)鏈接/接口 發(fā)送給服務(wù)提供方 ---很明顯服務(wù)提供方到時(shí)會回來call這個(gè)接口在用戶認(rèn)證并授權(quán)之后)

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

6)授權(quán)成功后，服務(wù)提供方將用戶引導(dǎo)至客戶端的網(wǎng)頁(call第4步里面的回調(diào)鏈接/接口)；

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

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

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

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

1、Authorization Code (授權(quán)碼模式)

結(jié)合普通服務(wù)器端應(yīng)用使用。

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

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

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

(免費(fèi)學(xué)習(xí)視頻分享：php視頻教程)

2、Implicit(簡化模式)

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

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

不支持refresh tokens

假定資源所有者和公開客戶應(yīng)用在同一個(gè)設(shè)備上

最容易受安全攻擊

3、Resource Owner Password Credentials

適用于受信任客戶端應(yīng)用，例如同個(gè)組織的內(nèi)部或外部應(yīng)用。

使用用戶名密碼登錄的應(yīng)用，例如桌面App

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

一般不支持refresh token

假定資源擁有者和公開客戶在相同設(shè)備上

4、Client Credentials

適用于客戶端調(diào)用主服務(wù)API型應(yīng)用(比如百度API Store，不同項(xiàng)目之間的微服務(wù)互相調(diào)用)

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

因?yàn)榭蛻魬{證可以使用對稱或者非對稱加密，該方式支持共享密碼或者證書

3、Cookie-Session Auth

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

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

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

1)Session 增多會增加服務(wù)器開銷

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

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

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

3)容易遭到CSRF攻擊

因?yàn)槭腔赾ookie來進(jìn)行用戶識別的, cookie如果被截獲，用戶就會很容易受到跨站請求偽造的攻擊

4、Token Auth

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

流程：

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

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

服務(wù)器通過驗(yàn)證發(fā)送給用戶一個(gè)token

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

服務(wù)端驗(yàn)證token值，并返回?cái)?shù)據(jù)

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

5、JWT 認(rèn)證機(jī)制(Json Web Token)

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

簡潔性

可以通過URL，POST參數(shù)或者在HTTP header發(fā)送，因?yàn)閿?shù)據(jù)量小，傳輸速度也很快

自包含性

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

下列場景中使用JSON Web Token是很有用的：

Authorization (授權(quán)) : 這是使用JWT的最常見場景。一旦用戶登錄，后續(xù)每個(gè)請求都將包含JWT，允許用戶訪問該令牌允許的路由、服務(wù)和資源。單點(diǎn)登錄是現(xiàn)在廣泛使用的JWT的一個(gè)特性，因?yàn)樗拈_銷很小，并且可以輕松地跨域使用。

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

JWT的結(jié)構(gòu)：

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

Header：

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

例如：

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

Payload:

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

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

Public claims : 可以隨意定義。

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

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

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

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

Signature:

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

例如：

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

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

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

更多關(guān)于JWT的內(nèi)容，可以前往這個(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

總結(jié)

以上是生活随笔為你收集整理的php 登录安全认证,介绍几种常用的web安全认证方式的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。