天天看點

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

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

寫在前面

頭發掉得多了,總有機會接觸/調到各種各樣的接口,各種面向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裡。

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

總結: 跟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. 響應,流程完;

其實大家都差不多這麼用的,不管是自定義實作還是用第三方的中間件形式,具體看需求;

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

優點

  • 因為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 調用 受保護的接口了;

我們來看看執行個體:

1、先請求AccessToken

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

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

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

其實這裡的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 裡面就有:HMACMD5、HMACSHA1、HMACSHA256、HMACSHA384、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