几种移动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的使用者进行认证，虽然增长了必定的工做量，可是对整个系统的安全性仍是有提升的。