基本概念

認證: 用戶認證就是判斷一個用戶的身份是否合法的過程 ，用戶去訪問系統(tǒng)資源時系統(tǒng)要求驗證用戶的身份信息，身份合法方可繼續(xù)訪問，不合法則拒絕訪問。常見的用戶身份認證方式有:用戶名密碼登錄，二維碼登錄，手機短信登錄，指紋認證等方式。

會話:用戶認證通過后,為了避免用戶的每次操作都進行認證可將用戶的信息保證在會話中。會話就是系統(tǒng)為了保持當前用戶的登錄狀態(tài)所提供的機制,常見的有基于session方式、基于token方式等。

授權(quán):授權(quán)是用戶認證通過后根據(jù)用戶的權(quán)限來控制用戶訪問資源的過程,擁有資源的訪問權(quán)限則正常訪問，沒有權(quán)限則拒絕訪問。授權(quán)可簡單理解為Who對What(which)進行How操作，

Who，即主體( Subject)， 主體一般是指用戶，也可以是程序，需要訪問系統(tǒng)中的資源。

What，即資源( Resource)， 如系統(tǒng)菜單、頁面、按鈕、代碼方法、系統(tǒng)商品信息、系統(tǒng)訂單信息等。系統(tǒng)菜單、頁面、按鈕、代碼方法都屬于 系統(tǒng)功能資源,對于web系統(tǒng)每個功能資源通常對應(yīng)一個URL ;系統(tǒng)商品信息系統(tǒng)訂單信息都屬于 實體資源(數(shù)據(jù)資源)， 實體資源由資源類型和資源實例組成,比如商品信息為資源類型，商品編號為001的商品為資源實例。

How ,權(quán)限/許可( Permission)， 規(guī)定了用戶對資源的操作許可,權(quán)限離開資源沒有意義，如用戶查詢權(quán)限、用戶添加權(quán)限、某個代碼方法的調(diào)用權(quán)限、編號為001的用戶的修改權(quán)限等，通過權(quán)限可知用戶對哪些資源都有哪些操作許可。

• 授權(quán)的數(shù)據(jù)模型

• 資源和權(quán)限可以合并一起

• RBAC

基于角色的訪問控制 if (主體.hasRole()){}

基于資源的訪問控制 if(主體.hasPermission()){}

Spring Boot Security

對所有進入系統(tǒng)的請求進行攔截，校驗每個請求是否能夠訪問它所期望的資源，通過Filter實現(xiàn)

2.1 結(jié)構(gòu)原理

初始化Spring Security時，初始化一個類型為org.springframework.security.web.FilterChainProxy的過濾器，

外部的請求會經(jīng)過此類。FilterChainProxy是一個代理，真正起作用的是FilterChainProxy中SecurityFilterChain所包含的各個Filter，同時這些Filter作為Bean被Spring管理，它們是Spring Security核心，并不直接處理用戶的認證，也不直接處理用戶的授權(quán)，而是把它們交給了認證管理器（AuthenticationManager）和 決策管理器（AccessDecisionManager）進行處理

spring Security功能的實現(xiàn)主要是由一系列過濾器鏈相互配合完成。

2.2 認證過程

1. 用戶提交用戶名、密碼被SecurityFilterChain中的 UsernamePasswordAuthenticationFilter 過濾器獲取到，封裝為請求Authentication，通常情況下是UsernamePasswordAuthenticationToken這個實現(xiàn)類。

2. 然后過濾器將Authentication提交至認證管理器（AuthenticationManager）進行認證

3. 認證成功后， AuthenticationManager 身份管理器返回一個被填充滿了信息的（包括上面提到的權(quán)限信息，身份信息，細節(jié)信息，但密碼通常會被移除） Authentication 實例。

4. SecurityContextHolder 安全上下文容器將第3步填充了信息的 Authentication ，通過

SecurityContextHolder.getContext().setAuthentication(…)方法，設(shè)置到其中。

AuthenticationManager接口（認證管理器）是認證相關(guān)的核心接口，也是發(fā)起認證的出發(fā)點，它的實現(xiàn)類為ProviderManager。

而Spring Security支持多種認證方式，因此ProviderManager維護著一個List<AuthenticationProvider> 列表，存放多種認證方式，最終實際的認證工作是由AuthenticationProvider完成。不同的認證方式使用不同的AuthenticationProvider。如使用用戶名密碼登錄時，使用DaoAuthenticationProvide

DaoAuthenticationProvider，它的內(nèi)部又維護著一個UserDetailsService負責(zé)UserDetails的獲取。最終AuthenticationProvider將UserDetails填充至Authentication。

2.3 密碼處理

Spring Security提供了很多內(nèi)置的PasswordEncoder，能夠開箱即用，使用某種PasswordEncoder只需要進行如

• 下聲明即可

常見的密碼編碼器有：

NoOpPasswordEncoder、BCryptPasswordEncoder、Pbkdf2PasswordEncode、SCryptPasswordEncoder

2.4 授權(quán)過程

已認證用戶訪問受保護的web資源將被SecurityFilterChain中的 FilterSecurityInterceptor 的子類攔截。

• FilterSecurityInterceptor會從 SecurityMetadataSource 的子類DefaultFilterInvocationSecurityMetadataSource 獲取要訪問當前資源所需要的權(quán)限Collection<ConfigAttribute>
• SecurityMetadataSource其實就是讀取“安全攔截機制”
• FilterSecurityInterceptor會調(diào)用 AccessDecisionManager 進行授權(quán)決策，若決策通過，則允許訪問資源，否則將禁止訪問。

此處會從安全上下文中獲取用戶：

Authentication authentication = SecurityContextHolder.getContext().getAuthentication(); 

再進行比對和判斷。

• decide接口就是用來鑒定當前用戶是否有訪問對應(yīng)受保護資源的權(quán)限。
• authentication：要訪問資源的訪問者的身份
• object：要訪問的受保護資源，web請求對應(yīng)FilterInvocation
• confifigAttributes：是受保護資源的訪問策略，通過SecurityMetadataSource獲取。

Spring Security內(nèi)置了三個基于投票的AccessDecisionManager實現(xiàn)類

• AffirmativeBased 只要有一個贊成票，則表示同意用戶訪問
• ConsensusBased：贊成票多余反對票，則表示同意用戶訪問
• UnanimousBased：只要有一個反對票，則表示反對用戶訪問

spring security為防止CSRF（Cross-site request forgery跨站請求偽造）的發(fā)生，限制了除了get以外的大多數(shù)方法，

解決方法1：

屏蔽CSRF控制，即spring security不再限制CSRF。

httpSecurity.csrf().disable()

解決方法2：

表單添加隱藏域:

<input type="hidden" name="${_csrf.parameterName}" value="${_csrf.token}"/>

2.5 實際應(yīng)用

用戶認證通過后，為了避免用戶的每次操作都進行認證可將用戶的信息保存在會話中。spring security提供會話管理，認證通過后將身份信息放入SecurityContextHolder上下文，SecurityContext與當前線程進行綁定，方便獲取用戶身份。

Authentication authentication = SecurityContextHolder.getContext().getAuthentication();

2.5.1 會話控制

• Spring Security會為每個登錄成功的用戶會新建一個Session

httpSecurity.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)

• session超時、session失效后，通過Spring Security 設(shè)置跳轉(zhuǎn)的路徑。

httpSecurity.sessionManagement()
.expiredUrl("/login‐view?error=EXPIRED_SESSION")
.invalidSessionUrl("/login‐view?error=INVALID_SESSION");

• session退出

httpSecurity.logout()

.logoutUrl("/logout")
.logoutSuccessUrl("/login‐view?logout")
.logoutSuccessHandler(logoutSuccessHandler)
.addLogoutHandler(logoutHandler)
.invalidateHttpSession(true)

定制的 LogoutSuccessHandler ，實現(xiàn)用戶退出成功時的處理。如果指定了這個選項那么logoutSuccessUrl() 的設(shè)置被忽略；

添加一個 LogoutHandler ，用于實現(xiàn)用戶退出時的清理工作.默認 SecurityContextLogoutHandler 會被添加為最后一個 LogoutHandler；

指定是否在退出時讓 HttpSession 無效。 默認設(shè)置為 true。

2.5.2 web授權(quán)

使用 http.authorizeRequests() 對web資源進行授權(quán)保護

httpSecurity
.authorizeRequests()
.antMatchers("/r/r1").hasAuthority("p1") (
.antMatchers("/r/r2").hasAuthority("p2")
.antMatchers("/r/r3").access("hasAuthority('p1') and hasAuthority('p2')")
.antMatchers("/r/**").authenticated()
.anyRequest().permitAll()
.and()
.formLogin()

保護URL常用的方法有：

• authenticated() 保護URL，需要用戶登錄
• permitAll() 指定URL無需保護，一般應(yīng)用與靜態(tài)資源文件
• hasRole(String role) 限制單個角色訪問，角色將被增加 “ROLE_” .所以”ADMIN” 將和 “ROLE_ADMIN”進行比較.
• hasAuthority(String authority) 限制單個權(quán)限訪問
• hasAnyRole(String… roles)允許多個角色訪問.
• hasAnyAuthority(String… authorities) 允許多個權(quán)限訪問.
• access(String attribute) 該方法使用 SpEL表達式, 所以可以創(chuàng)建復(fù)雜的限制.
• hasIpAddress(String ipaddressExpression) 限制IP地址或子網(wǎng)

2.5.3.方法授權(quán)

以在任何 @Configuration 實例上使用 @EnableGlobalMethodSecurity 注釋來啟用基于注解的安全性。

@PreAuthorize,@PostAuthorize, @Secured三類注解作用域服務(wù)層方法上，限制訪問的訪問

例如：

匿名訪問

@Secured("IS_AUTHENTICATED_ANONYMOUSLY")
@PreAuthorize("isAnonymous()")

方法可匿名訪問，底層使用WebExpressionVoter投票器

• @PreAuthorize

@PreAuthorize("hasAuthority('p_transfer') and hasAuthority('p_read_account')")

同時擁有p_transfer和p_read_account權(quán)限才能訪問，底層使用WebExpressionVoter投票器

另外，還有注解@PostAuthorize

分布式系統(tǒng)認證方案

軟件的架構(gòu)由單體結(jié)構(gòu)演變?yōu)榉植际郊軜?gòu)，具有分布式架構(gòu)的系統(tǒng)叫分布式系統(tǒng)，分布式系統(tǒng)的運行通常依賴網(wǎng)絡(luò)，它將單體結(jié)構(gòu)的系統(tǒng)分為若干服務(wù)，服務(wù)之間通過網(wǎng)絡(luò)交互來完成用戶的業(yè)務(wù)處理，當前流行的微服務(wù)架構(gòu)就是分布式系統(tǒng)架構(gòu)。

3.1 分布式認證需求

分布式系統(tǒng)的每個服務(wù)都會有認證、授權(quán)的需求，考慮分布式系統(tǒng)共享性的特點，需要由獨立的認證服務(wù)處理系統(tǒng)認證授權(quán)的請求；考慮分布式系統(tǒng)開放性的特點，不僅對系統(tǒng)內(nèi)部服務(wù)提供認證，對第三方系統(tǒng)也要提供認證。分布式認證的需求總結(jié)如下：

統(tǒng)一認證授權(quán)

提供獨立的認證服務(wù)，統(tǒng)一處理認證授權(quán)。無論是不同類型的用戶，還是不同種類的客戶端(web端，H5、APP)，均采用一致的認證、權(quán)限、會話機制，實現(xiàn)統(tǒng)一認證授權(quán)。要實現(xiàn)統(tǒng)一則認證方式必須可擴展，支持各種認證需求，比如：用戶名密碼認證、短信驗證碼、二維碼、人臉識別等認證方式，并可以非常靈活的切換。

應(yīng)用接入認證

應(yīng)提供擴展和開放能力，提供安全的系統(tǒng)對接機制，并可開放部分API給接入第三方使用，一方應(yīng)用（內(nèi)部系統(tǒng)服務(wù)）和三方應(yīng)用（第三方應(yīng)用）均采用統(tǒng)一機制接入。

3.2 選型分析

3.2.1 基于Session認證

每個應(yīng)用服務(wù)都需要在session中存儲用戶身份信息，通常的做法有下面幾種：

• Session復(fù)制：多臺應(yīng)用服務(wù)器之間同步session，使session保持一致，對外透明。
• Session黏貼：當用戶訪問集群中某臺服務(wù)器后，強制指定后續(xù)所有請求均落到此機器上。
• Session集中存儲：將Session存入分布式緩存中，所有服務(wù)器應(yīng)用實例統(tǒng)一從分布式緩存中存取Session。

基于session認證的認證方式，可以更好的在服務(wù)端對會話進行控制，且安全性較高。但是，session機制方式基于cookie，在復(fù)雜多樣的移動客戶端上不能有效的使用，并且無法跨域，另外隨著系統(tǒng)的擴展需提高session的復(fù)制、黏貼及存儲的容錯性。

3.2.2 基于Token認證

基于token的認證方式，服務(wù)端不用存儲認證數(shù)據(jù)，易維護擴展性強， 客戶端可以把token 存在任意地方，并且可以實現(xiàn)web和app統(tǒng)一認證機制。其缺點也很明顯，token由于自包含信息，因此一般數(shù)據(jù)量較大，而且每次請求都需要傳遞，因此比較占帶寬。另外，token的簽名驗簽操作也會給cpu帶來額外的處理負擔。

3.2.3 技術(shù)方案

根據(jù) 選型分析，采用token認證，它的優(yōu)點是：

• 適合統(tǒng)一認證的機制，客戶端、一方應(yīng)用、三方應(yīng)用都遵循一致的認證機制。
• token認證方式對第三方應(yīng)用接入更適合，因為它更開放，可使用當前有流行的開放協(xié)議Oauth2.0、JWT等。
• 一般情況服務(wù)端無需存儲會話信息，減輕了服務(wù)端的壓力。

3.3 Oauth2.0

OAuth（開放授權(quán)）是一個開放標準，允許用戶授權(quán)第三方應(yīng)用訪問他們存儲在另外的服務(wù)提供者上的信息，而不需要將用戶名和密碼提供給第三方應(yīng)用或分享他們數(shù)據(jù)的所有內(nèi)容。例如，第三方登錄，用戶 授權(quán) 電商網(wǎng)站 訪問 用戶存儲在微信平臺的用戶信息

OAauth2.0包括以下角色：

客戶端

本身不存儲資源，需要通過資源擁有者的授權(quán)去請求資源服務(wù)器的資源，比如：Android客戶端、Web客戶端（瀏覽器端）、微信客戶端等。

資源擁有者

通常為用戶，也可以是應(yīng)用程序，即該資源的擁有者。

資源服務(wù)器

存儲資源的服務(wù)器，例如微信平臺用戶信息資源。

服務(wù)提供商會給準入的接入方一個身份，用于接入時的憑據(jù):

• client_id：客戶端標識
• client_secret：客戶端秘鑰

授權(quán)服務(wù)器（也稱認證服務(wù)器）

用于服務(wù)提供商對資源擁有的身份進行認證、對訪問資源進行授權(quán)，認證成功后會給客戶端發(fā)放令牌，作為客戶端訪問資源服務(wù)器的憑據(jù)。例如：微信認證服務(wù)器。

授權(quán)服務(wù)器對OAuth2.0中的兩個角色進行認證授權(quán)，分別是資源擁有者、客戶端

Spring Cloud Security OAuth2

Spring-Security-OAuth2是對OAuth2的一種實現(xiàn)，并且跟Spring Security相輔相成，與SpringCloud體系的集成也非常便利。其服務(wù)實現(xiàn)包括兩個服務(wù)：

認證授權(quán)服務(wù) (Authorization Server）

應(yīng)包含對接入端以及登入用戶的合法性進行驗證并頒發(fā)token等功能，對令牌的請求端點由 Spring MVC 控制器進行實現(xiàn)，下面是配置一個認證服務(wù)必須要實現(xiàn)的endpoints：

• AuthorizationEndpoint 服務(wù)于認證請求。默認 URL：/oauth/authorize 。
• TokenEndpoint 服務(wù)于訪問令牌的請求。默認 URL：/oauth/token 。

資源服務(wù) (Resource Server)，應(yīng)包含對資源的保護功能，對非法請求進行攔截，對請求中token進行解析鑒權(quán)等，下面的過濾器用于實現(xiàn) OAuth 2.0 資源服務(wù)：

OAuth2AuthenticationProcessingFilter用來對請求給出的身份令牌解析鑒權(quán)。

4.1 授權(quán)服務(wù)器配置

可以使用

@Configuration
@EnableAuthorizationServer

注解并繼承AuthorizationServerConfifigurerAdapter來配置OAuth2.0 授權(quán)服務(wù)器。

• AuthorizationServerConfifigurerAdapter要求配置
• ClientDetailsServiceConfifigurer：用來配置客戶端詳情服務(wù)（ClientDetailsService），客戶端詳情信息在這里進行初始化
• AuthorizationServerEndpointsConfifigurer：用來配置令牌（token）的訪問端點和令牌服務(wù)(tokenservices)。
• AuthorizationServerSecurityConfifigurer：用來配置令牌訪問端點的安全約束

4.1.1 客戶端詳情

ClientDetailsServiceConfifigurer能夠使用內(nèi)存或者JDBC來實現(xiàn)客戶端詳情，ClientDetailsService負責(zé)查找ClientDetails，而ClientDetails有幾個重要的屬性

客戶端詳情（Client Details）能夠在應(yīng)用程序運行的時候進行更新，可以通過訪問底層的存儲服務(wù)（例如將客戶端詳情存儲在一個關(guān)系數(shù)據(jù)庫的表中，就可以使用 JdbcClientDetailsService）或者通過實現(xiàn)

ClientRegistrationService接口（同時你也可以實現(xiàn) ClientDetailsService 接口）來管理。

此次客戶端詳情讀取數(shù)據(jù)庫的配置：

4.1.2令牌管理服務(wù)

AuthorizationServerTokenServices 接口定義了一些操作可以對令牌進行一些必要的管理,這個接口的實現(xiàn)，則需要繼承 DefaultTokenServices,里面包含了一些有用實現(xiàn)，你可以使用它來修改令牌的格式和令牌的存儲，其持久化令牌委托一個 TokenStore 接口來實現(xiàn)，TokenStore 這個接口有一個默認的實現(xiàn)，它就是 InMemoryTokenStore。

• InMemoryTokenStore：

這個版本的實現(xiàn)是被默認采用的，它可以完美的工作在單服務(wù)器上（即訪問并發(fā)量壓力不大的情況下，并且它在失敗的時候不會進行備份），大多數(shù)的項目都可以使用這個版本的實現(xiàn)來進行嘗試，可以在開發(fā)的時候使用它來進行管理，因為不會被保存到磁盤中，更易于調(diào)試。

• JdbcTokenStore：

這是一個基于JDBC的實現(xiàn)版本，令牌會被保存進關(guān)系型數(shù)據(jù)庫。

使用這個版本的實現(xiàn)時，你可以在不同的服務(wù)器之間共享令牌信息，使用這個版本的時候需要把"spring-jdbc"這個依賴加入到classpath。

• JwtTokenStore:

這個版本的全稱是 JSON Web Token（JWT），它可以把令牌相關(guān)的數(shù)據(jù)進行編碼（因此對于后端服務(wù)來說，它不需要進行存儲，這將是一個重大優(yōu)勢），但是它有一個缺點，那就是撤銷一個已經(jīng)授權(quán)令牌將會非常困難，所以它通常用來處理一個生命周期較短的令牌以及撤銷刷新令牌（refresh_token）。

另外一個缺點就是這個令牌占用的空間會比較大，如果你加入了比較多用戶憑證信息。

JwtTokenStore 不會保存任何數(shù)據(jù)，但是它在轉(zhuǎn)換令牌值以及授權(quán)信息方面與 DefaultTokenServices 所扮演的角色是一樣的。

4.1.3 令牌訪問端點

4.1.3.1 認證管理器

AuthorizationServerEndpointsConfifigurer通過設(shè)定以下屬性決定支持的授權(quán)類型（Grant Types）:

• authenticationManager

認證管理器，選擇了資源所有者密碼（password）授權(quán)類型的時候，請設(shè)置這個屬性注入一個 AuthenticationManager 對象。

• userDetailsService

設(shè)置了這個屬性，需要有一個 UserDetailsService 接口的實現(xiàn)

• authorizationCodeServices

用來設(shè)置授權(quán)碼服務(wù)（即 AuthorizationCodeServices 的實例對象），主要用于 "authorization_code" 授權(quán)碼類型模式。

• implicitGrantServic

這個屬性用于設(shè)置隱式授權(quán)模式，用來管理隱式授權(quán)模式的狀態(tài)。

• tokenGranter

授權(quán)將會交由自己來完全掌控，并且會忽略掉上面的這幾個屬性，這個屬性一般是用作拓展用途

4.1.3.2 令牌訪問點

框架的默認URL訪問鏈接如下列表

• /oauth/authorize：授權(quán)端點。
• /oauth/token：令牌端點。
• /oauth/confifirm_access：用戶確認授權(quán)提交端點。
• /oauth/error：授權(quán)服務(wù)錯誤信息端點。
• /oauth/check_token：用于資源服務(wù)訪問的令牌解析端點。
• /oauth/token_key：提供公有密匙的端點，如果你使用JWT令牌的話。

AuthorizationServerEndpointsConfifigurer 這個配置對象有一個叫做 pathMapping() 的方法用來配置端點URL鏈接，它有兩個參數(shù)：

• 第一個參數(shù)：String 類型的，這個端點URL的默認鏈接。
• 第二個參數(shù)：String 類型的，你要進行替代的URL鏈接。

4.1.4 令牌訪問端點安全約束

• AuthorizationServerSecurityConfigurer: ：用來配置令牌端點(Token Endpoint)的安全約束

4.1.5 WEB安全配置

4.1.6 授權(quán)類型

4.1.6.1授權(quán)碼模式

資源擁有者打開客戶端，客戶端要求資源擁有者給予授權(quán)，它將瀏覽器被重定向到授權(quán)服務(wù)器，重定向時會附加客戶端的身份信息

/uaa/oauth/authorize?client_id=c1&response_type=code&scope=all&redirect_uri=http://www.baidu.com

瀏覽器出現(xiàn)向授權(quán)服務(wù)器授權(quán)頁面，之后用戶同意授權(quán)

授權(quán)服務(wù)器將授權(quán)碼（AuthorizationCode）經(jīng)瀏覽器發(fā)送給client

客戶端拿著授權(quán)碼向授權(quán)服務(wù)器索要訪問access_token

/uaa/oauth/token?client_id=c1&client_secret=secret&grant_type=authorization_code&code=5PgfcD&redirect_uri=http://www.baidu.com

授權(quán)服務(wù)器返回令牌(access_token)

參數(shù)列表如下:

• client_id：客戶端準入標識。
• response_type：授權(quán)碼模式固定為code。
• scope：客戶端權(quán)限。
• client_secret：客戶端秘鑰。
• grant_type：授權(quán)類型，填寫authorization_code，表示授權(quán)碼模式
• code：授權(quán)碼，就是剛剛獲取的授權(quán)碼，注意：授權(quán)碼只使用一次就無效了，需要重新申請。
• redirect_uri：申請授權(quán)碼時的跳轉(zhuǎn)url，一定和申請授權(quán)碼時用的redirect_uri一致。

4.1.6.2 簡化模式

資源擁有者打開客戶端，客戶端要求資源擁有者給予授權(quán)，它將瀏覽器被重定向到授權(quán)服務(wù)器，重定向時會附加客戶端的身份信息

/uaa/oauth/authorize?client_id=c1&response_type=token&scope=all&redirect_uri=http://www.baidu.com

瀏覽器出現(xiàn)向授權(quán)服務(wù)器授權(quán)頁面，之后用戶同意授權(quán)

授權(quán)服務(wù)器將授權(quán)碼將令牌（access_token）以Hash的形式存放在重定向uri的fargment中發(fā)送給瀏覽器。fragment 主要是用來標識 URI 所標識資源里的某個資源，在 URI 的末尾通過 （#）作為 fragment 的開頭，其中 # 不屬于 fragment 的值。

4.1.6.3 密碼模式

資源擁有者將用戶名、密碼發(fā)送給客戶端

客戶端拿著資源擁有者的用戶名、密碼向授權(quán)服務(wù)器請求令牌（access_token）

/uaa/oauth/token?

client_id=c1&client_secret=secret&grant_type=password&username=shangsan&password=123

授權(quán)服務(wù)器將令牌（access_token）發(fā)送給client

4.1.6.4 客戶端模式

客戶端向授權(quán)服務(wù)器發(fā)送自己的身份信息，并請求令牌（access_token）

確認客戶端身份無誤后，將令牌（access_token）發(fā)送給client

/uaa/oauth/token?client_id=c1&client_secret=secret&grant_type=client_credentials

4.2資源服務(wù)器配置

@Configuration
@EnableResourceServer
public class ResouceServerConfig extends ResourceServerConfigurerAdapter

@EnableResourceServer 注解自動增加了一個類型為 OAuth2AuthenticationProcessingFilter 的過濾器鏈

ResourceServerSecurityConfifigurer中主要包括：

• tokenServices：ResourceServerTokenServices 類的實例，用來實現(xiàn)令牌服務(wù)。
• tokenStore：TokenStore類的實例，指定令牌如何訪問，與tokenServices配置可選
• resourceId：這個資源服務(wù)的ID，這個屬性是可選的，但是推薦設(shè)置并在授權(quán)服務(wù)中進行驗證。

其他的拓展屬性例如 tokenExtractor 令牌提取器用來提取請求中的令牌。

HttpSecurity配置這個與Spring Security類似：

請求匹配器，用來設(shè)置需要進行保護的資源路徑，默認的情況下是保護資源服務(wù)的全部路徑。

通過http.authorizeRequests()來設(shè)置受保護資源的訪問規(guī)則

其他的自定義權(quán)限保護規(guī)則通過 HttpSecurity 來進行配置。

RemoteTokenServices 資源服務(wù)器通過 HTTP 請求來解碼令牌，每次都請求授權(quán)服務(wù)器端點 /oauth/check_token

此處使用JWT校驗令牌

配置安全攔截機制

@EnableResourceServer 注解自動增加了一個類型為 OAuth2AuthenticationProcessingFilter 的過濾器鏈,此過濾器作用，主要是用來解析網(wǎng)關(guān)傳過來的用戶信息字符串，并存入安全上下文中

4.3 網(wǎng)關(guān)

網(wǎng)關(guān)整合 OAuth2.0作為OAuth2.0的資源服務(wù)器角色，實現(xiàn)接入客戶端權(quán)限攔截、令牌解析并轉(zhuǎn)發(fā)當前登錄用戶信息(jsonToken)給微服務(wù)

public class AuthFilter extends ZuulFilter

校驗客戶端token，驗證接入客戶端權(quán)限，并解析后明文token，轉(zhuǎn)發(fā)請求到微服務(wù)

總結(jié)

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

最新評論