概述

網(wǎng)上有很多Spring Security和 oauth2的介紹，但是對于初學(xué)者來說，上手比較復(fù)雜，本篇從原理上梳理一下兩者之間的聯(lián)系和區(qū)別

1. 什么是Spring Security

spring security 的核心功能主要包括：

• 認(rèn)證 （你是誰） 通過注解 @EnableWebSecurity開啟
• 簡單來說，就是需要登錄，你需要輸入用戶名和密碼，才能訪問某個(gè)url。
• 授權(quán) （你能干什么） 不需要通過指定的開關(guān)開啟，而是通過配置來增加授權(quán)規(guī)則來生效，不增加授權(quán)規(guī)則就不生效
• 授權(quán)的目的是可以把資源進(jìn)行劃分，例如公司有不同的資料，有普通級(jí)別和機(jī)密級(jí)別，只有公司高層才能看到機(jī)密級(jí)別的子類，而普通級(jí)別的資料大家都可以看到！ 那么授權(quán)就是允許你查看某個(gè)資源，當(dāng)然，如果你沒有權(quán)限，就拒絕你查看！
• 授權(quán)有個(gè)前提就是先認(rèn)證才能授權(quán)，例如你是A公司的人，有A公司的卡牌，才能進(jìn)入A公司資料庫。如果是B公司的人，大門都不給你進(jìn)。

認(rèn)證可以單獨(dú)使用，即不劃分資源的級(jí)別，所有人只要登錄都可以查看

1.1 配置示例

public class MyWebSecurityConfig extends WebSecurityConfigurerAdapter {

    //配置安全攔截策略
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        //鏈?zhǔn)脚渲脭r截策略
        http
                .csrf().disable()//關(guān)閉csrg跨域檢查
                //這里注意matchere是有順序的。
                .authorizeRequests()
                .antMatchers("/user/**").hasAuthority("user")
                .antMatchers("/order/**").hasAuthority("order")
                .antMatchers("/common/**").permitAll() //common下的請求直接通過
                .antMatchers("/**.html","/js/**","/css/**","/img/**").permitAll()//放行靜態(tài)資源
                .anyRequest().authenticated() //其他請求需要登錄
                .and()//并行條件
                .formLogin()
                .loginPage("/index.html")//自定義登錄頁面
                .loginProcessingUrl("")
                .defaultSuccessUrl("/main.html").failureUrl("/common/loginFailed"); //可從默認(rèn)的login頁面登錄，并且登錄后跳轉(zhuǎn)到main.html
    }

簡單來說：

• 配置了 @EnableWebSecurity，就需要先登陸， .anyRequest().authenticated() 就是讓你登陸的意思
• 系統(tǒng)內(nèi)置了登陸頁面，一般情況下都是需要定制的，因此，通過 .loginPage(“/index.html”) 你可以指定自定義的登陸頁
• 由于有些資源是不需要登陸就行訪問的，例如登陸頁html，否則，形成死循環(huán)了。index.html等價(jià)于售票處，你總得讓游客免票入內(nèi)吧
• .antMatchers(“/user/**”).hasAuthority(“user”)用于定制哪些請求有額外要求，例如景區(qū)內(nèi)的廁所，先買大門票后，男的進(jìn)男側(cè)，不允許進(jìn)女廁

1.2 spring security 基本原理

spring security的核心就是一組過濾器鏈，項(xiàng)目啟動(dòng)后將會(huì)自動(dòng)配置。最核心的就是 Basic Authentication Filter 用來認(rèn)證用戶的身份，一個(gè)在spring security中一種過濾器處理一種認(rèn)證方式。

如下圖所示，這是一組鏈?zhǔn)教幚砥黝悾埱髲淖鐾乙来谓?jīng)過多個(gè)過濾器類處理：

比如，對于username password認(rèn)證過濾器來說：

會(huì)檢查是否是一個(gè)登錄請求；

是否包含username 和 password （也就是該過濾器需要的一些認(rèn)證信息） ；

如果不滿足則放行給下一個(gè)。

下一個(gè)按照自身職責(zé)判定是否是自身需要的信息，basic的特征就是在請求頭中有 Authorization:Basic eHh4Onh4 的信息。中間可能還有更多的認(rèn)證過濾器。

最后一環(huán)是 FilterSecurityInterceptor，這里會(huì)判定該請求是否能進(jìn)行訪問rest服務(wù)，判斷的依據(jù)是 BrowserSecurityConfig中的配置，如果被拒絕了就會(huì)拋出不同的異常（根據(jù)具體的原因）。

Exception Translation Filter 會(huì)捕獲拋出的錯(cuò)誤，然后根據(jù)不同的認(rèn)證方式進(jìn)行信息的返回提示。

注意：綠色的過濾器可以配置是否生效，其他的都不能控制。

1.2 Spring Security存在的問題

一般情況下 ，Spring Security 應(yīng)用在一個(gè)單體項(xiàng)目中，此時(shí)只存在一個(gè)獨(dú)立的項(xiàng)目，你訪問一個(gè)資源，需要輸入用戶名和密碼就行了

在多體應(yīng)用中，特別是存在第三方的場景下，我們存在這樣的需求：

• 假設(shè)你去注冊csdn的賬戶，那么需要填入手機(jī)號(hào)、昵稱、郵箱等信息，有的繁瑣，如果你已經(jīng)有了微信賬戶的話，那么csdn可以從微信處獲取這些信息，而你只需要通過手機(jī)掃一下就實(shí)現(xiàn)了，是不是很方便？
• oauth2協(xié)議應(yīng)運(yùn)而生。你去訪問csdn注冊頁面，然后頁面轉(zhuǎn)向微信登陸頁面(授權(quán)中心角色)，你輸入正確的用戶名和密碼(手機(jī)掃碼是輸入用戶名和密碼的一種變形)，然后csdn獲得了token，帶著token，訪問微信的用戶信息接口(資源中心角色)，微信返回用戶的郵箱等信息，csdn利用這些信息，完成注冊新用戶，入用戶表

什么是單體應(yīng)用？就是資源和檢查權(quán)限的系統(tǒng)都正在一個(gè)地方，傳統(tǒng)的注冊csdn手動(dòng)輸入郵箱，然后你登陸csdn，就是單體應(yīng)用，而我們?nèi)プ詂sdn，此時(shí)微信的個(gè)人信息數(shù)據(jù)就是第三方系統(tǒng)的，此時(shí)涉及csdn和微信2個(gè)系統(tǒng)

2. 什么是oauth2

此時(shí)一般的文章都是通過2個(gè)步驟來演示的，第一步 拿到token，通過瀏覽器發(fā)送一個(gè)請求，完成用戶名密碼登陸輸入，模擬獲取token過程，第二步 攜帶token獲取資源，通過postman發(fā)送請求模擬查詢資源

oauth2是一種協(xié)議，核心是用token令牌替換直接輸入用戶名和密碼的方式，通過該協(xié)議，可以實(shí)現(xiàn)跨服務(wù)至之間的授權(quán)功能。一般分為2個(gè)模塊，認(rèn)證授權(quán)中心和資源中心，資源中心可以有多個(gè)：

• 授權(quán)中心：負(fù)責(zé)頒發(fā)token，配置`@EnableAuthorizationServer
• 資源中心：負(fù)責(zé)檢查token(可以自己檢查，例如jwt本地檢查 或委托授權(quán)中心檢查)，檢查通過后發(fā)放資源。

基礎(chǔ)原理是這樣的：

• 授權(quán)中心頒發(fā)token
• 這個(gè)沒啥原理，就是讓用戶輸入用戶名和密碼，檢查下是否正確，然后返回一個(gè)token，說白了就是一個(gè)字符串，并存在授權(quán)中心的服務(wù)器上。
• 就像你買的飯票一樣，你用現(xiàn)金買了飯票，將來憑借飯票就可以領(lǐng)取一份盒飯！不需要再付錢了
• 向資源中心發(fā)起一個(gè)資源的查詢，資源中心檢查token，檢查通過后，發(fā)放資源。
• 關(guān)鍵點(diǎn)在于微信頒發(fā)的token，可以給csdn，csdn帶著token去微信獲取資源，這個(gè)步驟是在csdn后臺(tái)完成的，對用戶來說是隱藏的。也就是說csdn拿了飯票，去微信領(lǐng)盒飯了，不需要付錢(輸入密碼)，爽！

OAuth是Open Authority的縮寫，是令牌代替用戶密碼訪問應(yīng)用的又一標(biāo)準(zhǔn)， OAuth 協(xié)議存在第一代和第二代之分，后者稱為OAuth2，Spring OAuth2是實(shí)現(xiàn)OAuth2協(xié)議的具體的框架之一，你也可以使用其他的OAuth2框架。

對于大家而言，我們在互聯(lián)網(wǎng)應(yīng)用中最常見的 OAuth2 應(yīng)該就是各種第三方登錄了。利用OAuth2協(xié)議，我們在注冊csdn賬戶的時(shí)候，可以直接使用微信或QQ賬戶進(jìn)行注冊，這樣，僅需登陸微信或QQ，即可讓csdn獲取到用戶的昵稱、愛好、郵箱等基礎(chǔ)信息

2.1 那么如何實(shí)現(xiàn)檢查token的呢

答案在于 @EnableResourceServer注解，表示開啟資源中心功能，會(huì)有代理類負(fù)責(zé)登陸和授權(quán)的檢查：

如果某個(gè)服務(wù)的入口類被 @EnableResourceServer注解，說明現(xiàn)在是基于oauth2協(xié)議的架構(gòu)，那么原來的Spring Security配置會(huì)被覆蓋：

一般的Spring Security要求所有的請求url都要先判斷是否登錄，如果沒有登錄，就跳轉(zhuǎn)至登陸頁，然后檢查用戶名和密碼是否正確，但是資源中心注解會(huì)內(nèi)置有更高優(yōu)先級(jí)的攔截器，會(huì)修改這個(gè)默認(rèn)的邏輯，不是通過用戶名和密碼來檢查是否正確，而是通過檢查消息頭中的Authorization:Bearer xxx參數(shù)。

開啟資源中心，所有資源優(yōu)先用token方式進(jìn)行檢查，即檢查消息頭中是否含有 Authorization:Bearer xxx 這樣格式的；

如果沒有token，直接判定失敗；即使有了token，那么如何驗(yàn)證？可以本地驗(yàn)證，或轉(zhuǎn)發(fā)token至授權(quán)中心進(jìn)行判斷

授權(quán)中心頒發(fā)token后，會(huì)把token存儲(chǔ)在內(nèi)存中，這樣當(dāng)ABC服務(wù)獲得token后，轉(zhuǎn)發(fā)至授權(quán)中心，和內(nèi)存中存儲(chǔ)的原始值進(jìn)行比較就行了。

2.2 jwt

token默認(rèn)是明文的不安全，采用jwt，可以進(jìn)行加密，更安全！

加密有2種形式：

• 對稱加密
• 缺點(diǎn)：容易破解
• 非對稱加密
• 優(yōu)點(diǎn)：不容易破解

2.3 endpoint概念

授權(quán)中心需要配置endpoint，那么endpoint是什么？

授權(quán)中心內(nèi)置一些url，表示用于token特定的功能，這些url是免密使用的：

授權(quán)中心內(nèi)置很多url資源，例如/oauth/token，這些url就是endpoint概念

你可以去復(fù)寫/oauth/token 這樣的url

2.4 spring Security和 spring Security oauth2關(guān)系

從第一章節(jié)，我們知道， spring Security是一個(gè)框架，提供了認(rèn)證和授權(quán)功能，從本章得知oauth2是一個(gè)協(xié)議，光有協(xié)議也沒用，你的有具體的實(shí)現(xiàn)，那么spring Security oauth2是什么東西呢？

答案就是 spring Security框架內(nèi)置了oauth2的api，可以直接使用。當(dāng)然，其他框架也有oauth2的實(shí)現(xiàn)，你可以根據(jù)需求選擇。

3. spring cloud oauth2

我們在第二章節(jié)用到的語法，Spring Security的oauth2 是內(nèi)置在Spring Security包中的，例如@EnableAuthorizationServer 開啟授權(quán)中心注解是在spring-security-oauth2-2.3.4.RELEASE.jar，說明Spring Security框架已經(jīng)包含了oauth2協(xié)議的api接口：

從注解的package 能看出是springframework下的，說明是基礎(chǔ)包：

package org.springframework.security.oauth2.config.annotation.web.configuration;
public @interface EnableAuthorizationServer {
}

spring cloud oauth2是提供了一個(gè)starter，自動(dòng)引入相關(guān)的依賴包，僅僅是方便使用，并沒有新增特殊的功能:

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-oauth2</artifactId>
        </dependency>

4. sso單點(diǎn)登陸

通過前面的學(xué)習(xí)，我們知道，利用token原理，可以實(shí)現(xiàn)登陸一個(gè)系統(tǒng)后，只輸入一次用戶名和密碼，然后在cookie中保存這個(gè)token，再訪問其他系統(tǒng)時(shí)，帶上這個(gè)token，就可以直接訪問資源了。

oauth2的基本原理就是利用了token實(shí)現(xiàn)的，幫助我們利用第三方系統(tǒng)獲得資源。

單點(diǎn)登錄的英文名是 Single Sign On，因此一般簡稱為SSO。它的用途在于，不管多么復(fù)雜的應(yīng)用群，只要在用戶權(quán)限范圍內(nèi)，那么就可以做到，用戶只需要登錄一次就可以訪問權(quán)限范圍內(nèi)的所有應(yīng)用子系統(tǒng)。對于用戶而言，訪問多個(gè)應(yīng)用子系統(tǒng)只需要登錄一次，同樣在需要注銷的時(shí)候也只需要注銷一次。舉個(gè)簡單的例子，你在百度首頁登錄成功之后，你再訪問百度百科、百度知道、百度貼吧等網(wǎng)站也會(huì)處于登錄狀態(tài)了，這就是一個(gè)單點(diǎn)登錄的真實(shí)案例。

劃分為2類角色：

• 授權(quán)服務(wù)器 負(fù)責(zé)檢查是否授權(quán)及生成token
• 資源服務(wù)器，提供資源，如果發(fā)現(xiàn)沒有登陸，統(tǒng)一重定向至授權(quán)中心進(jìn)行token授權(quán)。多臺(tái)資源服務(wù)器可以共享同一個(gè)token，不用每次都生成token

特點(diǎn)是 檢查是否有權(quán)限的操作是在資源服務(wù)器上，即每個(gè)資源服務(wù)器都有檢查的邏輯。

缺點(diǎn)：sso默認(rèn)配置僅能解決登陸認(rèn)證問題，但是解決不了授權(quán)問題，即/user 和/order需要不同的權(quán)限

單點(diǎn)登陸和Oauth2的區(qū)別和聯(lián)系：

• 相似點(diǎn)都是利用token作為介質(zhì)
• 單點(diǎn)登陸側(cè)重多個(gè)子系統(tǒng)的場景，登陸一個(gè)，另幾個(gè)系統(tǒng)免登陸，簡單來說就是同一個(gè)公司下的不同子系統(tǒng)，而oauth2側(cè)重存在一個(gè)第三方系統(tǒng)，彼此完全獨(dú)立，簡單理解就是不同公司旗下的不同系統(tǒng)。
• 單點(diǎn)登陸側(cè)重認(rèn)證，即檢查是否登陸，一般不細(xì)分權(quán)限，即只要登陸即可，所有的功能都可以訪問。如果有角色概念，那么單點(diǎn)登陸就不能完全滿足，需要額外的工作去負(fù)責(zé)授權(quán)檢查；oauth2側(cè)重認(rèn)證+授權(quán)，屬于單一url的，一次只能訪問特定的資源，如果訪問多個(gè)資源，需要多個(gè)token
• sso實(shí)際上是擴(kuò)展了oauth2的功能，即擴(kuò)展了oauth2協(xié)議的，使之用于某個(gè)特殊場景，即帶有子系統(tǒng)的一個(gè)大系統(tǒng)！

也就是說不同公司之間的系統(tǒng)，采用oauth2就是完美方案！

如果是同一個(gè)公司的不同子系統(tǒng)，那么不考慮復(fù)雜的授權(quán)的場景下，單點(diǎn)登陸就是完美方案！

如果單點(diǎn)登陸同時(shí)需要考慮授權(quán)的情況，那么就要考慮授權(quán)功能，系統(tǒng)就更復(fù)雜了，需要sso+授權(quán)，例如下一章節(jié)就是該問題的解決方案！

5. 統(tǒng)一網(wǎng)關(guān)

從前面學(xué)習(xí)的示例來看，是不包含網(wǎng)關(guān)的，即sso項(xiàng)目是多個(gè)獨(dú)立服務(wù)都要進(jìn)行鑒權(quán)，每個(gè)服務(wù)都要配置一套鑒權(quán)系統(tǒng)，只不過是把具體的處理流程轉(zhuǎn)發(fā)至同一個(gè)鑒權(quán)中心了，只要登錄一次，就可以在多個(gè)服務(wù)中心共享登錄信息。那么有了網(wǎng)關(guān)之后怎么辦？

有了網(wǎng)關(guān)，可以在網(wǎng)關(guān)處進(jìn)行鑒權(quán)，后續(xù)的請求轉(zhuǎn)發(fā)至具體服務(wù)后，后者不再需要進(jìn)行鑒權(quán)了，或者網(wǎng)關(guān)暫不處理鑒權(quán)，轉(zhuǎn)發(fā)請求至具體的服務(wù)后，由服務(wù)自行進(jìn)行鑒權(quán)

有了網(wǎng)關(guān)之后，就有了統(tǒng)一的入口！

如果項(xiàng)目集成了網(wǎng)關(guān)，在網(wǎng)關(guān)里整合 OAuth2.0，實(shí)現(xiàn)單點(diǎn)登陸 有兩種思路：

一種是授權(quán)服務(wù)器生成令牌, 所有請求統(tǒng)一在網(wǎng)關(guān)層驗(yàn)證，判斷權(quán)限等操作；

• 優(yōu)點(diǎn)： 只有網(wǎng)關(guān)層一個(gè)模塊負(fù)責(zé)檢查權(quán)限，資源模塊都不用涉及
• 缺點(diǎn)：需要改造，對技術(shù)要求高

另一種是由各資源服務(wù)處理，網(wǎng)關(guān)只做請求轉(zhuǎn)發(fā)。 這種情況下，不用做特殊處理，等價(jià)于第四章節(jié)的sso單點(diǎn)登陸

• 優(yōu)點(diǎn)：保留現(xiàn)有架構(gòu)不動(dòng)，每個(gè)資源服務(wù)配置sso即可
• 缺點(diǎn)：每個(gè)資源服務(wù)配置sso，架構(gòu)上不好，存在冗余的感覺

比較常用的是第一種，把API網(wǎng)關(guān)作為OAuth2.0的資源服務(wù)器角色，實(shí)現(xiàn)接入客戶端權(quán)限攔截、令牌解析并轉(zhuǎn)發(fā)當(dāng)前登錄用戶信息給微服務(wù)，這樣下游微服務(wù)就不需要關(guān)心令牌格式解析以及OAuth2.0相關(guān)機(jī)制了。

網(wǎng)關(guān)在認(rèn)證授權(quán)體系里主要負(fù)責(zé)兩件事：

（1）作為OAuth2.0的資源服務(wù)器角色，實(shí)現(xiàn)接入方權(quán)限攔截。

（2）令牌解析并轉(zhuǎn)發(fā)當(dāng)前登錄用戶信息（明文token）給微服務(wù)

微服務(wù)拿到明文token(明文token中包含登錄用戶的身份和權(quán)限信息)后也需要做兩件事：

（1）用戶授權(quán)攔截（看當(dāng)前用戶是否有權(quán)訪問該資源）

（2）將用戶信息存儲(chǔ)進(jìn)當(dāng)前線程上下文（有利于后續(xù)業(yè)務(wù)邏輯隨時(shí)獲取當(dāng)前用戶信息）

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論