在接口的调用一接进自动化测试以后，就不能再只靠着“能不能访问得通”这一条，去判断它到底安不安全了，testbed接口的调用，要怎么去验明正身，还有，当验明正身失败了，那本记着失败的日志，又该跑到哪里去翻，这通常是要从调用方的身份、接口的权限、令牌是不是还在有效期内、网关有没有在半道上把人给拦下来，还有服务端自己记的日志，这么好几条线索，搁在一块儿去瞅的，认证这码事，它主要就是为了去确认，跑来调用的到底是谁；而授权呢，它决定的是，这被确认了身份的家伙，都能去碰哪些资源，在接口那一类的系统里头，尤其要去躲开一种坑，就是只把登录时候的校验给做了，却松松散散地，把对权限的判断，给撂在了一边。

　　一、testbed接口调用要怎么去验明正身

　　给testbed的接口调用做鉴权，得先去瞅一眼，这是在个什么场景底下调用的，内部的脚本、调度的平台、设备的代理、还有第三方系统的接入，这几种情况，它们适合用的验明正身的法子，不一定就是一样的，可不能全都去共用一个账号，还有同一把钥匙。

　　1、去把调用方的身份给弄明白

　　要先去给每一个跑来调用的那一方，都分配上一个独立的身份，就比如，自动化脚本用的账号、设备代理用的账号、持续集成任务用的账号，还有外部系统用的账号，可别让一大帮子人，都去共用着一个管理员的账号，来来回回地调接口，要不然的话，等真出了什么问题，是根本就没法子去查清楚，当初那个请求，到底是谁给发出来的。

　　2、去挑一种合适的、能验明正身的法子

　　常见的法子，有用账号和密码先去登进去，然后拿回来一个令牌的、有直接就用接口钥匙的、有用开放授权令牌的、有靠着客户端的证书的，还有那种把请求拿去做签名的，在内部的testbed上，是可以用令牌，或者是接口钥匙，去图个快，赶紧接进来；可要是跨了系统，或者是那种权限给得比较高的接口，那最好还是再额外地加上，签名、过期的时间，还有对请求来源的校验。

　　3、去把接口能碰的范围，给框死

　　验明正身这一关，就算是过了，这也不等于，所有的接口，就都能敞开了让你随便去调了，是应该照着角色的不同，去把权限给切开的，就比如，只让查、不让改的，可以去建任务的，可以叫停任务的，能去直接控制设备的，可以做固件升级的，还有能把数据给删掉的，那些风险高高的接口，是得要单独去给授权的，可不能把所有的权力，都给一股脑儿地绑在同一个，拿来通用的令牌上头。

　　4、去把令牌管用的期限，给好好地限制住

　　令牌它能管用的那个有效期，可不要给设得太长了，那种自己会跑的自动化任务，是可以去用那种短期的令牌，然后到了时间，就再去定时地刷一下的；那些要长期连着线的设备代理呢，就可以去用那种，能被定期换掉的钥匙，等到钥匙一旦被换过了以后，就得要同步地去把Jenkins那边的、调度脚本那边的，还有设备那一头的配置，全都给更新一遍，要躲开那种，旧的钥匙，还一直在那明晃晃地暴露在外头的情况。

　　二、验明正身失败的日志，要在哪里去翻看

　　testbed鉴权失败记下来的日志，是要分着层去瞅的，一次返回了未授权，或者是禁止访问的状态，这可不一定是，单从应用服务那边给扔回来的，它也有可能是，在这之前，就已经被网关、代理、身份那一套系统，或者是权限的服务，给半道上截下来了，认证的日志，它一般是会把，谁想登进来、是因为什么才没登成、是谁在试，还有是在几点几分来试的，这些东西，全都给记下来的，在动手排查的时候，要特别去留意，那个错误码、拿来追踪请求的ID、是从哪个IP过来的，还有调用的是哪条路径。

　　1、要先去瞅一眼，接口那边给返回了些什么

　　在调用给跑失败了以后，要先去把HTTP的那个状态码、接口的路径、请求是在什么时间发出去的、用来标记这次请求的ID，还有响应里头塞着的内容，这一串都给记下来，状态码要是未授权，那多半是跟身份的认证，脱不了干系；要是禁止访问，那常常就是权限没给够；要是提示请求太多了，那可能是被限了流；可要是服务器内部报了错，那就要接着往下头，去看服务端的异常了。

　　2、去翻一翻网关，或者是代理那边留下的日志

　　要是testbed的前头，还顶着像Nginx、API网关、Ingress，或者是反向代理这一层东西，那就先要去翻这一层的日志，有好些个鉴权失败，它是在网关那一头，就被直直地给拦了下来的，后头的应用服务，是压根儿就连请求的面，都没见着的。

　　3、去翻一翻应用自己记下来的认证日志

　　进到跑着testbed服务的那台机器里头去，去把跟认证、安全、应用、访问，这几样相关的日志文件，都给找出来，要在里头，重点去搜，那个用户名、客户端ID、IP地址、接口的路径、请求追踪的ID，还有像什么令牌是无效的、令牌它过期了、签名验不过去、还有权限被拒，这些个顶顶关键的词。

　　4、去翻一翻身份系统那边的日志

　　要是testbed的后头，还接着像目录访问协议、单点登录、开放授权、专门管身份的那一套，或者是企业里头统一认证的平台，那就要再跑到身份系统的后台里头去，查一查它登进来的记录，还有往外签发令牌的记录，平台那一类的身份日志，它一般来讲，是会明明白白地把因为什么才没通过，还有对应的那个错误码，都给提供出来的，这个东西，在你去判断，到底是密码给敲错了、还是账号被人家给禁掉了、又或者是令牌已经过期了，是非常有用的。

　　三、鉴权出了异常要怎样去把它给闭环定位

　　testbed鉴权出了异常的时候，可别就只是去把钥匙给改一改，然后再去重试一下子，更合适的法子，是去把请求走过的那一整条链路，都给它还原出来，去弄弄清楚，这个请求，从脚本那边被发出来以后，它到底是，挨个地经过了哪一些组件，最后，又是在哪一层上，被人家给拒在了门外。

　　1、要按着时间，去把日志给对齐了

　　得把客户端发起调用的那个时间、网关记下访问的那个时间、应用日志里对应的时间，还有身份系统那边的时间，这好几样，都拢到一块儿去瞅，要是这几个系统的时间，它压根儿就没有被同步过，那就要先动手，去把时间上的那个差，给换算一下，要不然的话，是很容易，就摸错了日志的。

　　2、得拿请求的ID，去把整条链路都给串起来

　　在动手去调接口的时候，是非常建议，在请求头的那一栏里头，主动去塞进去一个用来追踪全链路的ID，然后，在服务端那边，也得要把它给妥妥当当地记到日志里头去，这么一来，从最开始的客户端，到网关，再到应用的服务，一直到最后管身份的系统，这所有的环节，就都能被一串儿地给穿起来了，也就不用再靠着，去对那个模模糊糊的时间点，来猜来猜去了。

　　3、再回过头去，把配置上的变更，复查一遍

　　在发现鉴权，是突然一下就败下来了的时候，要着重去瞅一瞅，最近是不是动过了令牌的钥匙、证书、回调的地址、白名单、角色的权限、接口的路径，还有网关的规则，有老些个问题，它其实就出在，配置只给更新到了一半，可是调用的那一头呢，还在那傻傻地，用着旧的配置。

　　4、去把失败时候的样本，给保留下来

　　要把那个跑失败了的请求的时间、用的是哪个账号、调的是哪个接口、返回了什么状态码、日志里截出来的关键片段，还有最后是拿什么法子给处理掉的，这些东西，全给记下来，这么攒着，等到后面再碰上了差不多的毛病，就可以直接去对着它来瞅，到底这是账号权限上的事、是令牌惹的祸、是签名没搞对，还是网关那边，又新立了什么规矩。

　　总结

　　给testbed的接口调用做鉴权，是要先去给每一个调用方，都弄一个独一份的身份，然后再照着接口本身的风险高低，去把令牌、接口钥匙、签名、证书，还有角色的权限，这些东西都给设好，到了要去翻查鉴权失败的日志时，就得照着客户端、网关、应用服务，还有身份系统，这么一层一层地往下捋，重点要去抓牢那几样东西：状态码、请求的ID、时间、账号，还有到底是因为什么才出的错，等这一整条链子，全都被妥妥地串起来了以后，那么鉴权失败这档子事，就能从在那儿“翻来覆去地试着重试”，给变成一种，能被清清楚楚地定到位、能被完完整整地复盘，最后还能被结结实实地给修好的问题了。