开放平台认证方案

背景

本次的直接起因是第三方那边接入系统后端引起的，第三方方觉得认证要过期比较麻烦，而且要用账号密码去调登录接口去刷token，设计不合理。

客观来说：

凭本人使用过其它开放平台来说确实有些不一样。 常见的一些开放平台，有带web的，一般web能看到的接口，在你想进行一些二次开发时调用他们的接口是另外一套接口，web显示的一般会在包一层（github web端直接返回的html）。另外调用他们的接口的认证方式也不是像在web端那样，走传统的账号密码登录的方式。

主观来说：

有没有必要去做，还是要看我们系统的定位，如果想像一些开放平台一样对外提供服务，那么看来是有必要的，如果最终只是内部用，那么是没必要的。这些认证也往往考虑计费模式。另外过期是合理的，可能也只是刷 token的方式有点不合适。

方案一

Token auth

用户输入账号密码校验成功后，服务端返回token，以后客户端就可以用token去调接口，token过期或者永久都可以，看业务。

常见的实践有jwt等

我们目前还是用的sso-token，会2个月过期，过期后需要调用方使用账户密码主动调用sso登录接口去更新token。

优点：

1.不用改动或改动较小

缺点：

1.安全性，后端和前端共有接口及认证方案，客户能直接登陆我们的pegasusu配置平台。

方案二

Hmac

一般用户在个人主页申请appid࿰