真实业务场景下的开放平台架构及实现

需求：

1. APP支持多种登录方式

   包括：

   • 用户名和密码
   • 手机号加验证码
   • 其他渠道的第三方登录，如微信、支付宝等第三方登录

2. 支持微信小程序、支付宝小程序对受保护资源的请求

3. 支持APP自身H5页面对受保护资源的请求

4. 支持第三方应用H5页面获取受保护资源的请求。第三方应用H5页面分为两种情况：

   • 第三方应用有自己的后台和前端H5页面的，嵌入到我们系统里面的
   • 第三方应用仅提供接口，没有后台和H5页面的，我们来为其开发后台和H5页面

架构设计：

由四部分组成：API网关、开发者中心、授权中心、控制后台

API网关

如果你写一个死循环，那么就有可能把API网关搞挂掉，怎么办呢？一个非常重要的模块就是流量控制（熔断），在流量控制中限制某一个app或某一个应用在规定时间内访问流量的大小，异步从控制后台拿取流控设置。

在api网关必须要验签通过，才能访问业务服务（受保护资源）

开发者中心

开发者注册，申请应用，查看文档，数据接口，是直接对外的

授权中心

颁发授权码code，颁发访问令牌access_token，校验访问令牌，吊销访问令牌

企业级授权服务器的监控

• 授权次数
• 颁发访问令牌/刷新令牌个数
• 活跃令牌数
• 令牌校验次数
• 令牌吊销次数

控制后台

整个开发平台运营人员的操作后台，配置如流量阀值，app申请的时候能否通过审核等

实现：

需求1：app登录

登录认证成功，返回access_token和refresh_token，可以看做是第一方app+资源拥有者凭据模式

app-gateway：给app原生使用，只使用token

需求2：小程序

• 首先，开发者通过wx.login(Object object)方法获取到登录凭证code值，这一步的流程是在小程序内部通过调用微信提供的SDK实现（本质上还是通过ajax获取code）；
• 然后，再通过该code值换取用户的session_key等信息，也就是官方文档的auth.code2Session方法，同时该方法也是被强烈建议通过开发者的后端服务来调用的。

oauth-gateway：采用授权码模式

需求3：APP自身H5页面

h5-gateway：给app自身H5来使用，使用授权码模式

需求4-1：第三方H5页面，无server端

api-gateway：采用implicit模式

注意：这种方式下一般是嵌入无用户状态的服务，比如垃圾分类、实时公交等功能，如对用户信息敏感，此方式并不安全

需求4-2：第三方H5页面，有server端

api-gateway：采用授权码模式

我们这里使用了自动授权方式

令牌有效期及scope的处理

• authcode：有效期5min

• access_token：有效期12个小时

• refresh_token：14天

• 对于登录，返回token，scope=all

• 对于小程序，H5，返回token，其token绑定appId + 用户 + scope

实现方案

方案1：可以遵从oauth2.0协议自编码实现

方案2：也可以依赖spring security技术栈

• 通过spring security实现用户名密码及手机号+验证码登录
• 通过spring social实现联合登录
• 通过spring security oauth实现oauth授权