建站
咨詢
售后
建站咨詢
新聞中心
認(rèn)證和授權(quán)這兩個(gè)術(shù)語(yǔ)通常在安全性方面相互結(jié)合使用，尤其是在獲得對(duì)系統(tǒng)的訪問(wèn)權(quán)限時(shí)。兩者都是非常重要的主題，通常與網(wǎng)絡(luò)相關(guān)聯(lián)，作為其服務(wù)基礎(chǔ)架構(gòu)的關(guān)鍵部分。然而，這兩個(gè)術(shù)語(yǔ)在完全不同的概念上是非常不同的。雖然它們通常使用相同的工具在相同的上下文中使用，但它們彼此完全不同。
成都創(chuàng)新互聯(lián)公司服務(wù)項(xiàng)目包括麻江網(wǎng)站建設(shè)、麻江網(wǎng)站制作、麻江網(wǎng)頁(yè)制作以及麻江網(wǎng)絡(luò)營(yíng)銷策劃等。多年來(lái)，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，麻江網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到麻江省份的部分城市，未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！
1. 認(rèn)證 (Authentication) 和授權(quán) (Authorization)的區(qū)別是什么?
首先先從讀音上來(lái)認(rèn)識(shí)這兩個(gè)名詞，很多人都會(huì)把它倆的讀音搞混，所以我建議你先先去查一查這兩個(gè)單詞到底該怎么讀，他們的具體含義是什么。
說(shuō)簡(jiǎn)單點(diǎn)就是：
認(rèn)證 (Authentication)： 你是誰(shuí)。
授權(quán) (Authorization)： 你有權(quán)限干什么。
稍微正式點(diǎn)(啰嗦點(diǎn))的說(shuō)法就是：
Authentication(認(rèn)證) 是驗(yàn)證您的身份的憑據(jù)(例如用戶名/用戶ID和密碼)，通過(guò)這個(gè)憑據(jù)，系統(tǒng)得以知道你就是你，也就是說(shuō)系統(tǒng)存在你這個(gè)用戶。所以，Authentication 被稱為身份/用戶驗(yàn)證。
Authorization(授權(quán)) 發(fā)生在 Authentication(認(rèn)證) 之后。授權(quán)嘛，光看意思大家應(yīng)該就明白，它主要掌管我們?cè)L問(wèn)系統(tǒng)的權(quán)限。比如有些特定資源只能具有特定權(quán)限的人才能訪問(wèn)比如admin，有些對(duì)系統(tǒng)資源操作比如刪除、添加、更新只能特定人才具有。
這兩個(gè)一般在我們的系統(tǒng)中被結(jié)合在一起使用，目的就是為了保護(hù)我們系統(tǒng)的安全性。
2. Cookie是什么?&有什么作用以及如何在服務(wù)端使用Cookie ?
2.1 什么是Cookie ? Cookie的作用是什么?
Cookie 和 Session都是用來(lái)跟蹤瀏覽器用戶身份的會(huì)話方式，但是兩者的應(yīng)用場(chǎng)景不太一樣。
維基百科是這樣定義 Cookie 的：Cookies是某些網(wǎng)站為了辨別用戶身份而儲(chǔ)存在用戶本地終端上的數(shù)據(jù)(通常經(jīng)過(guò)加密)。簡(jiǎn)單來(lái)說(shuō)： Cookie 存放在客戶端，一般用來(lái)保存用戶信息。
下面是 Cookie 的一些應(yīng)用案例：
我們?cè)?Cookie 中保存已經(jīng)登錄過(guò)的用戶信息，下次訪問(wèn)網(wǎng)站的時(shí)候頁(yè)面可以自動(dòng)幫你登錄的一些基本信息給填了。除此之外，Cookie 還能保存用戶首選項(xiàng)，主題和其他設(shè)置信息。
使用Cookie 保存 session 或者 token ，向后端發(fā)送請(qǐng)求的時(shí)候帶上 Cookie，這樣后端就能取到session或者token了。這樣就能記錄用戶當(dāng)前的狀態(tài)了，因?yàn)?HTTP 協(xié)議是無(wú)狀態(tài)的。
Cookie 還可以用來(lái)記錄和分析用戶行為。舉個(gè)簡(jiǎn)單的例子你在網(wǎng)上購(gòu)物的時(shí)候，因?yàn)镠TTP協(xié)議是沒(méi)有狀態(tài)的，如果服務(wù)器想要獲取你在某個(gè)頁(yè)面的停留狀態(tài)或者看了哪些商品，一種常用的實(shí)現(xiàn)方式就是將這些信息存放在Cookie
2.2 如何在服務(wù)端使用 Cookie 呢?
這部分內(nèi)容參考：https://attacomsian.com/blog/cookies-spring-boot，更多如何在Spring Boot中使用Cookie 的內(nèi)容可以查看這篇文章。
1)設(shè)置cookie返回給客戶端
@GetMapping("/change-username")
public String setCookie(HttpServletResponse response) {
// 創(chuàng)建一個(gè) cookie
Cookie cookie = new Cookie("username", "Jovan");
//設(shè)置 cookie過(guò)期時(shí)間
cookie.setMaxAge(7 * 24 * 60 * 60); // expires in 7 days
//添加到 response 中
response.addCookie(cookie);
return"Username is changed!";
}
\2) 使用Spring框架提供的@CookieValue注解獲取特定的 cookie的值
@GetMapping("/")
public String readCookie(@CookieValue(value = "username", defaultValue = "Atta") String username) {
return"Hey! My username is " + username;
}
\3) 讀取所有的 Cookie 值
@GetMapping("/all-cookies")
public String readAllCookies(HttpServletRequest request) {
Cookie[] cookies = request.getCookies();
if (cookies != null) {
return Arrays.stream(cookies)
.map(c -> c.getName() + "=" + c.getValue()).collect(Collectors.joining(", "));
}
return"No cookies";
}
3. Cookie 和 Session 有什么區(qū)別?如何使用Session進(jìn)行身份驗(yàn)證?
Session 的主要作用就是通過(guò)服務(wù)端記錄用戶的狀態(tài)。 典型的場(chǎng)景是購(gòu)物車，當(dāng)你要添加商品到購(gòu)物車的時(shí)候，系統(tǒng)不知道是哪個(gè)用戶操作的，因?yàn)?HTTP 協(xié)議是無(wú)狀態(tài)的。服務(wù)端給特定的用戶創(chuàng)建特定的 Session 之后就可以標(biāo)識(shí)這個(gè)用戶并且跟蹤這個(gè)用戶了。
Cookie 數(shù)據(jù)保存在客戶端(瀏覽器端)，Session 數(shù)據(jù)保存在服務(wù)器端。相對(duì)來(lái)說(shuō) Session 安全性更高。如果使用 Cookie 的一些敏感信息不要寫(xiě)入 Cookie 中，最好能將 Cookie 信息加密然后使用到的時(shí)候再去服務(wù)器端解密。
那么，如何使用Session進(jìn)行身份驗(yàn)證?
很多時(shí)候我們都是通過(guò) SessionID 來(lái)實(shí)現(xiàn)特定的用戶，SessionID 一般會(huì)選擇存放在 Redis 中。舉個(gè)例子：用戶成功登陸系統(tǒng)，然后返回給客戶端具有 SessionID 的 Cookie，當(dāng)用戶向后端發(fā)起請(qǐng)求的時(shí)候會(huì)把 SessionID 帶上，這樣后端就知道你的身份狀態(tài)了。關(guān)于這種認(rèn)證方式更詳細(xì)的過(guò)程如下：
Session Based Authentication flow
用戶向服務(wù)器發(fā)送用戶名和密碼用于登陸系統(tǒng)。
服務(wù)器驗(yàn)證通過(guò)后，服務(wù)器為用戶創(chuàng)建一個(gè) Session，并將 Session信息存儲(chǔ) 起來(lái)。
服務(wù)器向用戶返回一個(gè) SessionID，寫(xiě)入用戶的 Cookie。
當(dāng)用戶保持登錄狀態(tài)時(shí)，Cookie 將與每個(gè)后續(xù)請(qǐng)求一起被發(fā)送出去。
服務(wù)器可以將存儲(chǔ)在 Cookie 上的 Session ID 與存儲(chǔ)在內(nèi)存中或者數(shù)據(jù)庫(kù)中的 Session 信息進(jìn)行比較，以驗(yàn)證用戶的身份，返回給用戶客戶端響應(yīng)信息的時(shí)候會(huì)附帶用戶當(dāng)前的狀態(tài)。
使用 Session 的時(shí)候需要注意下面幾個(gè)點(diǎn)：
依賴Session的關(guān)鍵業(yè)務(wù)一定要確保客戶端開(kāi)啟了Cookie。
注意Session的過(guò)期時(shí)間
花了個(gè)圖簡(jiǎn)單總結(jié)了一下Session認(rèn)證涉及的一些東西。
另外，Spring Session提供了一種跨多個(gè)應(yīng)用程序或?qū)嵗芾碛脩魰?huì)話信息的機(jī)制。如果想詳細(xì)了解可以查看下面幾篇很不錯(cuò)的文章：
Getting Started with Spring Session
Guide to Spring Session
Sticky Sessions with Spring Session & Redis
4.如果沒(méi)有Cookie的話Session還能用嗎?這是一道經(jīng)典的面試題!
一般是通過(guò) Cookie 來(lái)保存 SessionID ，假如你使用了 Cookie 保存 SessionID的方案的話， 如果客戶端禁用了Cookie，那么Seesion就無(wú)法正常工作。
但是，并不是沒(méi)有 Cookie 之后就不能用 Session 了，比如你可以將SessionID放在請(qǐng)求的 url 里面https://javaguide.cn/?session_id=xxx 。這種方案的話可行，但是安全性和用戶體驗(yàn)感降低。當(dāng)然，為了你也可以對(duì) SessionID 進(jìn)行一次加密之后再傳入后端。
5.為什么Cookie 無(wú)法防止CSRF攻擊，而token可以?
CSRF(Cross Site Request Forgery)一般被翻譯為 跨站請(qǐng)求偽造 。那么什么是 跨站請(qǐng)求偽造 呢?說(shuō)簡(jiǎn)單用你的身份去發(fā)送一些對(duì)你不友好的請(qǐng)求。舉個(gè)簡(jiǎn)單的例子：
小壯登錄了某網(wǎng)上銀行，他來(lái)到了網(wǎng)上銀行的帖子區(qū)，看到一個(gè)帖子下面有一個(gè)鏈接寫(xiě)著“科學(xué)理財(cái)，年盈利率過(guò)萬(wàn)”，小壯好奇的點(diǎn)開(kāi)了這個(gè)鏈接，結(jié)果發(fā)現(xiàn)自己的賬戶少了10000元。這是這么回事呢?原來(lái)黑客在鏈接中藏了一個(gè)請(qǐng)求，這個(gè)請(qǐng)求直接利用小壯的身份給銀行發(fā)送了一個(gè)轉(zhuǎn)賬請(qǐng)求,也就是通過(guò)你的 Cookie 向銀行發(fā)出請(qǐng)求。
上面也提到過(guò)，進(jìn)行Session 認(rèn)證的時(shí)候，我們一般使用 Cookie 來(lái)存儲(chǔ) SessionId,當(dāng)我們登陸后后端生成一個(gè)SessionId放在Cookie中返回給客戶端，服務(wù)端通過(guò)Redis或者其他存儲(chǔ)工具記錄保存著這個(gè)Sessionid，客戶端登錄以后每次請(qǐng)求都會(huì)帶上這個(gè)SessionId，服務(wù)端通過(guò)這個(gè)SessionId來(lái)標(biāo)示你這個(gè)人。如果別人通過(guò) cookie拿到了 SessionId 后就可以代替你的身份訪問(wèn)系統(tǒng)了。
Session 認(rèn)證中 Cookie 中的 SessionId是由瀏覽器發(fā)送到服務(wù)端的，借助這個(gè)特性，攻擊者就可以通過(guò)讓用戶誤點(diǎn)攻擊鏈接，達(dá)到攻擊效果。
但是，我們使用 token 的話就不會(huì)存在這個(gè)問(wèn)題，在我們登錄成功獲得 token 之后，一般會(huì)選擇存放在 local storage 中。然后我們?cè)谇岸送ㄟ^(guò)某些方式會(huì)給每個(gè)發(fā)到后端的請(qǐng)求加上這個(gè) token,這樣就不會(huì)出現(xiàn) CSRF 漏洞的問(wèn)題。因?yàn)?，即使有個(gè)你點(diǎn)擊了非法鏈接發(fā)送了請(qǐng)求到服務(wù)端，這個(gè)非法請(qǐng)求是不會(huì)攜帶 token 的，所以這個(gè)請(qǐng)求將是非法的。
需要注意的是不論是 Cookie 還是 token 都無(wú)法避免跨站腳本攻擊(Cross Site Scripting)XSS。
“跨站腳本攻擊(Cross Site Scripting)縮寫(xiě)為 CSS 但這會(huì)與層疊樣式表(Cascading Style Sheets，CSS)的縮寫(xiě)混淆。因此，有人將跨站腳本攻擊縮寫(xiě)為XSS?！?XSS中攻擊者會(huì)用各種方式將惡意代碼注入到其他用戶的頁(yè)面中。就可以通過(guò)腳本盜用信息比如cookie。
6. 什么是 Token?什么是 JWT?如何基于Token進(jìn)行身份驗(yàn)證?
我們?cè)谏弦粋€(gè)問(wèn)題中探討了使用 Session 來(lái)鑒別用戶的身份，并且給出了幾個(gè) Spring Session 的案例分享。 我們知道 Session 信息需要保存一份在服務(wù)器端。這種方式會(huì)帶來(lái)一些麻煩，比如需要我們保證保存 Session 信息服務(wù)器的可用性、不適合移動(dòng)端(依賴Cookie)等等。
有沒(méi)有一種不需要自己存放 Session 信息就能實(shí)現(xiàn)身份驗(yàn)證的方式呢?使用 Token 即可!JWT (JSON Web Token) 就是這種方式的實(shí)現(xiàn)，通過(guò)這種方式服務(wù)器端就不需要保存 Session 數(shù)據(jù)了，只用在客戶端保存服務(wù)端返回給客戶的 Token 就可以了，擴(kuò)展性得到提升。
JWT 本質(zhì)上就一段簽名的 JSON 格式的數(shù)據(jù)。由于它是帶有簽名的，因此接收者便可以驗(yàn)證它的真實(shí)性。
下面是 RFC 7519 對(duì) JWT 做的較為正式的定義。
“JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. ——JSON Web Token (JWT)” JWT 由 3 部分構(gòu)成:
Header :描述 JWT 的元數(shù)據(jù)。定義了生成簽名的算法以及 Token 的類型。
Payload(負(fù)載):用來(lái)存放實(shí)際需要傳遞的數(shù)據(jù)
Signature(簽名)：服務(wù)器通過(guò)Payload、Header和一個(gè)密鑰(secret)使用 Header 里面指定的簽名算法(默認(rèn)是 HMAC SHA256)生成。
在基于 Token 進(jìn)行身份驗(yàn)證的的應(yīng)用程序中，服務(wù)器通過(guò)Payload、Header和一個(gè)密鑰(secret)創(chuàng)建令牌(Token)并將 Token 發(fā)送給客戶端，客戶端將 Token 保存在 Cookie 或者 localStorage 里面，以后客戶端發(fā)出的所有請(qǐng)求都會(huì)攜帶這個(gè)令牌。你可以把它放在 Cookie 里面自動(dòng)發(fā)送，但是這樣不能跨域，所以更好的做法是放在 HTTP Header 的 Authorization字段中：Authorization: Bearer Token。
Token Based Authentication flow
用戶向服務(wù)器發(fā)送用戶名和密碼用于登陸系統(tǒng)。
身份驗(yàn)證服務(wù)響應(yīng)并返回了簽名的 JWT，上面包含了用戶是誰(shuí)的內(nèi)容。
用戶以后每次向后端發(fā)請(qǐng)求都在Header中帶上 JWT。
服務(wù)端檢查 JWT 并從中獲取用戶相關(guān)信息。
7.什么是OAuth 2.0?
OAuth 是一個(gè)行業(yè)的標(biāo)準(zhǔn)授權(quán)協(xié)議，主要用來(lái)授權(quán)第三方應(yīng)用獲取有限的權(quán)限。而 OAuth 2.0是對(duì) OAuth 1.0 的完全重新設(shè)計(jì)，OAuth 2.0更快，更容易實(shí)現(xiàn)，OAuth 1.0 已經(jīng)被廢棄。詳情請(qǐng)見(jiàn)：rfc6749。
實(shí)際上它就是一種授權(quán)機(jī)制，它的最終目的是為第三方應(yīng)用頒發(fā)一個(gè)有時(shí)效性的令牌 token，使得第三方應(yīng)用能夠通過(guò)該令牌獲取相關(guān)的資源。
OAuth 2.0 比較常用的場(chǎng)景就是第三方登錄，當(dāng)你的網(wǎng)站接入了第三方登錄的時(shí)候一般就是使用的 OAuth 2.0 協(xié)議。
另外，現(xiàn)在OAuth 2.0也常見(jiàn)于支付場(chǎng)景(微信支付、支付寶支付)和開(kāi)發(fā)平臺(tái)(微信開(kāi)放平臺(tái)、阿里開(kāi)放平臺(tái)等等)。
微信支付賬戶相關(guān)參數(shù)：
8.什么是 SSO?
SSO(Single Sign On)即單點(diǎn)登錄說(shuō)的是用戶登陸多個(gè)子系統(tǒng)的其中一個(gè)就有權(quán)訪問(wèn)與其相關(guān)的其他系統(tǒng)。舉個(gè)例子我們?cè)诘顷懥司〇|金融之后，我們同時(shí)也成功登陸京東的京東超市、京東家電等子系統(tǒng)。
9.SSO與OAuth2.0的區(qū)別
OAuth 是一個(gè)行業(yè)的標(biāo)準(zhǔn)授權(quán)協(xié)議，主要用來(lái)授權(quán)第三方應(yīng)用獲取有限的權(quán)限。SSO解決的是一個(gè)公司的多個(gè)相關(guān)的自系統(tǒng)的之間的登陸問(wèn)題比如京東旗下相關(guān)子系統(tǒng)京東金融、京東超市、京東家電等等。
網(wǎng)站名稱：關(guān)于認(rèn)證和授權(quán)常見(jiàn)的9個(gè)問(wèn)題
網(wǎng)頁(yè)網(wǎng)址：http://www.5511xx.com/article/coesesg.html
