几种移动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的使用者进行认证，虽然增加了一定的工作量，但是对整个系统的安全性还是有提高的。