SpringBoot整合SpringSecurity(十)窺探OAuth2

序言

OAuth2是一個關於授權的開放網絡標準,允許用戶授權第三方移動應用訪問他們存儲在另外的服務提供者上的信息,而不需要將用戶名和密碼提供給第三方移動應用或分享他們數據的所有內容。 OAuth2.0是OAuth協議的延續版本,但不向後兼容OAuth 1.0即完全廢止了OAuth1.0。

代碼請參考 https://github.com/AutismSuperman/springsecurity-example

應用場景主要有如下

  • 第三方應用授權登錄 在APP或者網頁接入一些第三方應用時,時長會需要用戶登錄另一個合作平臺,比如QQ,微博,微信的授權登錄。
  • 原生app授權 App登錄請求後臺接口,爲了安全認證,所有請求都帶token信息,如果登錄驗證、請求後臺數據。
  • 前後端分離單頁面應用(spa) 前後端分離框架,前端請求後臺數據,需要進行oauth2安全認證,比如使用vue、react後者h5開發的app。

OAuth2的一個流程

這幅圖是OAuth2 官網的一幅圖,講述了OAuth2的 一個大體協議流程。
在這裏插入圖片描述

  • A)用戶(資源所有者)打開 客戶端 ,客戶端 要求 用戶 給予授權。
  • B)用戶 同意給予 客戶端 授權。
  • C)客戶端 獲得授權後,向 認證服務器 申請令牌。
  • D)認證服務器對 客戶端 進行認證後,確認無誤,同意發放令牌。
  • E)客戶端 使用令牌,向 資源服務器 申請獲取資源。
  • F)資源服務器 確認 令牌無誤, 同意 向 客戶端開放資源。

引用阮老師的話 OAuth2 就是一種授權機制。數據的所有者告訴系統,同意授權第三方應用進入系統,獲取這些數據。系統從而產生一個短期的進入令牌(token),用來代替密碼,供第三方應用使用。

OAuth2四種不同的標準模式

OAuth2標準爲了應對不同的場景,設計了四種不同的標準模式。分別是以下幾種

  • 授權碼模式
  • 簡化模式
  • 密碼模式
  • 客戶端模式

先不提這接種原理到底是什麼,先說明以下這幾種模式的應用場景

  • 授權碼模式:第三方Web服務器端應用與第三方原生App
  • 簡化模式:第三方單頁面應用
  • 密碼模式:自家單頁應用與自家原生App
  • 客戶端模式:沒有用戶參與的,完全信任的服務器端服務

好知道這些後我們就來窺探以下這幾種模式。

授權碼模式 Authorization code

在這裏插入圖片描述
授權碼模式是 四種模式中最繁瑣也是最安全的一種模式,大概步驟如下

  • (A) 用戶訪問客戶端如果需要用戶授權則將用戶導向認證服務器
  • (B) 如果用戶在認證服務器上進行授權
  • (C) 如果授權通過,認證服務器將用戶導向客戶端事先指定的"重定向URI"(redirection URI),同時附上一個授權碼
  • (D) 客戶端收到授權碼後 拿着授權碼向認證服務器索要 Access Token,這一步呢通常是在客戶端後臺完成
  • (E) 認證服務器會和對客戶端發來的授權碼檢測是否正確 返回 Access Token和 Refresh Token給客戶端

這些步驟做完後,有了Access Token,既可以訪問用戶那些受保護的資源了。因爲在這種模式中 Access Token不會經過瀏覽器或移動端的App,而是直接從服務端去交換,這樣就最大限度的減小了 Access Token泄漏的風險。

簡化模式Implicit

在這裏插入圖片描述
這種模式和 授權碼模式有所不同,他省略了客戶端去請求認證服務器的這一步

  • (A) 用戶訪問客戶端如果需要用戶授權則將用戶導向認證服務器
  • (B) 用戶在認證服務器上完成驗證
  • (C) 如果認證成功 認證服務器將Access Token以 Hash的形式存放在重定向 uri 的fargment中發送給瀏覽器
  • (D) 瀏覽器訪問重定向URI
  • (E) 資源服務器返回一個腳本,用以解析uri Hash中的Access Token
  • (F) 在瀏覽器裏將Access Token解析出來
  • (G) 將解析出的Access Token發送給client

這種模式呢有個弊端就是會把 Access Token暴漏出來,所以呢,該模式不支持refresh tokens,簡化模式用於沒有服務器端的第三方單頁面應用,因爲沒有服務器端就無法使用授權碼模式同樣呢 該模式最容易受安全攻擊。

用戶名密碼 Resource Owner Credentials

在這裏插入圖片描述
這種模式就比較簡單了 密碼模式是用戶直接將自己的用戶名密碼交給客戶端,客戶端用用戶的用戶名密碼直接換取Access Token。

  • (A)用戶將認證密碼發送給client
  • (B)客戶端拿着用戶的密碼向認證服務器請求Access Token
  • (C)認證服務器將Access Token和Refresh Token發送給客戶端

這種模式十分簡單,但是卻意味着直接將用戶敏感信息泄漏給了client,因此這就說明這種模式只能用於client是我們自己開發的情況下。

因此密碼模式一般用於我們自己開發的原生App或者單頁應用。

客戶端憑證 Client Credentials

在這裏插入圖片描述
這是一種最簡單的模式,只要client請求,我們就將Access Token發送給它。

  • (A)客戶端向認證服務器發送自己的身份信息,並請求Access Token
  • (B)確認客戶端信息無誤後,將Access Token發送給客戶端

這種模式是最方便但最不安全的模式, 就是因爲這種太不安全,因此這種模式一般用來提供給我們完全信任的服務器端服務。在這個過程中不需要用戶的參與。

總結

知道了這些概念後,在學習SpringSecurity 中的 Spring Social 和用來搭建自己的一套授權服務的 Spring OAuth2就會變的格外的簡單。

本博文是基於springboot2.x 和security 5 如果有什麼不對的請在下方留言。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章