怎樣淺談Spring Security中的OAuth2

怎樣淺談Spring Security中的OAuth2，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

首先我們來講述大概介紹一下OAuth3。

oAuth3是一種授權協議。它主要是為了簡化客戶端開發人員的工作，同時為需要授權的服務提供授權流程，主要包括網站、桌面、app、小程序等。 我從官網把它幾種授權模式搬過來了：

1. 授權碼（Authorization Code）

   機密和公共客戶端使用授權碼授予類型來交換訪問令牌的授權碼。 用戶通過重定向URL返回到客戶端后，應用程序將從URL獲得授權代碼，并使用它來請求訪問令牌。

2. 客戶憑證（Client Credentials）

   客戶端使用“客戶端證書”授予類型來獲取用戶上下文之外的訪問令牌。客戶端通常使用它來訪問有關其自身的資源，而不是訪問用戶的資源。

3. 設備代碼（Device Code）

   設備流中的無瀏覽器或受輸入限制的設備使用設備代碼授權類型，以將先前獲得的設備代碼交換為訪問令牌。設備代碼授權類型值為urn:ietf:params:oauth:grant-type:device_code。

4. 刷新令牌（Refresh Token）

   當訪問令牌過期時，客戶端使用“刷新令牌”授予類型來將刷新令牌交換為訪問令牌。這允許客戶端繼續具有有效的訪問令牌，而無需與用戶進行進一步的交互。

5. 密碼授權（Implicit Flow）

   密碼授予類型是一種將用戶憑據交換為訪問令牌的方式。因為客戶端應用程序必須收集用戶的密碼并將其發送到授權服務器，所以不建議再使用此授權。該流程沒有為多因素身份驗證或委托帳戶之類的機制提供任何機制，因此在實踐中是相當有限的。

   最新的OAuth 2.0安全性最佳最新實踐完全禁止密碼授予。

6. 隱式流（Password Grant）

   Implicit流是先前為本機應用程序和JavaScript應用程序推薦的簡化的OAuth流，其中本機訪問令牌無需額外的授權代碼交換步驟即可立即返回訪問令牌。不建議使用隱式流（有些服務器完全禁止該流），因為在HTTP重定向中返回訪問令牌而未確認客戶端已收到訪問令牌的固有風險。公共客戶端（例如本機應用程序和JavaScript應用程序）現在應該使用帶有PKCE擴展名的授權代碼流。

   其中密碼授權及隱式流兩種模式在OAuth官網中是已經屬于遺留模式，不在推薦了。但是我的Spring Security OAuth3系列文章主要講述的將是密碼模式，不要問我為啥？因為我是需要去解決我們現有框架中的登陸問題。所以我會著重密碼模式！

個人理解的OAuth3

直到我寫到這里，可能我才對OAuth3有了更新的一個認識！根據官方介紹OAuth3應該是一個第三方授權機制，即有點類似于是一個能提供公共授權機制的模塊。因此在現實中這個授權模塊應該具有相對的權威性，又或者說在一個范圍內的應用程序，可以去請求同一個授權模塊進行使用。
那這個授權模塊是不是也應該是一個至少擁有用戶管理功能的信息系統，能夠進行身份授權，授權后授權模塊允許這個賬號可以使用某些功能。
但是問題來了，我在文章開頭寫了我們主要是搭建我們系統的登陸模塊，暫時未用到對第三方應用授權。我們在這個系統中是否有必要引入OAuth3的授權機制？

說實話寫到上一行，我停下來想了十分鐘。我在本文中提到的系統屬于我們的核心系統，包括整個公司的核心業務功能都在上面。如果以后我們在擴展其他應用時，是需要用到第三方授權的，不然就需要在每個應用中都去維護一套系統用戶了。而且我們通過OAuth3也可以登陸本系統的，所以使用OAuth3.0是完全沒有問題的。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。