第三方token过期监控及刷新机制

背景

信息系统随着业务发展的多样化及场景的拓展，需要接入越来越多的第三方系统，部分收费的第三方服务都会按照合同约定给用户提供对应的应用授权账户，授权账户包含并不仅限于账号/密码/AppKey/AppSecret/MerchantId，但是从系统安全角度出发，为了保护授参数的安全性和系统的稳定性，服务商都有针对账号进行流量控制/服务降级/关键安全信息定期更新等机制，来确保双方系统稳定及安全，本次说到的Token过期就是其中的一种保护账号安全的机制

现状

各第三方服务token过期时间

针对目前的一些第三方服务，目前渣渣所了解到的是，拼多多的部分接口授权token是15天过期时间，蘑菇街/蘑菇街小店的token过期时间是7天，京东/淘宝等是一年的过期时间。

存在的问题点

有朋友会说，这个问题很好处理，token过期那就刷token就是的；是的，对于一个开发来说，刷token很简单，按照官方的文档操作就可以了，但是现在大多数的企业都存在以下场景，致使刷token的过程效率比较低，沟通成本却很高，从开发和运营角度去看

开发角度

• 用来刷token的账号一般都是业务账号，开发需要走流程才能获取到。
• 此类账号一般异地登陆或者换PC登录都需要手机号验证，沟通成本和及时性很难保障
• 操作2分钟，沟通一小时，线上问题迫在眉睫

运营角度

• 大多数运营不知道这个系统中存在这个问题，只在线上出问题后，开发才反馈有此问题
• 我有账号，我不知道怎么操作，操作的流程都是一串串代码，我不会
• 线上出问题了，需要快速恢复业务，我直接去开发工位去处理

以上问题总结起来就是，有权限的不会处理，会处理的没权限，部分公司的做法就是运营把账号给到开发，并提供手机号验证码；开发愿意去接这个么？大多数情况不愿意，因为此类账号里面一般都会有运营的数据或者一些销售数据，比较敏感，例如天猫和京东的账号，是有发优惠卷和上线营销活动的权限的。

处理方案

开发侧

• 在token过期前提醒运营进行刷新操作，一般是过期前一周内(有效期较短的过期前3天，一般有效期比较短的都不需要验证账号)
• 开发业务操作页面，方便运营在自研系统中进行操作
• 页面简历tips,提示具体的每一步操作

运营侧

• 注意查收特定邮箱的预警邮件，处理完成后回复邮件及抄送人
• 操作过程中有问题需要开发协助及时沟通

具体落地方案(以京东平台为例)

开发建立第三方服务表(第三方服务信息管理)

存储关键信息:
平台名称/业务名称/AppKey/AppSecret/Token/RefreshToken/EndDate等关键参数

了解刷新流程

京东平台授权刷新流程
以下内容转发，可以直接去
京东授权刷新流程查看原汁原味的

1、请求入口地址
1）获取授权码（code）
https://open-oauth.jd.com/oauth2/to_login
2）获取访问令牌（access_token）
https://open-oauth.jd.com/oauth2/access_token
注意：如授权账号（商家为主账号）修改密码则授权码（Access token）随之失效，需重新授权。
2、授权操作步骤
       实际进行授权操作时，测试的数据 app_key、app_secret、redirect_uri 均需要根据自己创建的应用实际数据给予替换，不能拿示例中给出的值直接进行测试，以免影响实际测试效果。
 1）拼接授权url
    拼接用户授权需访问url ，示例及参数说明如下：
https://open-oauth.jd.com/oauth2/to_login?app_key=XXXXX&response_type=code&redirect_uri=XXXXX&state=20180416&scope=snsapi_base
2）引导用户登录授权
    引导用户通过浏览器访问以上授权url，将弹出登录授权页面。用户输入账号、密码点“登录”按钮，即完成授权流程。在PC浏览器里，该页面支持授权用户京东APP扫码登录；若授权用户已经在该浏览器中登录京东，则可实现一键授权登录。
3）获取code
    上图页面，若用户点“登录”按钮后，开放平台会跳转到指定的redirect_uri并多添加两个参数code和state参数（浏览器地址栏），应用可以获取并使用该code去换取access_token；
返回示例：
redirect_uri?code=CODE&state=STATE
说明：
    可发布服务市场（fw.jd.com）的应用，在应用上线后，如购买应用的用户，通过"我的服务--立即使用”访问（下图)，系统会自动跳到授权页面（因此这种方式访问应用的，不需要拼接url），只需注意获取code即可。同时返回code时，还会返回通过state传递订购服务相关的信息；
注意：state中如果有“+”号，因浏览器交互的原因，会出现“+”号替换成空格的现象，导致授权报错，如果出现此种情况，请把的state 中的空格再替换成“+”号，state后面的是经过base64编码，使用者可以通过收费项目编码或者版本号来指定自己软件对应的服务并可以通过接口进行验证参数的正确性，反编码后内容如下：

{
   "jos_parameters":
{
        "app_key": "CB69F1769C4B110D010D128E41030C94",
        "end_date": 1469289600000,
        "item_code": "FW_GOODS-233232-1",
        "source": "JM",
        "user_name": "sop_order",
        "version_no": 1
    }
}

大体流程如下图:

建立监控机制

上述表中我们有存储字段EndDate，通过建立定时调度去扫描此表，判断当前时间与EndDate之间的关系，确定刷否需要刷新token，不需要则无提示，需要刷新时可通过邮件/钉钉/企业微信等方式通知相应人员；注意此处最好发送给操作人员，抄送给相关支持人员和开发

操作平台设计

页面简图:
页面可选模式:列表展示单行修改/平台名称+业务模块下拉选择修改

1. 建立单行表单，可选择平台名称/业务名称，触发授权按钮，服务拼接授权参数访问第三方登陆平台，此处需要保留原页面。
2. 用户在页面上获取到code后，将code填充到表单中的授权code栏目中并点击确认授权按钮，应用发起授权请求，并从返回的结果中解析出对应的end_date/access_token/refresh_token等字段
3. 将以上信息更新到表中维持之后的监控判断

写在最后

以上方案，只有在第一次处理时需要开发接入，原则上后续的流程只是对此功能的维护。
另外有些企业可能考虑到将这些参数存在表中，安全性可能会有问题，此类数据可以考虑关闭开发访问权限。