鉴于微博、QQ、微信等开发平台的影响，互联网行业的工程师都知道OAuth协议和用户信息Token存储的机制，但很少有人提及it两方OAuth的概念。两方OAuth一提到OAuth协议，下意识就会想到认证、客户端、服务器三方，然后是认证服务器、客户端应用、资源服务器。现在常见的OAuth协议是OAuth2.0，是互联网开放授权协议，用于规范资源服务器、客户端应用、授权服务器的职责，实现客户端不直接获取用户名和密码的普通用户。前提下，访问用户私有资源。在实际的应用开发过程中，当我们的应用复杂度没有达到一定规模时，应用只涉及到客户端APP和服务端中央云服务的认证和业务处理。我们可以简化OAuth2.0协议，进化成两方OAuth。上图[Auth-history.png]是服务端客户端认证的几个阶段。OAuth协议可以更理解为一个广义的协议。在工程应用方面，只注重规范，不要求细节。最初的OAuth协议是服务端根据HTTP协议头的Authorization字段来验证客户端的身份。现在逐渐演变为使用Token来标记客户端身份和存储用户状态信息。至于Token如何产生，如何在HTTP协议中传输，没有太多硬性要求。消费者APP在OAuth协议体系中，消费者是指开发者开发的APP。这里的APP是一个广义的概念，并不局限于Android和iOS应用这两类。PC网站和手机WebView也被认为是APP服务器。各种云平台如何识别这些应用？借助应用编号和应用密钥机制，应用编号为APP_ID，即APP_KEY，用于唯一标识应用。密钥为APP_SERCRET，用于请求签名等安全算法的输入参数，以及服务器端验证的凭据。APP_KEY和APP_SERCRET的分配和管理是实现两方OAuth的第一步。看完这里，你可能会有疑问。上面说的不同的APP无非就是Android、iOS、WebView。为什么我们不定义不同的枚举？标记不同的client，甚至可以用User-Agent来判断。1PC，2Android3iOS4微信，能解决吗？答案很难。其实这是两个概念。从操作系统的角度来说，更多的是数据源通道的概念，APP_KEY的本质属性是开发者接入云平台的应用标志。Token生命周期以下是Token生命周期模型的简化版本。代币分配由客户端发起，服务端云端负责分配。典型场景下，在用户成功登录后分配，并在一定有效期内过期。支持每次请求不一致，token滑动过期。机制。默认为30分钟。生成规则用户令牌密钥：用户id+申请号。md5(userid+saltkey+timestamp)salt值是固定的。生成规则可根据项目单独调整，Token价值不可逆。存储服务器端键值存储在redis中。key是token，value是加密后的值。自动地。退出时需要调用接口删除token。这就会引出一个问题：出口功能是否需要网络支持？这个问题的原因是我发现有的工程师，exit函数是这样做的，页面跳转，本地Token被清除。Token代表用户态，代表了客户端和服务端之间的一种关联关系，退出函数就是切断这种关联。HTTP是无状态的，只是简单的响应请求，业务必须是有状态的，否则业务无法流通和推进。这个状态交给Token，两者是怎么关联的。Token设计时需要考虑。比较完善的Token落地机制是实现双方OAuth的第二步签名算法签名（Sign），保证数据的真实性和完整性，从及时性、合法性、频率等维度进行处理。将所有待签名参数按照字段名的ASCII码从小到大（字典序）排序后，使用URL键值对格式（即key1=value1&key2=value2…）拼接成字符串字符串1。这里需要注意的是，所有的参数名都是小写字母，并且在末尾加上&secret=app_secret；string1使用签名算法，字段名和字段值都是没有URL转义的原始值。具体的签名算法为sign=md5(string)。对于除登录之外的所有接口，由服务器决定是否启用签名验证。业界称为验证。签名采用APP_SECRET设计点，前后端分离，将接口参数分为系统级参数和业务级参数。系统级参数主要有app_key、timestamp、token、os_type、sign，主要放在HTTP请求头中。业务参数基于业务需求，通过POST或GET方式按需下发。检测请求超时使用客户端时间戳timestamp来确定真正的客户端发起时间。服务器检测时间差，将客户端请求时间与服务器时间的差值与超时时间进行比较。比如我们可以约定一个时间差大于5分钟间隔的请求是无效请求，或者是超时请求。识别终端采用App-Key方式识别应用终端，企业内部不同的应用由云服务统一管理。场景一：个性化配置，微信公众号登录用户的过期时间设置为1天，PC官网登录用户的过期时间设置为一周。场景2区分公司某条产品线的普通版和定制版，使用App-Key，对功能的简单复杂度和计费方式进行渐变设置。场景3应用于SASS应用识别、多租户数据隔离、数据库中应用数据隔离。进而为相关运营数据分析提供支持。其他设计规则1后台配置关闭使能开关，验证在开发阶段可以关闭，建议开启。2启用身份验证后，前端需要有一个公共方法来计算请求签名。后台需要增加一个安全验证模块来验证请求的合法性，负责登录过期检测、参数完整性和权限验证。3在安全方面，注重安全灵活性。通过timestamp、sign、token参数三个维度逐层升级安全验证级别。通过添加身份验证条件和复杂性来提高安全级别。安全级别可以合理，不能一概而论。综上所述，上面给出了一套基于两方OAuth方式的云和客户端服务设计模型。在应用服务不复杂，业务场景允许的前提下，可以采用两种OAuth方式，随着业务的发展，可以逐步演化为基于三方身份的OAuth协议项目实现。令牌机制和签名机制也可以独立分层，与业务应用分离，演化为网关系统。这种设计符合架构领域的简单和进化原则，是一种非常实惠的应用架构解决方案。
