一、背景

隨著業(yè)務(wù)的發(fā)展，越來越多的系統(tǒng)需要數(shù)據(jù)往來。那對(duì)外提供的接口也越來越多，而且各個(gè)接口散落在不同的項(xiàng)目中被調(diào)用，多了的話排查問題困難且混亂?；谶@個(gè)痛點(diǎn)，我們有必要打造一套開放平臺(tái)來管理各個(gè) api 的調(diào)用情況。

二、開放平臺(tái)設(shè)計(jì)

我們先從整體的功能需求來分析，主要有以下幾點(diǎn)：

• 開發(fā)者身份注冊(cè)與數(shù)據(jù)權(quán)限范圍授權(quán)

• 開發(fā)者獲取相關(guān)資料（接口文檔、使用說明、對(duì)接人聯(lián)系方式等）

• 平臺(tái)方接入管理，申請(qǐng)審核流程、服務(wù)配置、服務(wù)管理、參數(shù)配置等

• 平臺(tái)方運(yùn)營(yíng)管理，業(yè)務(wù)交易管理及統(tǒng)計(jì)報(bào)表分析

• 安全層面需求，加密、應(yīng)用秘鑰、應(yīng)用接口權(quán)限控制、訪問黑白名單、字段脫敏還原等

• 性能方面要求，客戶端緩存、服務(wù)端緩存、緩存等

上面的設(shè)計(jì)方案更多的是針對(duì)比較大型的公司，想要把整個(gè)開平的能力建設(shè)完善。但市場(chǎng)上更多的是中小型公司，它們沒有太多的人力去開發(fā)與建設(shè)這么全面的開放平臺(tái)。

那如果是中小型公司，那它們的開放平臺(tái)如何不費(fèi)很大精力去實(shí)現(xiàn)呢？不管中小型還是大型公司的開放平臺(tái)，上面說的那個(gè)圖中其它部分可以省略，但安全機(jī)制是必需的，也就是架構(gòu)圖中的統(tǒng)一鑒權(quán)。試想一下，作為提供給第三方調(diào)用接口的開放平臺(tái)，如果安全機(jī)制不能保障，那外部誰都可以來調(diào)用你們公司的內(nèi)部資源，危害可想而知。

老周下面就來針對(duì)不同的業(yè)務(wù)場(chǎng)景來給出相應(yīng)的開放平臺(tái)安全機(jī)制的保障，也就是根據(jù)不同類型的網(wǎng)站給出相對(duì)應(yīng)的開放平臺(tái)設(shè)計(jì)方案。

三、小型網(wǎng)站

3.1 基于 session 的登錄認(rèn)證

在傳統(tǒng)的用戶登錄認(rèn)證中，因?yàn)?http 是無狀態(tài)的，所以都是采用 session 方式。用戶登錄成功，服務(wù)端會(huì)保存一個(gè) session，當(dāng)然會(huì)給客戶端一個(gè) sessionId，客戶端會(huì)把 sessionId 保存在 cookie 中，每次請(qǐng)求都會(huì)攜帶這個(gè) sessionId。服務(wù)器收到 sessionId，找到前期保存的數(shù)據(jù)，由此得知用戶的身份。

四、中型網(wǎng)站

隨著用戶量的增多，上面基于 cookie + session 的這種模式缺點(diǎn)就顯現(xiàn)出來了，這種模式通常是保存在內(nèi)存中，而且服務(wù)從單服務(wù)到多服務(wù)會(huì)面臨 session 共享問題，開銷也隨即越來越大。

那中型網(wǎng)站的安全認(rèn)證機(jī)制是啥呢？接下來 JWT（JSON Web Token） 即將登場(chǎng)，關(guān)于 JWT 的概念與原理，老周這里覺得還是有必要說一下。

4.1 JWT 的概念

4.1.1 什么是 JWT?

JWT 是一個(gè)開放的行業(yè)標(biāo)準(zhǔn)（RFC 7519），它定義了一種簡(jiǎn)潔的、自包含的協(xié)議格式，用于在通信雙方傳遞 json 對(duì)象，傳遞的信息經(jīng)過數(shù)字簽名可以被驗(yàn)證和信任。JWT 可以使用 HMAC 算法或使用 RSA的公鑰/私鑰對(duì)來簽名，防止被篡改。

說白了 JWT 就是一套基于 token 的身份認(rèn)證的方案，可以保證安全傳輸?shù)那疤嵯聜魉鸵恍┗镜男畔?，以減輕對(duì)外部存儲(chǔ)的依賴，減少了分布式組件的依賴，減少了硬件的資源。

可實(shí)現(xiàn)無狀態(tài)、分布式的 Web 應(yīng)用授權(quán)，JWT 的安全特性保證了 token 的不可偽造和不可篡改。

本質(zhì)上是一個(gè)獨(dú)立的身份驗(yàn)證令牌，可以包含用戶標(biāo)識(shí)、用戶角色和權(quán)限等信息，以及您可以存儲(chǔ)任何其他信息（自包含）。任何人都可以輕松讀取和解析，并使用密鑰來驗(yàn)證真實(shí)性。

4.1.2 JWT 令牌結(jié)構(gòu)

JWT 令牌由三部分組成，每部分中間使用點(diǎn)(.)分隔，比如：xxxxx.yyyyy.zzzzz

• Header
  頭部包括令牌的類型(即JWT)及使用的哈希算法(如HMAC SHA256或RSA)，例如：

  {
      "alg": "HS256", 
      "typ": "JWT"
  }
  

  將上邊的內(nèi)容使用 Base64Url 編碼，得到一個(gè)字符串就是 JWT 令牌的第一部分。

• Payload
  第二部分是負(fù)載，內(nèi)容也是一個(gè) json 對(duì)象，它是存放有效信息的地方，它可以存放 jwt 提供的現(xiàn)成字段，比如：iss(簽發(fā)者)，exp(過期時(shí)間戳)，sub(面向的用戶)等，也可自定義字段。此部分不建議存放敏感信息，因?yàn)榇瞬糠挚梢越獯a還原原始內(nèi)容。最后將第二部分負(fù)載使用 Base64Url 編碼，得到一個(gè)字符串就是 JWT 令牌的第二部分。一個(gè)例子:

  {
      "sub": "1234567890", 
      "name": "微信公眾號(hào)【老周料架構(gòu)】", 
      "iat": 1516239022
  }
  

• Signature
  第三部分是簽名，此部分用于防止 jwt 內(nèi)容被篡改。這個(gè)部分使用 base64url 將前兩部分進(jìn)行編碼，編碼后使用點(diǎn)(.)連接組成字符串，最后使用 header 中聲明簽名算法進(jìn)行簽名。
  secret：簽名所使用的密鑰。

  HMACSHA256 ( 
      base64UrlEncode(header) + "." + base64UrlEncode(payload), secret
  )
  

  驗(yàn)簽過程描述：獲取 token 值，讀取 Header 部分并 Base64 解碼，得到簽名算法。根據(jù)以上方法算出簽名，如果簽名信息不一致，說明是非法的。

4.2 JWT 的流程

如果你們公司有第三方應(yīng)用接入的開放平臺(tái)，那可以在里面走相應(yīng)的接入流程得到 appId 和 appSecret。如果沒有的話，那可以簡(jiǎn)單點(diǎn)與第三方約定相應(yīng)的 appId 和 appSecret。老周這里假設(shè)你們已經(jīng)約定好了，我這里直接放在請(qǐng)求頭里來獲取 token，還有其它的方式，比如放在請(qǐng)求參數(shù)或者 cookie 里。

4.3.1 maven 依賴

<dependency>
    <groupId>com.auth0</groupId>
    <artifactId>java-jwt</artifactId>
    <version>3.4.1</version>
</dependency>

4.3.2 JWTUtil 工具類

public class JWTUtil {
    private static String SECRETE = "default_secrete";
    private static String APP_ID = "zhifubao";
    private static String APP_SECRETE = "123abc";

    /**
     * 傳入 appId、appSecret 進(jìn)行驗(yàn)證
     * @param appId 應(yīng)用id
     * @param appSecret 應(yīng)用密鑰
     * @return 返回一個(gè)加密 JWT token
     */
    public static String getToken(String appId, String appSecret) {
        String token = JWT.create()
                // 存放 payload 數(shù)據(jù)
                .withClaim("appId", appId)
                .withClaim("appSecret", appSecret)
                // 使用 SECRETE 對(duì)稱加密生成 signature
                .sign(Algorithm.HMAC256(SECRETE));
        return token;
    }

    /**
     * 驗(yàn)證 token
     * @param token
     * @return
     */
    public static boolean verifyToken(String token) {
        HashMap<String, String> map = new HashMap<>();
        // 通過 SECRETE 和相同的對(duì)稱加密算法反加密
        DecodedJWT jwt = JWT.require(Algorithm.HMAC256(SECRETE))
                .build().verify(token);
        // 獲得你儲(chǔ)存的 payload 信息
        String appId = jwt.getClaim("appId").asString();
        String appSecret = jwt.getClaim("appSecret").asString();
        if (APP_ID.equals(appId) && APP_SECRETE.equals(appSecret)) {
            return true;
        }
        return false;
    }
}

4.3.3 JWTController 類

@RestController
public class JWTController {
    @RequestMapping("/getToken")
    public String getToken(@RequestHeader("appId") String appId, @RequestHeader("appSecret") String appSecret) {
        return JWTUtil.getToken(appId, appSecret);
    }
}

4.3.4 測(cè)試

拓展：這個(gè)私鑰 secrete 是固定的，為了加強(qiáng)安全，你甚至可以使用動(dòng)態(tài)的 secrete 私鑰，
例如：動(dòng)態(tài)私鑰 = 靜態(tài)私鑰 + 用戶的 ip，這樣即使別人得到了用戶的 token，也會(huì)因?yàn)?ip 不一致而訪問失敗。

拿到了應(yīng)用資源服務(wù)器的 token 令牌了，那我們拿這個(gè)令牌去訪問相應(yīng)的資源看看。

@RequestMapping("/getResource")
public String getResource(String resourceId) {
    return resourceId + " 資源獲取成功";
}

簡(jiǎn)單模擬一個(gè)請(qǐng)求，直接返回該資源獲取成功。我們接下來就用 postman 工具來模擬一下這個(gè)資源服務(wù)器的這個(gè)接口請(qǐng)求。

這里你有可能問了，老周，這里咋就帶上 token 在請(qǐng)求頭就可以獲取到了資源服務(wù)器的資源啊。

我把代碼貼出來，你一看就知道了。

這里寫了一個(gè) token 的攔截器，對(duì)請(qǐng)求頭的 token 進(jìn)行驗(yàn)簽，通過才放行。

@Component
public class TokenInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        String token = request.getHeader("token");
        if (token != null) {
            boolean result = JWTUtil.verifyToken(token);
            if (result) {
                System.out.println("通過攔截器");
                return true;
            }
        }

        response.setCharacterEncoding("UTF-8");
        response.setContentType("application/json; charset=utf-8");
        try{
            response.getWriter().append("認(rèn)證失敗，無效的token令牌！");
            System.out.println("認(rèn)證失敗，無效的token令牌！");
        } catch (Exception e) {
            e.printStackTrace();
            response.sendError(500);
            return false;
        }
        return false;
    }
}

這里有個(gè)攔截器配置類，把需要攔截的 api 路徑放進(jìn)來，然后會(huì)對(duì)某個(gè) api 進(jìn)行細(xì)粒度的管控。

@Configuration
public class IntercepterConfig implements WebMvcConfigurer {
    private TokenInterceptor tokenInterceptor;

    public IntercepterConfig(TokenInterceptor tokenInterceptor){
        this.tokenInterceptor = tokenInterceptor;
    }

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        List<String> excludePath = new ArrayList<>();
        excludePath.add("/getResource/");
        excludePath.add("/static/**");  //靜態(tài)資源
        registry.addInterceptor(tokenInterceptor)
                .addPathPatterns("/**")
                .excludePathPatterns(excludePath);
        WebMvcConfigurer.super.addInterceptors(registry);
    }
}

這就實(shí)現(xiàn)中型網(wǎng)站安全認(rèn)證機(jī)制了，細(xì)心的讀者可能會(huì)發(fā)現(xiàn)，這個(gè) token 是固定的，會(huì)存在一些不安全。是的，我上面也說了，可以用動(dòng)態(tài)的 secrete 私鑰或者 token 過期機(jī)制來繼續(xù)保證更高的安全性。

五、大型網(wǎng)站

大型網(wǎng)站的話，針對(duì)中型網(wǎng)站的方案就不太可行了，為什么呢？由于大型網(wǎng)站的請(qǐng)求流量很大，而 token 由于自包含信息，因此一般數(shù)據(jù)量較大，而且每次請(qǐng)求都需要傳遞，因此比較占帶寬。另外，token 的簽名驗(yàn)簽操作也會(huì)給 cpu 帶來額外的處理負(fù)擔(dān)。可以采用微服務(wù)統(tǒng)一認(rèn)證方案 Spring Cloud OAuth2，那什么情況下需要使用 OAuth2?

• 第三方授權(quán)登錄的場(chǎng)景：比如，我們經(jīng)常登錄一些網(wǎng)站或者應(yīng)用的時(shí)候，可以選擇使用第三方授權(quán)登錄的方式，比如：微信授權(quán)登錄、QQ授權(quán)登錄、微博授權(quán)登錄等，這是典型的 OAuth2 使用場(chǎng)景。

• 單點(diǎn)登錄的場(chǎng)景：如果項(xiàng)目中有很多微服務(wù)或者公司內(nèi)部有很多服務(wù)，可以專?做一個(gè)認(rèn)證中心(充當(dāng)認(rèn)證平臺(tái)?色)，所有的服務(wù)都要到這個(gè)認(rèn)證中心做認(rèn)證，只做一次登錄，就可以在多個(gè)授權(quán)范圍內(nèi)的服務(wù)中自由串行。

5.1 OAuth2 構(gòu)建微服務(wù)統(tǒng)一認(rèn)證服務(wù)思路

5.1.1 搭建認(rèn)證服務(wù)器(Authorization Server)

5.1.1.1 maven 依賴文件

5.1.1.6.1 獲取 token

http://localhost:9999/oauth/token?client_secret=abcxyz&grant_type=password&username=admin&password=123456&client_id=client_riemann

endpoint：/oauth/token

獲取token攜帶的參數(shù)
client_id:客戶端id
client_secret:客戶單密碼
grant_type:指定使用哪種頒發(fā)類型，password
username:用戶名
password:密碼

http://localhost:9999/oauth/check_token?token=28317df7-4036-4bbb-8bb3-12f71fa07802

下面才是 token 校驗(yàn)成功的效果：

http://localhost:9999/oauth/token?grant_type=refresh_token&client_id=client_riemann&client_secret=abcxyz&refresh_token=68582d02-3a1d-4c31-ae22-ac7e84824d0d

5.1.2.1 資源服務(wù) Resource Server 配置類

• 當(dāng)我們第一次登陸之后，認(rèn)證服務(wù)器頒發(fā) token 并將其存儲(chǔ)在認(rèn)證服務(wù)器中，后期我們 訪問資源服務(wù)器時(shí)會(huì)攜帶 token，資源服務(wù)器會(huì)請(qǐng)求認(rèn)證服務(wù)器驗(yàn)證 token 有效性，如果資源服務(wù)器有很多，那么認(rèn)證服務(wù)器壓力會(huì)很大。

• 另外，資源服務(wù)器向認(rèn)證服務(wù)器 check_token，獲取的也是用戶信息 UserInfo，能否把用戶信息存儲(chǔ)到令牌中，讓客戶端一直持有這個(gè)令牌，令牌的驗(yàn)證也在資源服務(wù)器進(jìn)行，這樣避免和認(rèn)證服務(wù)器頻繁的交互。

• 我們可以考慮使用 JWT 進(jìn)行改造，使用 JWT 機(jī)制之后資源服務(wù)器不需要訪問認(rèn)證服務(wù)器。

5.3 JWT 改造統(tǒng)一認(rèn)證授權(quán)中心的令牌存儲(chǔ)機(jī)制

JWT 在上面中型網(wǎng)站那一節(jié)說過了，這里就不重復(fù)說了，老周直接上代碼了。

5.3.1 認(rèn)證服務(wù)器端 JWT 改造(改造主配置類)

5.3.2 修改 JWT 令牌服務(wù)方法

我們用這個(gè)網(wǎng)站：https://jwt.io/#encoded-jwt 把該 access_token 進(jìn)行解碼，解碼如下：

5.3.4 資源服務(wù)器校驗(yàn) JWT 令牌

不需要和遠(yuǎn)程認(rèn)證服務(wù)器交互，添加本地 tokenStore。

六、總結(jié)

老周首先從開放平臺(tái)的整體功能設(shè)計(jì)來分析了有如下幾個(gè)要點(diǎn)：開發(fā)者認(rèn)證、開放平臺(tái)內(nèi)部管理系統(tǒng)、安全機(jī)制以及性能。

但考慮很多公司它們沒有太多的人力去開發(fā)與建設(shè)這么全面的開放平臺(tái)，故抓住其中的最核心的一點(diǎn)，那就是安全機(jī)制。

針對(duì)于安全機(jī)制來說，不同類型的網(wǎng)站有不同的安全機(jī)制保障。

• 小型網(wǎng)站：基于 session 的登錄認(rèn)證，在小型網(wǎng)站特別是單機(jī)系統(tǒng)，這種方案夠用了，而且簡(jiǎn)單高效；

• 中型網(wǎng)站：到了中型網(wǎng)站，服務(wù)肯定是分布式部署的，這個(gè)時(shí)候小型網(wǎng)站中基于 session 的登錄認(rèn)證方案的缺點(diǎn)就暴露出來了。每個(gè)應(yīng)用服務(wù)都需要在 session 中存儲(chǔ)用戶身份信息，通過負(fù)載均衡將本地的請(qǐng)求分配到另一個(gè)應(yīng)用服務(wù)需要將 session 信息帶過去，否則會(huì)重新認(rèn)證。我們還要通過 session 共享、session 黏貼等方案來解決。從而引入了第三方分布式組件，比如 redis，增加了系統(tǒng)的復(fù)雜性。并且 session 方案還有另一個(gè)缺點(diǎn)，比如基于 cookie，移動(dòng)端不能有效使用等。所以中型網(wǎng)站的話基于 JWT 的 token 認(rèn)證機(jī)制，服務(wù)端不用存儲(chǔ)認(rèn)證數(shù)據(jù)，易維護(hù)擴(kuò)展性強(qiáng)，客戶端可以把 token 存在任意地方，并且可以實(shí)現(xiàn) web 和 app 統(tǒng)一認(rèn)證機(jī)制。

• 大型網(wǎng)站：到了大型網(wǎng)站，請(qǐng)求量也隨之暴漲，中型網(wǎng)站的 token 認(rèn)證機(jī)制的缺點(diǎn)也逐步暴露出來了，token 由于自包含信息，因此 一般數(shù)據(jù)量較大，而且每次請(qǐng)求都需要傳遞，因此比較占帶寬。另外，token 的簽名驗(yàn)簽操作也會(huì)給 cpu 帶來額外的處理負(fù)擔(dān)。這個(gè)時(shí)候得采用微服務(wù)統(tǒng)一認(rèn)證方案 Spring Cloud OAuth2，后面我們又對(duì) OAuth2 進(jìn)行了一些優(yōu)化，因?yàn)榇笮途W(wǎng)站的開平請(qǐng)求流量會(huì)很大，資源服務(wù)器會(huì)請(qǐng)求認(rèn)證服務(wù)器驗(yàn)證 token 有效性，那么認(rèn)證服務(wù)器壓力會(huì)很大。另外，資源服務(wù)器向認(rèn)證服務(wù)器 check_token，獲取的也是用戶信息 UserInfo，能否把用戶信息存儲(chǔ)到令牌中，讓客戶端一直持有這個(gè)令牌，令牌的驗(yàn)證也在資源服務(wù)器進(jìn)行，這樣避免和認(rèn)證服務(wù)器頻繁的交互。所以我們后續(xù)使用 JWT 進(jìn)行改造，使用 JWT 機(jī)制之后資源服務(wù)器不需要訪問認(rèn)證服務(wù)器。性能以及安全機(jī)制都得到了有力保障。

歡迎大家關(guān)注我的公眾號(hào)【老周聊架構(gòu)】，Java后端主流技術(shù)棧的原理、源碼分析、架構(gòu)以及各種互聯(lián)網(wǎng)高并發(fā)、高性能、高可用的解決方案。