API安全性设计------让你的接口从此不在裸奔

背景：在以HTTP为协议的REST API服务中，我们业务核心代码固然重要，但是如何保证api的安全性也是举足轻重的，本文将从一般接口和资源接口两方面进行讲解。

 

1 资源接口

资源接口，一般采用主动询问授权的方式，例如oauth2.0来保证资源的安全，这类接口注重资源的安全，不涉及复杂的业务代码，在认证和授权的过程中涉及到三方：

1、资源提供方：提供资源的角色，如照片，视频等。

2、用户：资源的拥有者

3、客户端：要访问服务提供方资源第三方，通常是网站，在认证过程之前，客户端要向服务提供者申请客户端标识。

 

授权过程如下：

    1 用户想操作存放在服务提供方的资源。

    2 用户登录客户端向服务提供方请求一个临时令牌。

    3 服务提供方验证客户端的身份后，授予一个临时令牌。

    4 客户端获得临时令牌后，将用户引导至服务提供方的授权页面请求用户授权。在这个过程中将临时令牌和客户端的回调连接发送给服务提供方。

    5 用户在服务提供方的网页上输入用户名和密码，然后授权该客户端访问所请求的资源。

    6 授权成功后，服务提供方引导用户返回客户端的网页。

    7 客户端根据临时令牌从服务提供方那里获取访问令牌。

    8 服务提供方根据临时令牌和用户的授权情况授予客户端访问令牌。

    9 客户端使用获取的访问令牌访问存放在服务提供方上的受保护的资源。

（备注：OAuth 2.0是个全新的协议，不向后兼容OAuth,但是整体架构类似)

 

2 业务接口

 此类接口主要负责核心业务，也就是我们常规意义上的接口，主要从三个方面来保证接口的安全性：

 

1、身份验证： 是否有权限访问接口。

      根据控制的力度可以分为2种，接口的身份验证和用户的身份验证，其中接口的身份认证主要是看用户是否有访问接口的权限，用户身份认证则是全局的认证，一般情况下只考虑全局的认证即可，可以使用token机制。

  设计： 三层token ： 

           1 临时token（有效期短）   

           2  长期token（有效期长） ，一般在登录的时候获取，临时token失效后，通过长期token获取。

           3  用户token（做混淆，可选）

  备注：不限于三层token，根据业务，安全性和效率做出平衡。

 

2、防止篡改：解决水平越权的问题，参数被修改后，必须重新利用加密算法，生成新的sign，否则鉴权失败。

      设计：  前后端约加密算法，采用对称加密或者非对称加密，生成sign：

                1 前端加密算法，生成csign

                 2 后端采用同样的加密算法，生成ssign

                 3 对比csign和ssign，相同则放行，不同则拒绝

 

3、接口重放：最好接口一次有效，单位时间内有效根据实际业务场景看能否接受

    设计：  根据业务和控制力度分为三种,一次有效还是单位时间内有效，还是幂等设计

             1  一次有效，则可以在参数中加入时间戳，并且纳入到加密参数中去，后端采用缓存记录sign，如果存在则拒绝，不存在则放行；

           2  单位时间内有效，同样的思路加入时间戳，后端判断时间区间范围（由于前后端时间不一致，有误差）

            3 幂等设计的话，允许重放，不影响最终结果。（注意加上版本号）

 

备注：http升级为https，也可以作为提升安全性的手段，移动端一定要做代码混淆，防止加密算法泄漏，web端利用cookie，session等内存操作来保证安全（内存操作相对是安全的，黑客无法获取用户的内存信息），最后请记住，没有决定的安全，关键是你为你的应用安全提高多少门槛。