這是一個絕大多數人都會混淆的問題。首先先從讀音上來認識這兩個名詞,不少人都會把它倆的讀音搞混,因此我建議你先先去查一查這兩個單詞到底該怎麼讀,他們的具體含義是什麼。html
說簡單點就是:git
稍微正式點(囉嗦點)的說法就是:github
這兩個通常在咱們的系統中被結合在一塊兒使用,目的就是爲了保護咱們系統的安全性。web
Cookie 和 Session都是用來跟蹤瀏覽器用戶身份的會話方式,可是二者的應用場景不太同樣。redis
維基百科是這樣定義 Cookie 的:Cookies是某些網站爲了辨別用戶身份而儲存在用戶本地終端上的數據(一般通過加密)。簡單來講: Cookie 存放在客戶端,通常用來保存用戶信息。算法
下面是 Cookie 的一些應用案例:spring
這部份內容參考:https://attacomsian.com/blog/cookies-spring-boot,更多如何在Spring Boot中使用Cookie 的內容能夠查看這篇文章。數據庫
1)設置cookie返回給客戶端json
@GetMapping("/change-username") public String setCookie(HttpServletResponse response) { // 建立一個 cookie Cookie cookie = new Cookie("username", "Jovan"); //設置 cookie過時時間 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"; }
Session 的主要做用就是經過服務端記錄用戶的狀態。 典型的場景是購物車,當你要添加商品到購物車的時候,系統不知道是哪一個用戶操做的,由於 HTTP 協議是無狀態的。服務端給特定的用戶建立特定的 Session 以後就能夠標識這個用戶而且跟蹤這個用戶了。
Cookie 數據保存在客戶端(瀏覽器端),Session 數據保存在服務器端。相對來講 Session 安全性更高。若是使用 Cookie 的一些敏感信息不要寫入 Cookie 中,最好能將 Cookie 信息加密而後使用到的時候再去服務器端解密。
那麼,如何使用Session進行身份驗證?
不少時候咱們都是經過 SessionID 來實現特定的用戶,SessionID 通常會選擇存放在 Redis 中。舉個例子:用戶成功登錄系統,而後返回給客戶端具備 SessionID 的 Cookie,當用戶向後端發起請求的時候會把 SessionID 帶上,這樣後端就知道你的身份狀態了。關於這種認證方式更詳細的過程以下:
另外,Spring Session提供了一種跨多個應用程序或實例管理用戶會話信息的機制。若是想詳細瞭解能夠查看下面幾篇很不錯的文章:
咱們在上一個問題中探討了使用 Session 來鑑別用戶的身份,而且給出了幾個 Spring Session 的案例分享。 咱們知道 Session 信息須要保存一份在服務器端。這種方式會帶來一些麻煩,好比須要咱們保證保存 Session 信息服務器的可用性、不適合移動端(依賴Cookie)等等。
有沒有一種不須要本身存放 Session 信息就能實現身份驗證的方式呢?使用 Token 便可!JWT (JSON Web Token) 就是這種方式的實現,經過這種方式服務器端就不須要保存 Session 數據了,只用在客戶端保存服務端返回給客戶的 Token 就能夠了,擴展性獲得提高。
JWT 本質上就一段簽名的 JSON 格式的數據。因爲它是帶有簽名的,所以接收者即可以驗證它的真實性。
下面是 RFC 7519 對 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 部分構成:
Payload
、Header
和一個密鑰(secret
)使用 Header 裏面指定的簽名算法(默認是 HMAC SHA256)生成。在基於 Token 進行身份驗證的的應用程序中,服務器經過Payload
、Header
和一個密鑰(secret
)建立令牌(Token
)並將 Token
發送給客戶端,客戶端將 Token
保存在 Cookie 或者 localStorage 裏面,之後客戶端發出的全部請求都會攜帶這個令牌。你能夠把它放在 Cookie 裏面自動發送,可是這樣不能跨域,因此更好的作法是放在 HTTP Header 的 Authorization字段中: Authorization: Bearer Token
。
推薦閱讀:
OAuth 是一個行業的標準受權協議,主要用來受權第三方應用獲取有限的權限。而 OAuth 2.0是對 OAuth 1.0 的徹底從新設計,OAuth 2.0更快,更容易實現,OAuth 1.0 已經被廢棄。詳情請見:rfc6749。
實際上它就是一種受權機制,它的最終目的是爲第三方應用頒發一個有時效性的令牌 token,使得第三方應用可以經過該令牌獲取相關的資源。
OAuth 2.0 比較經常使用的場景就是第三方登陸,當你的網站接入了第三方登陸的時候通常就是使用的 OAuth 2.0 協議。
推薦閱讀: