2024年6月13日发(作者：)
API
应用接口安全管理细则
一、API定义
APl类型主要分为：内部API、企业定制APl与外部APl三种类型。本标准
主要关注外部APL即本标准所述的商业银行接口。
两种形态：服务端到服务端、客户端SDK到服务端两种形态API。
二、Token授权认证
HnP协议是无状态的，一次请求结束，连接断开，下次服务器再收到请求，
它就不知道这个请求是哪个用户发过来的，但是对我们有权限访问限制的模块
而言，它是需要有状态管理的，以便服务端能够准确的知道HnP请求是哪个用
户发起的，从而判断他是否有权限继续这个请求。
Token的设计方案是用户在客户端使用用户名和密码登录后，服务器会给客
户端返回一个TOken,并将Token以键值对的形式存放在缓存（一般是RediS）
中，后续客户端对需要授权模块的所有操作都要带上这个TOkerb服务器端接收
到请求后进行TOken验证，如果TOken存在，说明是授权的请求。
TOken生成的设计要求：
1、应用内一定要唯一，否则会出现授权混乱，A用户看到了 B用户的数据；
2、每次生成的Token一定要不一样，防止被记录，授权永久有效；
3、一般Token对应的是Redis的key, value存放的是这个用户相关缓存信
息，比如：用户的id；
4、要设置Token的过期时间,过期后需要客户端重新登录,获取新的Token,
如果Token有效期设置较短，会反复需要用户登录，体验比较差，我们一般采
用Token过期后，客户端静默登录的方式，当客户端收到Token过期后，客户端
用本地保存的用户名和密码在后台静默登录来获取新的Token,还有一种是单独
出一个刷新Token的接口，但是一定要注意刷新机制和安全问题；
根据上面的设计方案要求，我们很容易得到Token=md5（用户ID+登录的时
间 戳+服务器端秘钥）这种方式来获得Token,因为用户ID是应用内唯一的，登
录 的时间戳保证每次登录的时候都不一样，服务器端秘钥是配置在服务器端参
与加 密的字符串（即：盐），目的是提高Token加密的破解难度，注意一定不
要泄漏；
三、时间戳超时机制
客户端每次请求接口都带上当前时间的时间戳timestamp,服务端接收到
timestamp后跟当前时间进行比对，如果时间差大于一定时间（比如：1分钟），
则认为该请求失效。时间戳超时机制是防御DOS攻击的有效手段。
四、URL签名
写过支付宝或微信支付对接的同学肯定对URL签名不陌生，我们只需要将原
本发送给server端的明文参数做一下签名，然后在server端用相同的算法再做 一
次签名，对比两次签名就可以确保对应明文的参数有没有被中间人篡改过。
首先我们需要分配给客户端一个私钥用于URL签名加密，一般的签名算法如
下：
2、对排序完的数组键值对用&进行连接，形成用于加密的参数字符串；
3、在加密的参数字符串前面或者后面加上私钥，然后用md5进行加密，得 到
sign,然后随着请求接口一起传给服务器。
例如：
服务器端接收到请求后，用同样的算法获得服务器的sign,对比客户端的 Sign
是否一致，如果一致请求有效；
注意：对于客户端的私钥一定要妥善处理好，不能被非法者拿到，如果针对
于H5的项目，H5保存私钥是个问题，目前没有更好的方法，也是一致困扰我的
问题，如果大家有更好的方法可以留言一起探讨。
五、防重放
客户端第一次访问时，将签名Sign存放到服务器的RediS中，超时时间设 定
为跟时间戳的超时时间一致，二者时间一致可以保证无论在timestamp限定时 间
内还是外URL都只能访问一次，如果被非法者截获，使用同一个URL再次访 问，
如果发现缓存服务器中已经存在了本次签名，则拒绝服务。如果在缓存中的 签名
失效的情况下，有人使用同一个URL再次访问，则会被时间戳超时机制拦截, 这
就是为什么要求sign的超时时间要设定为跟时间戳的超时时间一致。拒绝重 复调
用机制确保URL被别人截获了也无法使用（如抓取数据）。
以上方案流程如下:
发布者：admin，转转请注明出处：http://www.yc00.com/web/1718228928a2747517.html
评论列表（0条）