Spring Security Oauth2 從零到一完整實踐（一）

時間  2019-11-22
標籤 spring security oauth2 oauth 完整 實踐 欄目 Spring 简体版
原文   原文鏈接

好久沒有寫一篇長文章了，本身提及來其實年初換成 solo 到如今，寫的讓本身滿意的技術性文章也就只有 spring boot restful API 從零到一完整實踐 這篇了，其餘的其實都是隻屬於本身比較容易理解的筆記和記錄而已。想一想年中了，仍是須要寫上這麼一篇實踐性文章的。這段時間比較折磨本身的，莫過於就是 spirng security oauth2 了，本身折騰了好久，也算是學會了一些吧，按照原來的方式，寫了一篇文章。前面也寫過 spring boot security oauth2 構建簡單安全的 restful api，可是太過於基礎而且那時候本身也有不少不懂，如今實踐了不少，有了更加深刻的瞭解，記錄一下順便分享給你們。javascript

github 地址：spring-security-oauth2-democss

博客地址：echocow.cnhtml

[TOC]前端

系列文章

  1. 較爲詳細的學習 oauth2 的四種模式其中的兩種受權模式
  2. spring boot oauth2 自動配置實現
  3. spring security oauth2 受權服務器配置
  4. spring security oauth2 資源服務器配置
  5. spring security oauth2 自定義受權模式（手機、郵箱等）
  6. spring security oauth2 踩坑記錄

本來打算所有寫完一塊兒發的，可是才寫到第三點，就已經上萬字了，因此仍是以爲分系列發吧～java

預備知識

具有如下基礎知識可以方便你更好的閱讀本篇文章mysql

  • spring 基礎
  • spring boot web 的使用與配置
  • spring security 的使用與配置
  • postman 的使用
  • idea、maven、lombok 的使用與配置

Oauth2

學習一項新的東西以前，咱們要先了解一下他爲咱們解決了哪些事，可以帶來什麼樣的便利，而在 IT 行業，瞭解一個東西最簡單的方式就是去他的官網瞭解，因此咱們先去官網瞭解一下這個協議：Oauth2jquery

An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.git

一個容許從Web、移動和桌面應用程序簡單和標準方法進行安全受權的開放協議。github

The OAuth 2.0 authorization framework enables third-party applications to obtain limited access to a web service.web

OAuth 2.0 受權框架使第三方應用程序可以得到對 Web 服務的有限訪問權限。

從官網的解釋就能夠知道它能夠完成以下兩件事：

  1. 對你的應用站點進行安全受權
  2. 使第三方應用程序可以得到對 Web 服務的有限訪問權限

咱們這篇教程就是經過 spring security oauth2 來完成這麼兩件事。咱們來詳細瞭解一下這個協議，首先了解什麼要使用 oauth2。咱們以 web 爲例來進行了解。

傳統應用

在咱們傳統的 web 應用中，咱們的前端頁面和後端的邏輯都是一塊兒部署的，大概流程以下：

傳統模式

當咱們發送一個請求的時候，直接先發給後端處理，後端處理完成後將數據發送給前端，而後前端渲染，再交給用戶，因此有了模板引擎這個東西，例如 jsp、thymeleaf、freemarker 這些，都是這樣的流程。而這些個東西最爲重要的就是 session，你能夠經過存儲在 session 裏面的東西對他進行受權/認證等操做，大概以下：

受權

如今的應用

那麼如今咱們的應用是什麼樣的呢？如今的前端已經再也不是隻有 html、css、javascript 了，也再也不是 bootstrap 的天下，也沒有 jquery 一出，萬人空巷了。前端項目組建工程化，已經可以完整的獨立成爲一個工程化的項目了。因此咱們如今先後端是徹底分離的，先後端各司其職，前端完成前端的事，只作頁面，後端完成後端的事，只作邏輯和數據庫操做，徹底兩個獨立的引用，經過接口進行交互，那麼咱們的大概流程以下：

先後端分離

用戶經過瀏覽器請求前端應用的頁面，而後頁面裏面加載請求到數據，再渲染頁面。那麼如今的受權沒有 session 了，先後端是徹底獨立的兩個項目了，咱們要怎麼進行認證受權呢？對於一個受保護的應用來講，他的請求流程以下：

如今

在這個流程中，咱們後端應用其實變成了兩個，一個是受權服務器一個是資源服務器，固然你徹底能夠簡愛嗯他們兩個同時寫在一個之中。單獨提出來的好處是什麼呢？最主要的一點就是上面提到的 使第三方應用程序可以得到對 Web 服務的有限訪問權限，簡單的說就是可以更加方便的另一個應用接入。當你寫好一個受權服務器之後，其餘應用就能夠共用這個受權服務器，他們就做爲資源服務器亦或是客戶端便可。

角色

在這個協議中，咱們須要明確一個 角色 的概念，在前面的和傳統應用的對比中，咱們提到了資源服務器和受權服務器，這就是其中兩個角色，在 Oauth2 中，總共有四種角色：

名稱 英文名 描述 web例子
資源全部者 resource owner 可以授予對受保護資源的訪問權的實體。當資源全部者是一我的時，它就是用戶。 用戶
資源服務器 resource server 承載受保護資源的服務器，可以使用訪問令牌接受和響應受保護資源請求。 後端資源數據
客戶端 client 表明資源全部者及其受權發出受保護資源請求的應用程序。「客戶端」 並不意味着任何特定的實現特徵(例如，應用程序是否在服務器、桌面或其餘設備上執行)。 前端應用
受權服務器 authorization server 在成功認證資源全部者並得到受權後，服務器向客戶端發出訪問令牌。 後端受權

而受權服務器能夠是與資源服務器相同的服務器或單獨的服務器。 單個受權服務器能夠發出由多個資源服務器接受的訪問令牌。

流程圖大概以下：

+--------+                               +-----------------+
     |        |--（A）------- 受權請求 -------->|                 |
     |        |                               | 資源全部者（用戶） |
     |        |<-（B）------- 受權許可 ---------|                 |
     |        |                               +-----------------+
     |        |
     |        |                               +-----------------+
     |        |--（C）------- 受權許可 -------->|                 |
     | 客戶端  |                               |  受權服務器（1    |
     |        |<-（D）----- Access Token ----）|                 |
     |        |                               +-----------------+
     |        |
     |        |                               +-----------------+
     |        |（-（E）---- Access Token ----->|                 |
     |        |                               |   資源服務器（2   |
     |        |<-（F）---- 獲取受保護的資源 -----|                 |
     +--------+                               +-----------------+

複製代碼

圖中所示的 抽象 OAuth 2.0 流程描述了四個角色之間的交互，包括如下步驟：

（A）客戶機請求資源全部者（用戶）的受權。受權請求能夠直接發送給資源全部者(如圖所示)，最好經過做爲中介的受權服務器間接發送。簡單地說，用戶點擊登陸，會轉到登陸頁面顯示給用戶。

（B）客戶端接收受權許可，這是表示資源全部者受權的憑據，使用 Oauth2 規範中定義的四種受權類型之一或使用擴展受權類型表示。受權授予類型取決於客戶機用於請求受權的方法和受權服務器支持的類型。簡單地說，選擇 oauth2 中四種受權模式進行受權。

（C）客戶端經過向受權服務器進行認證並呈現受權受權來請求訪問令牌。簡單地說，客戶端會向受權服務器使用前面選擇的四種方式之一請求認證。

（D）受權服務器對客戶端進行身份驗證並驗證受權授予，若是有效，則發出訪問令牌。簡單地說，受權成功發放令牌。

（E）客戶端從資源服務器請求受保護的資源，並經過呈現訪問令牌進行身份驗證。簡單地說，攜帶 令牌 請求資源服務器。

（F）資源服務器驗證訪問令牌，若是有效，則爲請求服務。簡單地說，若是令牌有效，就容許訪問資源。

（1）受權服務器能夠只有一臺，一臺受權能夠發放多個資源服務器。

（2）資源服務器須要關聯一臺受權服務器做爲資源的保護和認證。

最爲重要的部分爲 B 中的 受權許可，它是表明資源全部者的受權（訪問其受保護的資源）的憑據，客戶端使用該受權來得到訪問令牌。該規範定義了四種受權類型——受權代碼、隱式、資源全部者密碼憑證和客戶端憑證——以及用於定義其餘類型的可擴展性機制（自定義受權）。

四種受權模式

客戶端必須獲得用戶的受權（authorization grant），才能得到令牌（access token）。OAuth 2.0定義了四種受權方式以下：

  • 受權碼模式（authorization code）
  • 密碼模式（resource owner password credentials）
  • 簡化模式（implicit）
  • 客戶端模式（client credentials）
  • 擴展模式（extension）

最爲經常使用的爲第1、二種，咱們這篇文章也只會完成第一二種，四種具體請參考 阮一峯 理解OAuth 2.0 ，請注意詳細看文章的 名詞定義 模塊。阮一峯老師的文章已經寫的很清楚了，可是我依舊仍是須要指明一下咱們即將開始的第一二種的 api 設計。

注意：如下 api 設計爲 spring security 提供實現，並非 oauth2 的標準 api 實現

不過在那以前，咱們先來了解一下 客戶端的加密

客戶端加密

在 spring security oauth 中，推薦加密咱們的客戶端信息，客戶端和受權服務器創建適合受權服務器安全要求的客戶端認證方法。受權服務器能夠接受知足其安全要求的任何形式的客戶端身份驗證。通常來講咱們使用的是 密碼驗證 的方式加密咱們的客戶端信息。

推薦的方式是使用 HTTP Basic ，咱們須要設置如下參數，當設置成功之後將客戶端憑證加密存放在請求頭中去請求受權信息，參數以下：

參數名稱 是否必填 描述
client_id REQUIRED 客戶端 id
client_secret REQUIRED 客戶端密碼，若是客戶機secret是空字符串，則客戶機能夠省略該參數

當咱們請求的時候，須要設置相應的客戶端認證信息，並存放在請求頭中，設置方法以下：

Authorization: Basic client_id：client_secret base64編碼
 eg:
 client_id:web
 client_secret:secret
 加密「web:secret」 獲得 「QmFzaWMgd2ViOnNlY3JldA==」
 受權請求頭中須要攜帶以下鍵值對：
 Authorization: Basic QmFzaWMgd2ViOnNlY3JldA==
複製代碼

這是保證客戶端安全十分重要的一環，強烈推薦對客戶端進行加密！

受權碼模式

他是一種流程最爲嚴密，安全性最高的受權模式，主要爲如下幾個步驟：

注意：如下全部請求都必須在請求頭中攜帶上一點中的客戶端加密信息！

  1. 用戶進入應用，攜帶一個 重定向應用地址 到 受權服務器 進行登陸，在登陸成功而且用戶贊成受權之後，受權服務攜帶一個生成的 受權碼 重定向到指定的 重定向應用地址 。
  2. 應用攜帶接收到的 受權碼 再次去請求 受權服務器，在驗證成功後，驗證服務器下發 token。

因此須要兩個請求，在 spring security oauth2 中，api 以下，咱們將這些 api 稱爲 端點：

受權端點

  • /oauth/authorize：受權端點，經過此端點跳轉到 受權服務器 進行認證，完成第一個請求。攜帶以下參數：
參數名稱 是否必填 描述
response_type REQUIRED 必須爲 code
client_id REQUIRED 客戶端的 id
redirect_uri OPTIONAL 獲取受權碼後重定向地址
scope OPTIONAL 申請的權限範圍
state RECOMMENDED 客戶端的當前狀態，能夠指定任意值，認證服務器會原封不動地返回這個值，推薦。

受權成功的狀況，會攜帶如下兩個參數重定向到到 redirect_uri 中：

參數名稱 是否必有 描述
code REQUIRED 受權服務器生成的受權代碼。受權代碼必須在發佈後不久過時，以下降泄漏的風險。最大受權代碼生命週期爲10分鐘
state REQUIRED 若是上一步中提供 state 參數，會原封不動地返回這個值。

注意：官網中給出的解釋 code 有 RECOMMENDED 推薦的狀況，可是我沒找到如何使用，因此沒寫。

受權失敗的狀況分爲兩種

  1. 若是請求因爲重定向URI丟失、無效或不匹配而失敗，或者若是客戶端標識符丟失或無效，受權服務器應通知資源全部者錯誤，而且不得自動將用戶代理重定向到無效的重定向URI。
  2. 若是資源全部者拒絕訪問請求，或者若是請求因爲除了丟失或無效重定向URI之外的緣由而失敗，則受權服務器經過使用 application/x-www-form-urlencoded 格式向重定向 URI 的查詢組件添加如下參數來通知客戶端，參數以下：(對於 spring ，目前沒有遇到 error_uri 屬性)
參數名稱 是否必有 值 描述
error REQUIRED invalid_request 請求缺乏必需的參數，包括無效的參數值，不止一次地包含參數，或者存在其餘形式的異常。
unauthorized_client 未受權客戶端使用此方法請求受權代碼。
access_denied 資源全部者或受權服務器拒絕了該請求。
unsupported_response_type 受權服務器不支持使用此方法獲取受權代碼。
invalid_scope 請求的做用域無效、未知或格式不正確。
server_error 受權服務器遇到意外狀況，沒法知足請求。(此錯誤代碼是必需的，由於500內部服務器錯誤HTTP狀態代碼不能經過HTTP重定向返回給客戶端。)
temporarily_unavailable 因爲服務器暫時過載或維護，受權服務器當前沒法處理該請求。(此錯誤代碼是必需的，由於503服務不可用的HTTP狀態代碼不能經過HTTP重定向返回給客戶端。)
error_description OPTIONAL - 提供附加信息的人類可讀ASCII [USASCII]文本，用於幫助客戶端開發人員理解所發生的錯誤。
error_uri OPTIONAL 一種帶有錯誤信息的可讀網頁的URI標識，用於向客戶端開發人員提供有關錯誤的附加信息。

令牌端點

  • /oauth/token：令牌端點，經過上一步獲取到的 受權碼 驗證與生成令牌，完成第二個請求，攜帶以下參數：
參數名稱 是否必填 描述
grant_type REQUIRED 使用的受權模式，值固定爲"authorization_code"
code REQUIRED 上一步得到的受權碼
redirect_uri REQUIRED 重定向URI，必須與上一步中的該參數值保持一致
client_id REQUIRED 客戶端的 id
scope RECOMMENDED 受權範圍，必須與第一步相同

若是訪問令牌請求有效且通過受權，受權服務器將發出訪問令牌和可選的刷新令牌，能夠獲得以下響應參數：

參數名稱 是否必有 描述 是否有實現
access_token REQUIRED 受權服務器頒發的訪問令牌 是
token_type REQUIRED 令牌類型，該值大小寫不敏感，能夠是bearer類型或mac類型 是
expires_in RECOMMENDED 過時時間，單位爲秒 是
refresh_token OPTIONAL 表示更新令牌，用來獲取下一次的訪問令牌 是，須要設置
scope OPTIONAL 權限範圍，若是有，則與客戶端申請的範圍一致 是

若是請求客戶端身份驗證失敗或無效，受權服務器將返回錯誤響應，受權服務器使用HTTP 400（錯誤請求）狀態代碼進行響應（除非另有說明），並在響應中包含如下參數：

參數名稱 是否必有 值 描述
error REQUIRED invalid_request 請求缺乏必需的參數，包含不受支持的參數值(受權類型除外)，重複參數，包含多個憑據，使用多個機制來驗證客戶端，或者格式不正確。
invalid_client 客戶端身份驗證失敗(例如，未知客戶端、不包含客戶端身份驗證或不支持的身份驗證方法)。受權服務器能夠返回一個超文本傳輸協議401(未受權)狀態碼，以指示支持哪些超文本傳輸協議認證方案。若是客戶端試圖經過「受權」請求頭字段進行身份驗證，受權服務器必須用一個HTTP
401(未受權)狀態代碼進行響應，幷包括與客戶端使用的身份驗證方案相匹配的「WWW-Authenticate」響應頭字段。
invalid_grant 所提供的受權授予(例如，受權代碼、資源全部者憑證)或刷新令牌無效、過時、已撤銷、不匹配受權請求中使用的重定向URI，或已向其餘客戶機發出。
unauthorized_client 通過身份驗證的客戶端無權使用此受權受權類型。
unsupported_grant_type 受權服務器不支持受權受權類型。
invalid_scope 請求的範圍無效、未知、格式錯誤或超出了資源全部者授予的範圍。
error_description OPTIONAL - 提供附加信息的人類可讀ASCII [USASCII]文本，用於幫助客戶端開發人員理解所發生的錯誤。
error_uri OPTIONAL - 一種帶有錯誤信息的可讀網頁的URI標識，用於向客戶端開發人員提供有關錯誤的附加信息。

密碼模式

這種模式能夠理解成咱們普通應用的用戶名密碼登陸，在第三方接入的時候不建議使用這種模式，可是若是是本身的應用，那麼這種模式是最爲簡單方便快捷的了。步驟只有一個：

注意：如下全部請求都必須在請求頭中攜帶上面所說的客戶端加密信息！

  • 用戶攜帶用戶名密碼請求受權服務器，驗證經過後下發令牌

他只須要一個請求，因此她只有一個令牌端點：

令牌端點

  • /oauth/token：令牌端點，攜帶以下參數請求便可：
請求參數 是否必填 描述
grant_type REQUIRED 使用的密碼模式，值固定爲"password"
username REQUIRED 用戶名
password REQUIRED 密碼
scope OPTIONAL 請求權限範圍

請求成功和失敗的響應同受權碼模式。

安全考慮

注意：如下全部請求都必須在請求頭中攜帶上面所說的客戶端加密信息！

做爲一個靈活且可擴展的框架，OAuth 的安全考慮取決於許多因素。spring security oauth 爲咱們提供了一些默認的端點以下：

  • /oauth/authorize：受權端點
  • /oauth/token：令牌端點
  • /oauth/token：令牌端點也同時擁有刷新用戶的功能，請求參數以下：
參數名稱 是否必填 描述
grant_type REQUIRED 固定值爲「refresh_token」
refresh_token REQUIRED 請求到 token 時傳過來的 refresh_token
  • /oauth/confirm_access：用戶確認受權提交端點
  • /oauth/error：受權服務錯誤信息端點
  • /oauth/check_token：用於資源服務訪問的令牌解析端點，請求參數以下：
參數名稱 是否必填 描述
token REQUIRED 獲得的有效的令牌
  • /oauth/token_key：提供公有密匙的端點，若是你使用JWT令牌的話

技術選型

  • 核心框架：spring boot
  • 構建工具：maven
  • 應用框架：spring boot data jpa
  • 數據庫：mysql
  • web： spring boot web
  • 測試框架：junit五、spring boot test
  • 開發工具：idea
  • 安全框架：spring security oauth2

在這以前

咱們須要對項目的基本初始化，也就是使用 idea 建立咱們 spring boot 項目

1

2

3

4

父項目忘記添加 web 依賴了，以下：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
複製代碼

5

可選，配置阿里雲國內源倉庫

<repositories>
    <!--阿里雲主倉庫，代理了maven central和jcenter倉庫-->
    <repository>
        <id>aliyun</id>
        <name>aliyun</name>
        <url>https://maven.aliyun.com/repository/public</url>
        <releases>
            <enabled>true</enabled>
        </releases>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </repository>
    <!--阿里雲代理Spring 官方倉庫-->
    <repository>
        <id>spring-milestones</id>
        <name>Spring Milestones</name>
        <url>https://maven.aliyun.com/repository/spring</url>
        <releases>
            <enabled>true</enabled>
        </releases>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </repository>
</repositories>
<!--遠程插件庫-->
<pluginRepositories>
    <!--阿里雲代理Spring 插件倉庫-->
    <pluginRepository>
        <id>spring-plugin</id>
        <name>spring-plugin</name>
        <url>https://maven.aliyun.com/repository/spring-plugin</url>
        <releases>
            <enabled>true</enabled>
        </releases>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </pluginRepository>
</pluginRepositories>
複製代碼

注意：請自行配置 lombok 支持！！！

這樣，咱們的父項目基本就構建完成了

咱們下一篇回來完成第二件事，spring security oauth2 自動配置實現。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程