幾種移動app API調用認證方案淺析

最近作的金融項目，app調用的接口須要作一個身份認證，因此找了下目前API services驗證的幾種方式。以前翻譯的一篇文章——[譯]移動API安全終極指南中，主要提出了API服務調用驗證的問題，經過添加認證，防止API濫用。裏面提到了基本的HTTP Basic Authentication、OAuth2.0以及JWT這三種驗證方式，同時對這三種認證技術的原理作了大體的梳理。那麼這篇文章主要介紹一下這幾種認證方式的使用環境以及別的一些方法用於API接口調用認證。

下面就列舉一些常見的認證方式和應用，有些大廠的驗證方法和常見的驗證協議是值得咱們學習的。

1. 相似HTTP Basic Authentication
隨意在網上搜索公共API服務，好比下圖中的百度基站查詢的接口。

這種接口通常付費以後會獲取到一個apikey，經過apikey進行請求。和HTTP Basic Authentication相似，須要把apikey這個字段寫入HTTP header中，服務器驗證後，返回相應的結果。

總結：也許是由於公共api的緣由吧，因此驗證的方式比較簡單。下面會講到，一樣是百度的api，在獲取地理數據方面，驗證方式會嚴格不少。固然即使是有人惡意抓包獲取到付費用戶的apikey，也不會形成太大的危害。這類型的接口通常都有當天最大的請求次數，同時用戶也很容易發現。

參考：

• 基站數據查詢

2. 百度LBS接口加密的方式

上圖是百度地圖中的API服務，經過IP來獲取獲取位置信息。
他的加密方式以下：

首先，購買了此服務的開發者會拿到ak（apikey）和sk（secretkey）。接口調用時除了公共參數以外，還須要ak和sn兩個參數。sn是一個用特定算法生成的加密串。

sn生成算法

1. url後的參數根據鍵值的字典排序（get不須要），拼接成字符串，utf-8編碼。
2. 拼接sk後再utf-8編碼
3. md5編碼。

服務器接收到參數後，經過開發者的ak獲取到sk，再根據上述操做，生成sn進行比對，驗證經過後，調用相應的接口返回結果。

總結：這種方法提到了ak和sk，有一種RSA的味道，安全性顯然比上一種強不少。因爲私鑰是不傳播的，只要作好祕鑰管理，應該仍是比較難破解的。

參考：

• 利用IP獲取大體位置
• sn計算規則

3. OAuth2.0
原理很少講，兩次握手獲取認證，受權獲取相關資源。好像app上用到的很少，最多的應用是在複雜系統的單點登陸和第三方登陸上（可參考微博、QQ登陸，微信公衆號受權等）。

參考：

• 阮一峯——理解OAuth 2.0
• 幫你深刻理解OAuth2.0協議
• 微信網頁受權

4. 相似OAuth2.0的access_token和refresh_token
熟悉OAuth2.0的開發者都知道，整個受權流程。

1. 受權獲取code。
2. 經過code獲取access_token和refresh_token。
3. 根據access_token請求資源。

那麼問了杭州某移動互聯網公司的小夥伴他們認證方案。結果就是簡化版的OAuth2.0。

1. 用戶登陸後，後臺簽發access_token和refresh_token。
2. access_token過時後使用refresh_token進行刷新。
3. refresh_token過時，app提示從新登陸。相似OAuth2.0的從新受權。

5. JWT
JSON Web Token，2015年出的一個標標準（RFC 7519）。

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.

簡單來說就是一個加密串，和傳統的token不一樣，這個加密串不是nosense，而是能夠解密成兩段json數據。加密串以下所示，點分三段式結構。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

解密後分爲兩段json：

{
  'typ': 'JWT',
  'alg': 'HS256'
}
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

綜上JWT的形式是這樣的：
[json1 base64加密].[json2 base64加密].[(json1加密後+json2加密後+secret) sha256加密]

總結：詳細的原理能夠看那篇我翻譯的文章。那麼和傳統的token相比就頗有優點了。當移動app登陸，API服務器獲取用戶的ID加上過時時間等信息生成JWT，簽發給app。下次app調用API附帶JWT，服務端解析後，返回結果。因爲全部的信息都存在JWT中，也就不須要使用數據庫存儲和查詢，這些額外的開銷了。

參考：

• RFC 7519
• 什麼是 JWT -- JSON WEB TOKEN
• JSON Web Tokens - jwt.io

總結

目前看到的認證方式基本上就是以上這幾種，固然還有上述幾種的組合，例如OAuth2.0+JWT。服務器對API的使用者進行認證，雖然增長了必定的工做量，可是對整個系統的安全性仍是有提升的。