聊聊常見的服務(接口)認證受權

寫在前面

頭髮掉得多了，總有機會接觸/調到各類各樣的接口，各類面向Api編程實際上已經嵌入到咱們的習慣中，沒辦法如今服務端通訊還得是http(s)，其餘協議還未能成爲通用的。

大廠的開發平臺api我先不敢說，各類小公司、或者很多大公司內部之間，各類各樣的的接口簽名/受權方式能夠說是盡顯勞動人民智慧、八仙過海，各顯神通。固然，我也曾是八仙中一員大將；

然而，不能總當神仙，偶爾也要作下凡人。下面咱們聊聊常見的服務受權方式；

Basic Auth

Basic Auth使用base64編碼把 username:password (注意中間有個半角冒號)加密後放入請求頭：

好比帳號密碼 hei:123 ， base64後在request--header這樣:

Authorization: Basic aGVpOjEyMw==

Postman支持

總結：

優勢：簡單明瞭，特別容易理解；

缺點：由於簡單，且幾乎是明文的形式傳遞，總得來講不夠安全；且要配合權限啊、受權策略啊要花挺多成本；

看場景使用；

Key Auth

這個別看名字起得高大上，其實也就是你先定義一個 KeyName，KeyValue,調用方和接口定義方約定這個Key放在--header或者Query Params裏，到時按約定好的取出就好；

好比我定義了的

KeyName: apikey

KeyValue: hei.key.7LimLB5qXHtuBsI7HpxM9mj447ME3GlNoe7WxKL5

約定好放到Header裏。

Postman支持

總結： 跟basic auth 同樣，仍是不夠安全，雖然能夠經過添加超複雜的keyValue提升安全性。但記住，只要是固定的key，永遠都是不安全的。看場景使用。

Jwt Auth

這個知識點但是但是博客園的常客了，三天兩頭都有相關博文；但畢竟本片不是jwt專題，我就不長篇闊論了簡單聊聊；

首先jwt是啥

Json web token (JWT), 是爲了在網絡應用環境間傳遞聲明而執行的一種基於JSON的開放標準（(RFC 7519)，

傳遞信息的標準的說白了就是一種數據格式，它分紅三個部分組成，中間用.隔開：

（圖來自龍哥的博客）

//上圖三部分通常這樣組成，因此整個jwt都是base64的（除了那兩個分割的'.'）
base64Url(Header)+"."+base64Url(Payload)+"."+base64Url(Signature)

具體的一個jwt

eyJhbGciOiJSUzI1NiIsImtpZCI6IjY1OTMxODE4QjYxQkIzQTVEMUIxN0Y0MEVCRTlEQkY2IiwidHlwIjoiYXQrand0In0.eyJuYmYiOjE1OTcxNDIxNzgsImV4cCI6MTU5NzE0OTM3OCwiaXNzIjoiaHR0cDovLzE3Mi4xNi4zLjExNzo1MTAwIiwiYXVkIjpbIm9jZWxvdCIsImh0dHA6Ly8xNzIuMTYuMy4xMTc6NTEwMC9yZXNvdXJjZXMiXSwiY2xpZW50X2lkIjoib2NlbG90LmNsaWVudCIsImp0aSI6IkQxRkExNkE3MkM1RDY4RDEyMTMzM0RGRjRDRDBCM0Q4IiwiaWF0IjoxNTk3MTQyMTc4LCJzY29wZSI6WyJvY2Vsb3QuYWRtaW4iXX0.PCN_Q77r0IyaesLy-Q0lTV12EYD9GkywrDMfxrCBj3ac9YltW8RzczAqdn2f92iysf_5Iu6hvTm16z9MJay6-eGWBiuIgJRXaCDlTqWWKcI8rWmW17ncyJT5oIgwip54Tfder9AfJOUJ-K0U2zT0fsrnBf7CZDLmkAAFHoxky1dzmPnh7JM4EkjtC-ybLOu_Aav7GgIOyYfodovxNgMvGHdhmheJLjxpjGblfI6o3rH8fRedwoV8zCY8MxJRGVcqg8slo0E9wfsebNx8hCV1mLHJbuDbJ1DCnDQ_1I1pFEFZCVNE2g0R-LRMC7opfFcveorNvZcJ8zEPWcACqoGXZg

咱們 複製到https://jwt.io/ 解析看看：

能夠很清楚的看到， header部分是說明Token的類型和所使用的算法，payload部分就是受權信息，好比用戶名啊、哪一個服務器，何時發的、何時失效等等。signature部分是簽名信息，防止篡改。

通常是怎麼用jwt的

我借龍哥個圖來講明下

1. 通常咱們先定義一個頒發token服務（Auth Service --Api），服務調用方攜帶受權信息申請token;
2. Auth Service驗證受權信息後返回jwt;
3. 服務調用方攜帶jwt請求受保護接口；
4. 受保護接口驗證jwt 的有效性，驗證有沒有權限、是否在有效期、有沒有被篡改等（這裏不用到Auth Service驗，也就是去中心化的方式，這是jwt的一大有點）。這裏寫着是網關，其實也能夠寫在接口的過濾器那裏，不過這樣每一個項目都要實現一遍驗證邏輯了。
5. 這裏已經解析完jwt，打擾能夠攜帶jwt的信息去調用接口啦；
6. 響應，流程完；

其實你們都差很少這麼用的，不論是自定義實現仍是用第三方的中間件形式，具體看需求；

Postman支持

總結：

優勢

• 由於json的通用性，因此JWT是能夠進行跨語言支持;

• 由於有了payload部分，因此JWT能夠在自身存儲一些其餘業務邏輯所必要的非敏感信息。

• 便於傳輸，jwt的構成很是簡單，傳輸字節不大，高性能。

• 去中心化，高性能；

缺點

• 安全性：若是是徹底去中心化的方式，若是jwt給黑客截取了，是沒有辦法吊銷的，開發的時候能夠考慮下如何解決這個問題；
• 攜帶的信息是徹底開放的，不能攜帶安全性高的加密信息，只能說有限安全性，依然看場景使用，不過個人經驗，平常開發絕大部分時候夠用了。

Oauth2--client_credentials（客戶端憑證）模式

Oauth2.0 有多種模式，好比Authorization Code、Implicit Flow、Password Grant等、咱們今天只來看client_credentials--客戶端配置模式吧。

咱們先看官方的流程圖：

+---------+                                  +---------------+
     |         |                                  |               |
     |         |>--(A)- Client Authentication --->| Authorization |
     | Client  |                                  |     Server    |
     |         |<--(B)---- Access Token ---------<|               |
     |         |                                  |               |
     +---------+                                  +---------------+

能夠看到很是簡單，他其實只要:

A、Client攜帶受權信息（client_id,client_scret，scopes,grant_type等）去Authorization Server 申領AccessToken；

B、Authorization Server 頒發AccessToken；

而後你就能夠用這個AccessToken 調用 受保護的接口了；

咱們來看看實例：

一、先請求AccessToken

二、攜帶AccessToken 調用受保護接口

Postman支持

其實這裏的header是這樣的：

Authorization: Bearer ZJg0rak2ZYKyZeBTH7zJzDl94AjkfwiE

那能夠看到咱們的AccessToken ，很明顯很簡短，看狀況是不攜帶任何信息的。那意味着它每次調用都須要去Authorization Server驗證AccessToken 才行，這樣接口調用量瞬間翻倍了，性能確定受影響。咱們能不能像上面提到的jwt同樣，用jwt 作token，去中心化呢？

答案是能夠的，Oauth2.0-client_credentials模式自己是對流程的標準化，並無限制token類型，因此咱們是能夠用jwt作token，可是又涉及到一個問題受權是OAth2.0的活,若是你加入jwt作身份區分那其實已是OpenId Connect的活了，那又是另外一個話題了。但那實際上是一個很是好的設計，咱們.net core裏面就用這麼個方案實現的框架IdentityServer4；

總結：identityserver4真香；

Hmac Auth

Hmac的全稱是Hash-based Message Authentication Code（基於哈希的消息認證碼）， 看起來有點蒙，咱們先來看個例子，好比咱們有以下的接口地址：

http://api.hei.com?userid=23233&age=18&type=normal

咱們常常會這樣給咱們接口加簽名：

1. 先把query參數全小寫後，按a-z排序爲，用&隔開：age=18&type=normal&userid=23233
2. 對參數32位小寫md5, md5_32(「age=18&type=normal&userid=23233」) 獲得sign：a8b8a635cc34b95a8788abfa6f6b9ff2
3. 把sign加在請求參數後面：http://api.hei.com?userid=23233&age=18&type=normal&sign=a8b8a635cc34b95a8788abfa6f6b9ff2
4. 服務端按一樣的方法驗證參數；

若是咱們把以上的 md5_32(「排序參數」）加「鹽」改成：md5_32(my_secret_key，「排序參數」） 這就是：

Hmac-Md5 算法，同理，還有：

Hmac-SHA1

Hmac-SHA384

Hmac-SHA256

Hmac-SHA512

等等算法，主要的區別在於哈希算法的不一樣。由於安全性有必定的報障，各類語言裏面都會有對應的語言無關的實現，好比.net core 裏面就有:HMACMD五、HMACSHA一、HMACSHA25六、HMACSHA38四、HMACSHA512 這五個內置類，都是調用裏面的ComputeHash()。

固然，生產中的例子可能不像上面的那麼簡單，好比接口調用方要求必定附加一個時間戳參數在請求裏，5分鐘內本請求有效，my_secret_key 很是複雜，動態 my_secret_key 等等方式。

這個Postman固然支持：

這是我用網關kong內置的Hmac Auth 插件實現的。

總結：

大總結

我以爲接口認證受權這塊挺多東西，我如今用IdentityServer4+Hmac比較多，你們平時怎麼處理的，也能夠聊一聊~

參考

https://www.cnblogs.com/edisonchou/p/talk_about_what_is_jwt.html