認證鑑權與API權限控制在微服務架構中的設計與實現（四）

時間 2019-11-16

原文原文鏈接

引言：本文系《認證鑑權與API權限控制在微服務架構中的設計與實現》系列的完結篇，前面三篇已經將認證鑑權與API權限控制的流程和主要細節講解完。本文比較長，對這個系列進行收尾，主要內容包括對受權和鑑權流程以外的endpoint以及Spring Security過濾器部分踩坑的經歷。歡迎閱讀本系列文章。html

1. 前文回顧

首先仍是照例對前文進行回顧。在第一篇認證鑑權與API權限控制在微服務架構中的設計與實現（一）介紹了該項目的背景以及技術調研與最後選型。第二篇認證鑑權與API權限控制在微服務架構中的設計與實現（二）畫出了簡要的登陸和校驗的流程圖，並重點講解了用戶身份的認證與token發放的具體實現。第三篇認證鑑權與API權限控制在微服務架構中的設計與實現（三）先介紹了資源服務器配置，以及其中涉及的配置類，後面重點講解了token以及API級別的鑑權。 java

本文將會講解剩餘的兩個內置端點：註銷和刷新token。註銷token端點的處理與Spring Security默認提供的有些'/logout'有些區別，不只清空SpringSecurityContextHolder中的信息，還要增長對存儲token的清空。另外一個刷新token端點其實和以前的請求受權是同樣的API，只是參數中的grant_type不同。 git

除了以上兩個內置端點，後面將會重點講下幾種Spring Security過濾器。API級別的操做權限校驗原本設想是經過Spring Security的過濾器實現，特意把這邊學習了一遍，踩了一遍坑。 github

最後是本系列的總結，並對於存在的不足和後續工做進行論述。web

2. 其餘端點

2.1 註銷端點

在第一篇中提到了Auth系統內置的註銷端點 /logout，若是還記得第三篇資源服務器的配置，下面的關於/logout配置必定不陌生。spring

//...
                .and().logout()
                .logoutUrl("/logout")
                .clearAuthentication(true)
                .logoutSuccessHandler(new HttpStatusReturningLogoutSuccessHandler())
                .addLogoutHandler(customLogoutHandler());複製代碼

上面配置的主要做用是：數據庫

設置註銷的URL
清空Authentication信息
設置註銷成功的處理方式
設置自定義的註銷處理方式

固然在LogoutConfigurer中還有更多的設置選項，筆者此處列出項目所須要的配置項。這些配置項圍繞着LogoutFilter過濾器。順帶講一下Spring Security的過濾器。其使用了springSecurityFillterChian做爲了安全過濾的入口，各類過濾器按順序具體以下：後端

SecurityContextPersistenceFilter：與SecurityContext安全上下文信息有關
HeaderWriterFilter：給http響應添加一些Header
CsrfFilter：防止csrf攻擊，默認開啓
LogoutFilter：處理註銷的過濾器
UsernamePasswordAuthenticationFilter：表單認證過濾器
RequestCacheAwareFilter：緩存request請求
SecurityContextHolderAwareRequestFilter：此過濾器對ServletRequest進行了一次包裝，使得request具備更加豐富的API
AnonymousAuthenticationFilter：匿名身份過濾器
SessionManagementFilter：session相關的過濾器，經常使用來防止session-fixation protection attack，以及限制同一用戶開啓多個會話的數量
ExceptionTranslationFilter：異常處理過濾器
FilterSecurityInterceptor：web應用安全的關鍵Filter

各類過濾器簡單標註了做用，在下一節重點講其中的幾個過濾器。註銷過濾器排在靠前的位置，咱們一塊兒看下LogoutFilter的UML類圖。api

類圖和咱們以前配置時的思路是一致的，HttpSecurity建立了LogoutConfigurer，咱們在這邊配置了LogoutConfigurer的一些屬性。同時LogoutConfigurer根據這些屬性建立了LogoutFilter。緩存

LogoutConfigurer的配置，第一和第二點就不用再詳細解釋了，一個是設置端點，另外一個是清空認證信息。
對於第三點，配置註銷成功的處理方式。因爲項目是先後端分離，客戶端只須要知道執行成功該API接口的狀態，並不用返回具體的頁面或者繼續向下傳遞請求。所以，這邊配置了默認的HttpStatusReturningLogoutSuccessHandler，成功直接返回狀態碼200。
對於第四點配置，自定義註銷處理的方法。這邊須要藉助TokenStore，對token進行操做。TokenStore在以前文章的配置中已經講過，使用的是JdbcTokenStore。首先校驗請求的合法性，若是合法則對其進行操做，前後移除refreshToken和existingAccessToken。

public class CustomLogoutHandler implements LogoutHandler {

    //...

    @Override
    public void logout(HttpServletRequest request, HttpServletResponse response, Authentication authentication) {
        //肯定注入了tokenStore
        Assert.notNull(tokenStore, "tokenStore must be set");
       //獲取頭部的認證信息
        String token = request.getHeader("Authorization");
        Assert.hasText(token, "token must be set");
        //校驗token是否符合JwtBearer格式
        if (isJwtBearerToken(token)) {
            token = token.substring(6);
            OAuth2AccessToken existingAccessToken = tokenStore.readAccessToken(token);
            OAuth2RefreshToken refreshToken;
            if (existingAccessToken != null) {
                if (existingAccessToken.getRefreshToken() != null) {
                    LOGGER.info("remove refreshToken!", existingAccessToken.getRefreshToken());
                    refreshToken = existingAccessToken.getRefreshToken();
                    tokenStore.removeRefreshToken(refreshToken);
                }
                LOGGER.info("remove existingAccessToken!", existingAccessToken);
                tokenStore.removeAccessToken(existingAccessToken);
            }
            return;
        } else {
            throw new BadClientCredentialsException();
        }

    }

    //...
}複製代碼

執行以下請求：

method: get
url: http://localhost:9000/logout
header:
{
    Authorization: Basic ZnJvbnRlbmQ6ZnJvbnRlbmQ=
}複製代碼

註銷成功則會返回200，將token和SecurityContextHolder進行清空。

2.2 刷新端點

在第一篇就已經講過，因爲token的時效通常不會很長，而refresh token通常週期會很長，爲了避免影響用戶的體驗，可使用refresh token去動態的刷新token。刷新token主要與RefreshTokenGranter有關，CompositeTokenGranter管理一個List列表，每一種grantType對應一個具體的真正受權者，refresh_ token對應的granter就是RefreshTokenGranter，而granter內部則是經過grantType來區分是不是各自的受權類型。執行以下請求：

method: post 
url: http://localhost:12000/oauth/token?grant_type=refresh_token&refresh_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJYLUtFRVRTLVVzZXJJZCI6ImQ2NDQ4YzI0LTNjNGMtNGI4MC04MzcyLWMyZDYxODY4ZjhjNiIsInVzZXJfbmFtZSI6ImtlZXRzIiwic2NvcGUiOlsiYWxsIl0sImF0aSI6ImJhZDcyYjE5LWQ5ZjMtNDkwMi1hZmZhLTA0MzBlN2RiNzllZCIsImV4cCI6MTUxMDk5NjU1NiwianRpIjoiYWE0MWY1MjctODE3YS00N2UyLWFhOTgtZjNlMDZmNmY0NTZlIiwiY2xpZW50X2lkIjoiZnJvbnRlbmQifQ.mICT1-lxOAqOU9M-Ud7wZBb4tTux6OQWouQJ2nn1DeE
header:
{
    Authorization: Basic ZnJvbnRlbmQ6ZnJvbnRlbmQ=
}複製代碼

在refresh_ token正確的狀況下，其返回的response和/oauth/token獲得正常的響應是同樣的。具體的代碼能夠參閱第二篇的講解。

3. `Spring Security`過濾器

在上一節咱們介紹了內置的兩個端點的實現細節，還提到了HttpSecurity過濾器，由於註銷端點的實現就是經過過濾器的做用。核心的過濾器主要有：

FilterSecurityInterceptor
UsernamePasswordAuthenticationFilter
SecurityContextPersistenceFilter
ExceptionTranslationFilter

這一節將重點介紹其中的UsernamePasswordAuthenticationFilter和FilterSecurityInterceptor。

3.1 `UsernamePasswordAuthenticationFilter`

筆者在剛開始看關於過濾器的文章，對於UsernamePasswordAuthenticationFilter有很多的文章介紹。若是隻是引入Spring-Security，必然會與/login端點熟悉。SpringSecurity強制要求咱們的表單登陸頁面必須是以POST方式向/login URL提交請求，並且要求用戶名和密碼的參數名必須是username和password。若是不符合，則不能正常工做。緣由在於，當咱們調用了HttpSecurity對象的formLogin方法時，其最終會給咱們註冊一個過濾器UsernamePasswordAuthenticationFilter。看一下該過濾器的源碼。

public class UsernamePasswordAuthenticationFilter extends AbstractAuthenticationProcessingFilter {
    //用戶名、密碼
    public static final String SPRING_SECURITY_FORM_USERNAME_KEY = "username";
    public static final String SPRING_SECURITY_FORM_PASSWORD_KEY = "password";

    private String usernameParameter = SPRING_SECURITY_FORM_USERNAME_KEY;
    private String passwordParameter = SPRING_SECURITY_FORM_PASSWORD_KEY;
    private boolean postOnly = true;

    //post請求/login
    public UsernamePasswordAuthenticationFilter() {
        super(new AntPathRequestMatcher("/login", "POST"));
    }
    //實現抽象類AbstractAuthenticationProcessingFilter的抽象方法，嘗試驗證
    public Authentication attemptAuthentication(HttpServletRequest request, HttpServletResponse response) throws AuthenticationException {
        if (postOnly && !request.getMethod().equals("POST")) {
            throw new AuthenticationServiceException(
                    "Authentication method not supported: " + request.getMethod());
        }

        String username = obtainUsername(request);
        String password = obtainPassword(request);

        //···

        username = username.trim();

        UsernamePasswordAuthenticationToken authRequest = new UsernamePasswordAuthenticationToken(
                username, password);
        //···
        return this.getAuthenticationManager().authenticate(authRequest);
    }
}複製代碼

public abstract class AbstractAuthenticationProcessingFilter extends GenericFilterBean implements ApplicationEventPublisherAware, MessageSourceAware {
    //...

    //調用requiresAuthentication，判斷請求是否須要authentication，若是須要則調用attemptAuthentication
    //有三種結果可能返回：
    //1.Authentication對象
    //2. AuthenticationException
    //3. Authentication對象爲空
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {

        HttpServletRequest request = (HttpServletRequest) req;
        HttpServletResponse response = (HttpServletResponse) res;
        //不須要校驗，繼續傳遞
        if (!requiresAuthentication(request, response)) {
            chain.doFilter(request, response);
            return;
        }
        Authentication authResult;

        try {
            authResult = attemptAuthentication(request, response);
            if (authResult == null) {
                // return immediately as subclass has indicated that it hasn't completed authentication
                return;
            }
            sessionStrategy.onAuthentication(authResult, request, response);
        }
        //...
        catch (AuthenticationException failed) {
            // Authentication failed
            unsuccessfulAuthentication(request, response, failed);

            return;
        }

        // Authentication success
        if (continueChainBeforeSuccessfulAuthentication) {
            chain.doFilter(request, response);
        }

        successfulAuthentication(request, response, chain, authResult);
    }

    //實際執行的authentication，繼承類必須實現該抽象方法
    public abstract Authentication attemptAuthentication(HttpServletRequest request, HttpServletResponse response) throws AuthenticationException, IOException, ServletException;
    //成功authentication的默認行爲
    protected void successfulAuthentication(HttpServletRequest request, HttpServletResponse response, FilterChain chain, Authentication authResult) throws IOException, ServletException {

        //...
    }
    //失敗authentication的默認行爲
    protected void unsuccessfulAuthentication(HttpServletRequest request, HttpServletResponse response, AuthenticationException failed) throws IOException, ServletException {
    //... 
    }

    ...
    //設置AuthenticationManager
    public void setAuthenticationManager(AuthenticationManager authenticationManager) {
        this.authenticationManager = authenticationManager;
    }
    ...
}複製代碼

UsernamePasswordAuthenticationFilter由於繼承了AbstractAuthenticationProcessingFilter才擁有過濾器的功能。AbstractAuthenticationProcessingFilter要求設置一個authenticationManager，authenticationManager的實現類將實際處理請求的認證。AbstractAuthenticationProcessingFilter將攔截符合過濾規則的request，並試圖執行認證。子類必須實現 attemptAuthentication 方法，這個方法執行具體的認證。
認證以後的處理和上註銷的差很少。若是認證成功，將會把返回的Authentication對象存放在SecurityContext，並調用SuccessHandler，也能夠設置指定的URL和指定自定義的處SuccessHandler。若是認證失敗，默認會返回401代碼給客戶端，也能夠設置URL，指定自定義的處理FailureHandler。

基於UsernamePasswordAuthenticationFilter自定義的AuthenticationFilte仍是挺多案例的，這邊推薦一篇博文Spring Security(五)--動手實現一個IP_Login，寫得比較詳細。

3.2 `FilterSecurityInterceptor`

FilterSecurityInterceptor是filterchain中比較複雜，也是比較核心的過濾器，主要負責web應用安全受權的工做。首先看下對於自定義的FilterSecurityInterceptor配置。

@Override
    public void configure(HttpSecurity http) throws Exception {

        ...
        //添加CustomSecurityFilter，過濾器的順序放在FilterSecurityInterceptor
        http.antMatcher("/oauth/check_token").addFilterAt(customSecurityFilter(), FilterSecurityInterceptor.class);

    }
    //提供實例化的自定義過濾器
    @Bean
    public CustomSecurityFilter customSecurityFilter() {
        return new CustomSecurityFilter();
    }複製代碼

從上述配置能夠看到，在FilterSecurityInterceptor的位置註冊了CustomSecurityFilter，對於匹配到/oauth/check_token，則會調用該進入該過濾器。下圖爲FilterSecurityInterceptor的類圖，在其中還添加了CustomSecurityFilter和相關實現的接口的類，方便讀者對比着看。

CustomSecurityFilter是模仿FilterSecurityInterceptor實現，繼承AbstractSecurityInterceptor和實現Filter接口。整個過程須要依賴AuthenticationManager、AccessDecisionManager和FilterInvocationSecurityMetadataSource。
AuthenticationManager是認證管理器，實現用戶認證的入口；AccessDecisionManager是訪問決策器，決定某個用戶具備的角色，是否有足夠的權限去訪問某個資源；FilterInvocationSecurityMetadataSource是資源源數據定義，即定義某一資源能夠被哪些角色訪問。
從上面的類圖中能夠看到自定義的CustomSecurityFilter同時又實現了
AccessDecisionManager和FilterInvocationSecurityMetadataSource。分別爲SecureResourceFilterInvocationDefinitionSource和SecurityAccessDecisionManager。下面分析下主要的配置。

//經過一個實現的filter，對HTTP資源進行安全處理
public class FilterSecurityInterceptor extends AbstractSecurityInterceptor implements Filter {
    //被filter chain真實調用的方法，經過invoke代理
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        FilterInvocation fi = new FilterInvocation(request, response, chain);
        invoke(fi);
    }
    //代理的方法
    public void invoke(FilterInvocation fi) throws IOException, ServletException {
        //...省略
    }
}複製代碼

上述代碼是FilterSecurityInterceptor中的實現，具體實現細節就沒列出了，咱們這邊重點在於對自定義的實現進行講解。

public class CustomSecurityFilter extends AbstractSecurityInterceptor implements Filter {

    @Autowired
    SecureResourceFilterInvocationDefinitionSource invocationSource;

    @Autowired
    private AuthenticationManager authenticationManager;

    @Autowired
    private SecurityAccessDecisionManager decisionManager;

    //設置父類中的屬性
    @PostConstruct
    public void init() {
        super.setAccessDecisionManager(decisionManager);
        super.setAuthenticationManager(authenticationManager);
    }
    //主要的過濾方法，與原來的一致
    @Override
    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
        //logger.info("doFilter in Security ");
        //構造一個FilterInvocation，封裝request, response, chain
        FilterInvocation fi = new FilterInvocation(servletRequest, servletResponse, filterChain);
        //beforeInvocation會調用SecureResourceDataSource中的邏輯，相似於aop中的before 
        InterceptorStatusToken token = super.beforeInvocation(fi);
        try {
            //執行下一個攔截器
            fi.getChain().doFilter(fi.getRequest(), fi.getResponse());            
        } finally {
            //完成後續工做，相似於aop中的after 
            super.afterInvocation(token, null);
        }
    }

    //...

    //資源源數據定義，設置爲自定義的SecureResourceFilterInvocationDefinitionSource
    @Override
    public SecurityMetadataSource obtainSecurityMetadataSource() {
        return invocationSource;
    }
}複製代碼

上面自定義的CustomSecurityFilter，與咱們以前的講解是同樣的流程。主要依賴的三個接口都有在實現中實例化注入。看下父類的beforeInvocation方法，其中省略了一些不重要的代碼片斷。

protected InterceptorStatusToken beforeInvocation(Object object) {  
    //根據SecurityMetadataSource獲取配置的權限屬性 
    Collection<ConfigAttribute> attributes = this.obtainSecurityMetadataSource().getAttributes(object);  
    //... 
    //判斷是否須要對認證明體從新認證，默認爲否 
    Authentication authenticated = authenticateIfRequired();  

    // Attempt authorization 
    try {  
        //決策管理器開始決定是否受權，若是受權失敗，直接拋出AccessDeniedException 
        this.accessDecisionManager.decide(authenticated, object, attributes);  
    }  
    catch (AccessDeniedException accessDeniedException) {  
        publishEvent(new AuthorizationFailureEvent(object, attributes, authenticated,  
                accessDeniedException));  

        throw accessDeniedException;  
    }  
}複製代碼

上面代碼能夠看出，第一步是根據SecurityMetadataSource獲取配置的權限屬性，accessDecisionManager會用到權限列表信息。而後判斷是否須要對認證明體從新認證，默認爲否。第二步是接着決策管理器開始決定是否受權，若是受權失敗，直接拋出AccessDeniedException。

(1). 獲取配置的權限屬性

public class SecureResourceFilterInvocationDefinitionSource implements FilterInvocationSecurityMetadataSource, InitializingBean {
    private PathMatcher matcher;
    //map保存配置的URL對應的權限集
    private static Map<String, Collection<ConfigAttribute>> map = new HashMap<>();

    //根據傳入的對象URL進行循環
    @Override
    public Collection<ConfigAttribute> getAttributes(Object o) throws IllegalArgumentException {
        logger.info("getAttributes");
        //應該作instanceof
        FilterInvocation filterInvocation = (FilterInvocation) o;
        //String method = filterInvocation.getHttpRequest().getMethod();
        String requestURI = filterInvocation.getRequestUrl();
        //循環資源路徑，當訪問的Url和資源路徑url匹配時，返回該Url所須要的權限
        for (Iterator<Map.Entry<String, Collection<ConfigAttribute>>> iterator = map.entrySet().iterator(); iter.hasNext(); ) {
            Map.Entry<String, Collection<ConfigAttribute>> entry = iterator.next();
            String url = entry.getKey();

            if (matcher.match(url, requestURI)) {
                return map.get(requestURI);
            }
        }
        return null;
    }

    //... 

    //設置權限集，即上述的map
    @Override
    public void afterPropertiesSet() throws Exception {
        logger.info("afterPropertiesSet");
        //用來匹配訪問資源路徑
        this.matcher = new AntPathMatcher();
        //能夠有多個權限
        Collection<ConfigAttribute> atts = new ArrayList<>();
        ConfigAttribute c1 = new SecurityConfig("ROLE_ADMIN");
        atts.add(c1);
        map.put("/oauth/check_token", atts);
    }
}複製代碼

上面是getAttributes()實現的具體細節，將請求的URL取出進行匹配事先設定的受限資源，最後返回須要的權限、角色。系統在啓動的時候就會讀取到配置的map集合，對於攔截到請求進行匹配。代碼中註釋比較詳細，這邊很少說。

(2). 決策管理器

public class SecurityAccessDecisionManager implements AccessDecisionManager {
    //...

    @Override
    public void decide(Authentication authentication, Object o, Collection<ConfigAttribute> collection) throws AccessDeniedException, InsufficientAuthenticationException {
        logger.info("decide url and permission");
        //集合爲空
        if (collection == null) {
            return;
        }

        Iterator<ConfigAttribute> ite = collection.iterator();
        //判斷用戶所擁有的權限，是否符合對應的Url權限，若是實現了UserDetailsService，則用戶權限是loadUserByUsername返回用戶所對應的權限
        while (ite.hasNext()) {
            ConfigAttribute ca = ite.next();
            String needRole = ca.getAttribute();
            for (GrantedAuthority ga : authentication.getAuthorities()) {
                logger.info("GrantedAuthority: {}", ga);
                if (needRole.equals(ga.getAuthority())) {
                    return;
                }
            }
        }
        logger.error("AccessDecisionManager: no right!");
        throw new AccessDeniedException("no right!");
    }

    //...
}複製代碼

上面的代碼是決策管理器的實現，其邏輯也比較簡單，將請求所具備的權限與設定的受限資源所需的進行匹配，若是具備則返回，不然拋出沒有正確的權限異常。默認提供的決策管理器有三種，分別爲AffirmativeBased、ConsensusBased、UnanimousBased，篇幅有限，咱們這邊再也不擴展了。

補充一下，所具備的權限是經過以前配置的認證方式，有password認證和client認證兩種。咱們以前在受權服務器中配置了withClientDetails，因此用frontend身份驗證得到的權限是咱們預先配置在數據庫中的authorities。

4. 總結

Auth系統主要功能是受權認證和鑑權。項目微服務化後，原有的單體應用基於HttpSession認證鑑權不能知足微服務架構下的需求。每一個微服務都須要對訪問進行鑑權，每一個微應用都須要明確當前訪問用戶以及其權限，尤爲當有多個客戶端，包括web端、移動端等等，單體應用架構下的鑑權方式就不是特別合適了。權限服務做爲基礎的公共服務，也須要微服務化。

筆者的設計中，Auth服務一方面進行受權認證，另外一方面是基於token進行身份合法性和API級別的權限校驗。對於某個服務的請求，通過網關會調用Auth服務，對token合法性進行驗證。同時筆者根據當前項目的總體狀況，存在部分遺留服務，這些遺留服務又沒有足夠的時間和人力立馬進行微服務改造，並且還須要繼續運行。爲了適配當前新的架構，採起的方案就是對這些遺留服務的操做API，在Auth服務進行API級別的操做權限鑑定。API級別的操做權限校驗須要的上下文信息須要結合業務，與客戶端進行商定，應該在token能取到相應信息，傳遞給Auth服務，不過應儘可能減小在header取上下文校驗的信息。

筆者將本次開發Auth系統所涉及的大部分代碼及源碼進行了解析，至於沒有講到的一些內容和細節，讀者能夠自行擴展。

5. 不足與後續工做

5.1 存在的不足

API級別操做權限校驗的通用性

(1). 對於API級別操做權限校驗，須要在網關處調用時構造相應的上下文信息。上下文信息基本依賴於 token中的payload，若是信息太多引發token太長，致使每次客戶端的請求頭部長度變長。

(2). 並非全部的操做接口都能覆蓋到，這個問題是比較嚴重的，根據上下文集合極可能出現好多接口的權限無法鑑定，最後的結果就是API級別操做權限校驗失敗的是絕對沒有權限訪問該接口，而經過不必定能訪問，由於該接口涉及到的上下文根本無法徹底獲得。咱們的項目在現階段，定義的最小上下文集合能勉強覆蓋到，可是對於後面擴增的服務接口真的是不樂觀。

(3). 每一個服務的每一個接口都在Auth服務註冊其所須要的權限，太過麻煩，Auth服務須要額外維護這樣的信息。
網關處調用Auth服務帶來的系統吞吐量瓶頸

(1). 這個其實很容易理解，Auth服務做爲公共的基礎服務，大多數服務接口都會須要鑑權，Auth服務須要通過複雜。

(2). 網關調用Auth服務，阻塞調用，只有等Auth服務返回校驗結果，纔會作進一步處理。雖然說Auth服務能夠多實例部署，可是併發量大了以後，其瓶頸明顯可見，嚴重可能會形成整個系統的不可用。

5.2 後續工做

從整個系統設計角度來說，API級別操做權限後期將會分散在各個服務的接口上，由各個接口負責其所須要的權限、身份等。Spring Security對於接口級別的權限校驗也是支持的，之因此採用這樣的作法，也是爲了兼容新服務和遺留的服務，主要是針對遺留服務，新的服務採用的是分散在各個接口之上。
將API級別操做權限分散到各個服務接口以後，相應的能提高Auth服務的響應。網關可以及時的對請求進行轉發或者拒絕。
API級別操做權限所須要的上下文信息對各個接口真的設計的很複雜，這邊咱們確實花了時間，同時管理移動服務的好幾百操做接口所對應的權限，很是煩。！

本文的源碼地址：
GitHub：github.com/keets2012/A…
碼雲： gitee.com/keets/Auth-…

認證鑑權與API權限控制在微服務架構中的設計與實現（四）

1. 前文回顧

2. 其餘端點

2.1 註銷端點

2.2 刷新端點

3. `Spring Security`過濾器

3.1 `UsernamePasswordAuthenticationFilter`

3.2 `FilterSecurityInterceptor`

4. 總結

5. 不足與後續工做

5.1 存在的不足

5.2 後續工做

訂閱最新文章，歡迎關注個人公衆號

參考

相關閱讀

認證鑑權與API權限控制在微服務架構中的設計與實現（四）

1. 前文回顧

2. 其餘端點

2.1 註銷端點

2.2 刷新端點

3. Spring Security過濾器

3.1 UsernamePasswordAuthenticationFilter

3.2 FilterSecurityInterceptor

4. 總結

5. 不足與後續工做

5.1 存在的不足

5.2 後續工做

訂閱最新文章，歡迎關注個人公衆號

參考

相關閱讀

3. `Spring Security`過濾器

3.1 `UsernamePasswordAuthenticationFilter`

3.2 `FilterSecurityInterceptor`