- 概述
公司、個(gè)人開發(fā)的系統(tǒng)上線后，系統(tǒng)中 API 暴露到網(wǎng)絡(luò)上會(huì)存在一定的安全風(fēng)險(xiǎn)，比如：爬蟲、惡意訪問、錯(cuò)誤訪問等。API沒有安全性，用戶可以任意注冊即可無限次訪問和調(diào)用API，且沒有請(qǐng)求與特定用戶數(shù)據(jù)關(guān)聯(lián)的簡單方法，就無法防止惡意用戶的惡意請(qǐng)求等。
常用 API 接口安全措施如下幾種：
（1）數(shù)據(jù)加密
數(shù)據(jù)在互聯(lián)網(wǎng)傳輸過程很容易被抓包，如果直接傳輸，那么用戶數(shù)據(jù)可能被其他人獲取，導(dǎo)致系統(tǒng)安全性等問題，所以必須對(duì)數(shù)據(jù)加密。常見的做法是對(duì)關(guān)鍵字段加密，比如用戶密碼直接通過 md5 加密。
（2）數(shù)據(jù)簽名
數(shù)據(jù)在傳輸過程中經(jīng)過加密，理論上就算被抓包，也無法對(duì)數(shù)據(jù)進(jìn)行篡改，但是我們一般加密的部分其實(shí)只是在外網(wǎng)，現(xiàn)在很多服務(wù)在內(nèi)網(wǎng)中都需要經(jīng)過很多服務(wù)跳轉(zhuǎn)，如果被攻入內(nèi)網(wǎng)，則可以在任意節(jié)點(diǎn)篡改數(shù)據(jù)，所以這里的加數(shù)據(jù)簽名可以防止內(nèi)網(wǎng)中數(shù)據(jù)被篡改。數(shù)據(jù)簽名就是由發(fā)送者產(chǎn)生一段無法偽造的一段數(shù)字串，來保證數(shù)據(jù)在傳輸過程中不被篡改。md5算法是常用的數(shù)據(jù)簽名算法，其原理是將需要提交的數(shù)據(jù)通過某種方式組合成一個(gè)字符串，然后通過md5算法生成一段加密字符串，這段加密字符串就是數(shù)據(jù)包的簽名。為保證安全性，最后的密鑰會(huì)在客戶端和服務(wù)端各備一份。
（3）添加時(shí)間戳
經(jīng)過如上的加密，加簽處理，就算拿到數(shù)據(jù)也不能看到真實(shí)的數(shù)據(jù)；但是有些攻擊者不關(guān)心真實(shí)的數(shù)據(jù)，而是直接拿到抓取的數(shù)據(jù)包做惡意請(qǐng)求，以達(dá)到攻擊的目的。我們可以使用時(shí)間戳機(jī)制，在每次請(qǐng)求的時(shí)候加入當(dāng)前的時(shí)間，服務(wù)器端會(huì)拿到當(dāng)前時(shí)間和消息中的時(shí)間相減，看看是否在一個(gè)固定的時(shí)間范圍內(nèi)，超過時(shí)間差的請(qǐng)求就視為非法請(qǐng)求。
（4）限流機(jī)制
如果有用戶出現(xiàn)頻繁調(diào)用接口的情況；這種情況需要給相關(guān)用戶做限流處理，常用的限流算法包括：令牌桶限流，漏桶限流，計(jì)數(shù)器限流。令牌桶限流：系統(tǒng)以一定速率向桶中放入令牌，填滿了就丟棄令牌；請(qǐng)求來時(shí)會(huì)先從桶中取出令牌，如果能取到令牌，則可以繼續(xù)完成請(qǐng)求，否則等待或者拒絕服務(wù)。令牌桶允許一定程度突發(fā)流量，只要有令牌就可以處理，支持一次拿多個(gè)令牌。漏桶限流：按照固定常量速率流出請(qǐng)求，流入請(qǐng)求速率任意，當(dāng)請(qǐng)求數(shù)超過桶的容量時(shí)，新的請(qǐng)求等待或者拒絕服務(wù)，因此漏桶算法可以強(qiáng)制限制數(shù)據(jù)的傳輸速度。計(jì)數(shù)器限流：這是一種比較簡單粗暴的算法，主要用來限制總并發(fā)數(shù)，比如數(shù)據(jù)庫連接池、線程池、秒殺的并發(fā)數(shù)；計(jì)數(shù)器限流只要一定時(shí)間內(nèi)的總請(qǐng)求數(shù)超過設(shè)定的閥值則進(jìn)行限流。
（5）黑名單限流
如果此用戶進(jìn)行過很多非法操作，或者說專門有一個(gè)中黑系統(tǒng)，經(jīng)過分析之后直接將此用戶列入黑名單，所有請(qǐng)求直接返回錯(cuò)誤碼。我們可以給每個(gè)用戶設(shè)置一個(gè)狀態(tài)比如包括：初始化狀態(tài)，正常狀態(tài)，中黑狀態(tài)，關(guān)閉狀態(tài)等等；或者我們直接通過分布式配置中心，直接保存黑名單列表，每次檢查是否在列表中即可。
常用的安全防范有以下方式：API Keys、Basic Auth、Hmac、OAuth。本文主要討論基于OAuth協(xié)議的API安全驗(yàn)證。本文主要介紹基于OAuth協(xié)議（Client Credentials）的實(shí)踐。
- 系統(tǒng)架構(gòu)
下圖是一個(gè)筆者親身經(jīng)歷的一個(gè)例子，到目前為止，運(yùn)轉(zhuǎn)良好。API服務(wù)服務(wù)網(wǎng)關(guān)采用基于Kong API網(wǎng)關(guān)的實(shí)現(xiàn)，認(rèn)證中心是實(shí)現(xiàn)OAuth 2.0協(xié)議的權(quán)限認(rèn)證系統(tǒng)，服務(wù)提供系統(tǒng)設(shè)置基于IP的白名單訪問。
OAuth 2.0是一種用戶驗(yàn)證和授權(quán)用戶的流行方法，此方法依賴于身份驗(yàn)證服務(wù)器和API服務(wù)器進(jìn)行通信以授予訪問權(quán)限，在筆者的前面的文章中已經(jīng)詳細(xì)闡述OAuth的原理，在這里就不在贅述，想看的讀者可以翻看歷史記錄找到該篇文章。下圖標(biāo)注了詳細(xì)的流程。
- JWT令牌的理論
JWT（全稱：Json Web Token）是一個(gè)開放標(biāo)準(zhǔn)（RFC 7519），它定義了一種緊湊的、自包含的方式，用于作為JSON對(duì)象在各方之間安全地傳輸信息。該信息可以被驗(yàn)證和信任，因?yàn)樗菙?shù)字簽名的。如有讀者想了解詳細(xì)的JWT規(guī)范，可以訪問RFC7519的官方網(wǎng)站：https://datatracker.ietf.org/doc/html/rfc7519。
JWT由3部分組成：標(biāo)頭（Header）、有效載荷（Payload）和簽名（Signature）。在傳輸?shù)臅r(shí)候，會(huì)將JWT的3部分分別進(jìn)行Base64編碼后用。進(jìn)行連接形成最終傳輸?shù)淖址WTString=Base64(Header).Base64(Payload).HMACSHA256(base64UrlEncode(header)+"."+base64UrlEncode(payload),secret)。
下圖為一個(gè)簡單的JWT的解碼出來的例子：
以上圖為例，JWT的數(shù)據(jù)結(jié)構(gòu)一般是一個(gè)三段式的字符，以“.”隔開：xxxxx.yyyyy.zzzzz。
JWT第一部分是Header頭部分，它是一個(gè)描述JWT元數(shù)據(jù)的Json對(duì)象，通常如下所示。alg屬性表示簽名使用的算法，默認(rèn)為HMAC SHA256（寫為HS256），typ屬性表示令牌的類型，JWT令牌統(tǒng)一寫為JWT。最后，使用Base64 URL算法將上述JSON對(duì)象轉(zhuǎn)換為字符串保存。
JWT第二部分是Payload，也是一個(gè)Json對(duì)象，除了包含需要傳遞的數(shù)據(jù)，還有七個(gè)默認(rèn)的字段供選擇。分別是，iss：發(fā)行人、exp：到期時(shí)間、sub：主題、aud：用戶、nbf：在此之前不可用、iat：發(fā)布時(shí)間、jti：JWT ID用于標(biāo)識(shí)該JWT。也可以加上自定義字段。需要注意的是，默認(rèn)情況下JWT是未加密的，任何人都可以解讀其內(nèi)容，因此如果一些敏感信息不要存放在此，以防信息泄露。JSON對(duì)象也使用Base64 URL算法轉(zhuǎn)換為字符串保存。
JWT第三部分是Signature簽名。是這樣生成的，首先需要指定一個(gè)secret，該secret僅僅保存在服務(wù)器中，保證不能讓其他用戶知道。然后使用Header指定的算法對(duì)Header和Payload進(jìn)行計(jì)算，然后就得出一個(gè)簽名哈希。也就是Signature。
那么Application Server如何進(jìn)行驗(yàn)證呢？可以利用JWT前兩段，用同一套哈希算法和同一個(gè)secret計(jì)算一個(gè)簽名值，然后把計(jì)算出來的簽名值和收到的JWT第三段比較，如果相同則認(rèn)證通過。
JWT的優(yōu)點(diǎn)包括如下：JSON格式的通用性，所以JWT可以跨語言支持，比如JAVA、JavaScript、php、Node等等。可以利用Payload存儲(chǔ)一些非敏感的信息。便于傳輸，JWT結(jié)構(gòu)簡單，字節(jié)占用小。不需要在服務(wù)端保存會(huì)話信息，易于應(yīng)用的擴(kuò)展。
- Kong API網(wǎng)關(guān)的JWT令牌應(yīng)用
下圖是Kong認(rèn)證的實(shí)際過程。
如果配置中允許OPTIONS請(qǐng)求，并且請(qǐng)求的方法確實(shí)是OPTIONS，放行。
如果配置中設(shè)置了匿名消費(fèi)者，并且有憑證，放行。這里是為了實(shí)現(xiàn)多重認(rèn)證，通過配置匿名消費(fèi)者來實(shí)現(xiàn)邏輯或的認(rèn)證，此時(shí)必須有其他認(rèn)證插件，當(dāng)其他認(rèn)證插件通過，jwt插件就不再驗(yàn)證，若不設(shè)置匿名，則既要jwt驗(yàn)證也要其他認(rèn)證插件驗(yàn)證。
先后從query params，request header中查找token（根據(jù)配置的變量），token的格式為\s*[Bb]earer\s+(.+)，如果從query params找到就返回了，不會(huì)再根據(jù)request header找。
如果沒有找到token，或者token格式不對(duì)，并且不允許匿名，返回401。
如果沒有找到token，并且允許匿名，根據(jù)配置的匿名的id查詢消費(fèi)者，增加request header：X-Consumer-ID、X-Consumer-Username和X-Anonymous-Consumer=true，id是自動(dòng)生成的，username是配置時(shí)填寫的，設(shè)置這個(gè)消費(fèi)者的憑證是nil，放行。
如果找到token，且格式合法，jwt解碼這個(gè)token，驗(yàn)證token的 claim，消費(fèi)者，簽名驗(yàn)證，過期驗(yàn)證，全部通過后，同匿名一樣，增加步驟5中的request header，并且清除X-Anonymous-Consumer這個(gè)header。
以下是Kong網(wǎng)關(guān)集成OAuth插件的例子，首先啟用OAuth插件，然后在將插件添加到需要集成權(quán)限的Service上。
請(qǐng)求的時(shí)候只要在HTTP Header帶上“Content-Type:application/json”和“Authorization: Bearer 認(rèn)證中心申請(qǐng)的JWT令牌”即可訪問到所需的資源。
- Spring Cloud Gateway的JTW令牌應(yīng)用
Spring Cloud Gateway是Spring官方基于Spring 5.0、Spring Boot 2.0和Project Reactor等技術(shù)開發(fā)的網(wǎng)關(guān)，Spring Cloud Gateway旨在為微服務(wù)架構(gòu)提供一種簡單而有效的統(tǒng)一的API路由管理方式。Spring Cloud Gateway作為Spring Cloud生態(tài)系中的網(wǎng)關(guān)，目標(biāo)是替代ZUUL，其不僅提供統(tǒng)一的路由方式，并且基于Filter鏈的方式提供了網(wǎng)關(guān)基本的功能，例如：安全，監(jiān)控/埋點(diǎn)，和限流等。
使用Gateway全局過濾器獲取JWT Token后進(jìn)行用戶認(rèn)證及鑒權(quán)。下圖為實(shí)現(xiàn)該過濾器的代碼。
- JWT令牌應(yīng)用實(shí)例
1、登錄獲取token
2、將token設(shè)置到Request Header后，訪問資源服務(wù)
3、當(dāng)沒有token訪問資源服務(wù)時(shí)就會(huì)返回401
- 總結(jié)
最后講講JWT的缺點(diǎn)，任何技術(shù)都不是完美的，所以我們得用辯證思維去看待任何一項(xiàng)技術(shù)。安全性沒法保證，所以jwt里不能存儲(chǔ)敏感數(shù)據(jù)。因?yàn)閖wt的payload并沒有加密，只是用Base64編碼而已。無法中途廢棄。因?yàn)橐坏┖灠l(fā)了一個(gè)jwt，在到期之前始終都是有效的，如果用戶信息發(fā)生更新了，只能等舊的jwt過期后重新簽發(fā)新的jwt。
續(xù)簽問題。當(dāng)簽發(fā)的jwt保存在客戶端，客戶端一直在操作頁面，按道理應(yīng)該一直為客戶端續(xù)長有效時(shí)間，否則當(dāng)jwt有效期到了就會(huì)導(dǎo)致用戶需要重新登錄。那么怎么為jwt續(xù)簽?zāi)兀孔詈唵未直┚褪敲看魏灠l(fā)新的jwt，但是由于過于暴力，會(huì)影響性能。如果要優(yōu)雅一點(diǎn)，又要引入redis解決，但是這又把無狀態(tài)的jwt硬生生變成了有狀態(tài)的，違背了初衷。所以印證了那句話，沒有最好的技術(shù)，只有適合的技術(shù)。感謝大家的閱讀，希望看完之后能對(duì)你有所收獲。
本文簡單的討論API權(quán)限認(rèn)證，關(guān)于API的限流等，后續(xù)將持續(xù)分享其他內(nèi)容。碼字不易，歡迎關(guān)注、點(diǎn)贊、收藏。
