欧美三级国产三级日韩三级_亚洲熟妇丰满大屁股熟妇_欧美亚洲成人一区二区三区_国产精品久久久久久模特

Web開發(fā)中常見的認(rèn)證機(jī)制 - 新聞資訊 - 云南小程序開發(fā)|云南軟件開發(fā)|云南網(wǎng)站建設(shè)-昆明葵宇信息科技有限公司

159-8711-8523

云南網(wǎng)建設(shè)/小程序開發(fā)/軟件開發(fā)

知識(shí)

不管是網(wǎng)站,軟件還是小程序,都要直接或間接能為您產(chǎn)生價(jià)值,我們?cè)谧非笃湟曈X表現(xiàn)的同時(shí),更側(cè)重于功能的便捷,營銷的便利,運(yùn)營的高效,讓網(wǎng)站成為營銷工具,讓軟件能切實(shí)提升企業(yè)內(nèi)部管理水平和效率。優(yōu)秀的程序?yàn)楹笃谏?jí)提供便捷的支持!

您當(dāng)前位置>首頁 » 新聞資訊 » 網(wǎng)站建設(shè) >

Web開發(fā)中常見的認(rèn)證機(jī)制

發(fā)表時(shí)間:2017-3-14

發(fā)布人:葵宇科技

瀏覽次數(shù):54

HTTP基本認(rèn)證(HTTP Basic Auth)

在HTTP中,HTTP基本認(rèn)證是一種允許Web瀏覽器或者其他客戶端在請(qǐng)求時(shí)提供用戶名口令形式的身份憑證的一種登錄驗(yàn)證方式。

簡單而言,HTTP基本認(rèn)證就是我們平時(shí)在網(wǎng)站中最常用的通過用戶名和密碼登錄來認(rèn)證的機(jī)制。
優(yōu)點(diǎn)
HTTP 基本認(rèn)證是基本上所有流行的網(wǎng)頁瀏覽器都支持。但是基本認(rèn)證很少在可公開訪問的互聯(lián)網(wǎng)網(wǎng)站上使用,有時(shí)候會(huì)在小的私有系統(tǒng)中使用。
缺點(diǎn)
HTTP 基本認(rèn)證雖然足夠簡單,但是前提是在客戶端和服務(wù)器主機(jī)之間的連接足夠安全。如果沒有使用SSL/TLS這樣的傳輸層安全的協(xié)議,那么以明文傳輸?shù)拿荑€和口令很容易被攔截。
由于現(xiàn)存的瀏覽器保存認(rèn)證信息直到標(biāo)簽頁或?yàn)g覽器關(guān)閉,或者用戶清除歷史記錄。導(dǎo)致了服務(wù)器端無法主動(dòng)來當(dāng)前用戶登出或者認(rèn)證失效。

OAuth(開放授權(quán))

OAuth 是一個(gè)開放標(biāo)準(zhǔn),允許用戶讓第三方應(yīng)用訪問該用戶在某一網(wǎng)站上存儲(chǔ)的私密的資源(如照片,視頻,聯(lián)系人列表等),而無需將用戶名和密碼提供給第三方應(yīng)用。
OAuth 允許用戶提供一個(gè)令牌,而不是用戶名和密碼來訪問他們存放在特定服務(wù)提供者的數(shù)據(jù)。每一個(gè)令牌授權(quán)一個(gè)特定的網(wǎng)站(例如,視頻編輯網(wǎng)站)在特定的時(shí)段(例如,接下來的2小時(shí)內(nèi))內(nèi)訪問特定的資源(例如僅僅是某一相冊(cè)中的視頻)。這樣,OAuth讓用戶可以授權(quán)第三方網(wǎng)站訪問他們存儲(chǔ)在另外服務(wù)提供者的某些特定信息,而非所有內(nèi)容。
現(xiàn)存在OAuth 1.0OAuth 2.0兩種協(xié)議,二者互不兼容。
OAuth 2.0 運(yùn)行流程

流程引用自O(shè)Auth2.0 RFC 6749:https://tools.ietf.org/html/rfc6749

這里寫圖片描述

  • (A)客戶端(Client)向資源擁有者(Resource Owner)發(fā)送授權(quán)請(qǐng)求(Authorization Request)
  • (B)資源擁有者授權(quán)許可(Authorization Grant)
  • (C)客戶端向驗(yàn)證服務(wù)器(Authorization Server)發(fā)送通過(B)獲取的授權(quán)許可
  • (D)驗(yàn)證服務(wù)器驗(yàn)證授權(quán)許可,通過的話,則返回Access Token給客戶端
  • (E)客戶端通過Access Token 訪問資源服務(wù)器(Resource Server)
  • (F)資源服務(wù)器返回受保護(hù)的資源(Protected Resource)

這種基于OAuth的認(rèn)證機(jī)制非常適用于個(gè)人消費(fèi)者類的互聯(lián)網(wǎng)應(yīng)用產(chǎn)品,如社交類等等。一些大的互聯(lián)網(wǎng)公司也都提供OAuth機(jī)制的API,如豆瓣、微信JS-SDK。

Cookie/Session 認(rèn)證機(jī)制

Cookie 是由客戶端保存的小型文本文件,其內(nèi)容為一系列的鍵值對(duì)。Cookie 是由 HTTP 服務(wù)器設(shè)置的,保存在瀏覽器中。Cookie會(huì)隨著 HTTP請(qǐng)求一起發(fā)送。
Session 是存儲(chǔ)在服務(wù)器端的,避免在客戶端 Cookie 中存儲(chǔ)敏感數(shù)據(jù)。Session 可以存儲(chǔ)在 HTTP 服務(wù)器的內(nèi)存中,也可以存在內(nèi)存數(shù)據(jù)庫(如redis)中。
Cookie/Session認(rèn)證機(jī)制就是為一次請(qǐng)求認(rèn)證在服務(wù)端創(chuàng)建一個(gè)Session對(duì)象,同時(shí)在客戶端的瀏覽器端創(chuàng)建了一個(gè)Cookie對(duì)象;通過客戶端帶上來Cookie對(duì)象來與服務(wù)器端的session對(duì)象匹配來實(shí)現(xiàn)狀態(tài)管理的。默認(rèn)的,當(dāng)我們關(guān)閉瀏覽器的時(shí)候,cookie會(huì)被刪除。但可以通過修改cookie 的expire time使cookie在一定時(shí)間內(nèi)有效;

基于 Token 的認(rèn)證機(jī)制

基于 Token的認(rèn)證機(jī)制,有著無需長期保存用戶名和密碼,服務(wù)器端能主動(dòng)讓token失效等諸多好處,非常實(shí)用于 Web 應(yīng)用和 App 已經(jīng)被很多大型網(wǎng)站采用,比如Facebook、Github、Google+等。其流程如下:
1. 客戶端使用用戶名和密碼請(qǐng)求登錄
2. 服務(wù)端收到請(qǐng)求,去驗(yàn)證用戶名與密碼
3. 驗(yàn)證成功后,服務(wù)器會(huì)簽發(fā)一個(gè) Token, 再把這個(gè) Token 發(fā)送給客戶端
4. 客戶端收到 Token 以后可以把它存儲(chǔ)起來,如Cookie或者Web Storage
5. 客戶單每次向服務(wù)端請(qǐng)求資源的時(shí)候,都需要帶著服務(wù)器端簽發(fā)的 Token
6. 服務(wù)器端收到請(qǐng)求,驗(yàn)證客戶端請(qǐng)求里面帶著的 Token,如果驗(yàn)證成功,就向客戶端返回請(qǐng)求的數(shù)據(jù);否的話,則返回對(duì)應(yīng)的錯(cuò)誤信息。

但是存儲(chǔ)在客戶端的 Token 存在幾個(gè)問題:
1. 存在泄露的風(fēng)險(xiǎn)。如果別人拿到你的 Token,在 Token過期之前,都可以以你的身份在別的地方登錄
2. 如果存在 Web Storage(指sessionStorage和localStorage)。由于Web Storage 可以被同源下的JavaScript直接獲取到,這也就意味著網(wǎng)站下所有的JavaScript代碼都可以獲取到web Storage,這就給了XSS機(jī)會(huì)
2. 如果存在Cookie中。雖然存在Cookie可以使用HttpOnly來防止XSS,但是使用 Cookie 卻又引發(fā)了CSRF

對(duì)于泄露的風(fēng)險(xiǎn),可以采取對(duì)Token進(jìn)行對(duì)稱加密,用時(shí)再解密。
對(duì)于XSS而言,在處理數(shù)據(jù)時(shí),都應(yīng)該 escape and encode 所有不信任的數(shù)據(jù)。
與CSRF相比,XSS更加容易防范和意識(shí)到,因此并不建議將Token存在Cookie中。
最后,網(wǎng)站或者應(yīng)用一定要使用HTTPS。畢竟在網(wǎng)絡(luò)層面上 Token 明文傳輸?shù)脑?#xff0c;還是非常的危險(xiǎn)。

關(guān)于基于Token認(rèn)證機(jī)制的項(xiàng)目可以參考:一個(gè)項(xiàng)目學(xué)會(huì)前端實(shí)現(xiàn)登錄攔截
以上是我個(gè)人的看法,如有錯(cuò)誤,歡迎指出。

參考資料

維基百科-HTTP基本認(rèn)證

維基百科-OAuth

相關(guān)案例查看更多