记一次开放平台

百度百科是这样定义开放平台：

     开放平台（Open Platform） 在软件行业和网络中，开放平台是指软件系统经过公开其应用程序编程接口（API）或函数（function)来使外部的程序能够增长该软件系统的功能或使用该软件系统的资源，而不须要更改该软件系统的源代码。

在互联网时代，把网站的服务封装成一系列计算机易识别的数据接口开放出去，供第三方开发者使用，这种行为就叫作Open API，提供开放API的平台自己就被称为开放平台。经过开放平台，网站不只能提供对Web网页的简单访问，还能够进行复杂的数据交互，将它们的Web网站转换为与操做系统等价的开发平台。第三方开发者能够基于这些已经存在的、公开的Web网站而开发丰富多彩的应用。其次，开放平台包含多种含义，这些不一一赘述，笔者主要是围绕笔者在第一次参与开放平台开发到第一个上线版本的过程，其余相关的理论知识请自行脑补。

笔者接到的需求是：使用oauth2.0协议完成开放平台的搭建，形如微信。

那么什么是oauth2.0协议呢？

一、OAuth（Open Authorization，开放受权）是为用户资源的受权定义了一个安全、开放及简单的标准，第三方无需知道用户的帐号及密码，就可获取到用户的受权信息，而且这是安全的。

二、OAuth2.0是OAuth的最新版本

三、https://oauth.net/2/

                                 

两眼一抹黑，在公司内部技术分享会有对其作过介绍，可是当时却没有投入相应时间去研究与琢磨，致使浪费多数时间在学习oauth2.0协议，实属不应。

要说目前网络上的博客做者能把oauth2.0讲得最人性化，最通俗易懂，当属阮一峰老师。阮老师的博客中将oauth2.0协议讲的很是通俗易懂，关键是讲得也很透彻，因此全部初学者都从阮老师的博客中入门。传送门点此处。

oauth2.0协议中多个受权模式：

• 受权码模式（authorization code）
• 简化模式（implicit）
• 密码模式（resource owner password credentials）
• 客户端模式（client credentials）

四个模式各有优缺点，都有本身适合的场景，在此不一一赘述，可是笔者最终仍是选择采用受权码模式来作，由于它功能最完整、流程最严密，而且笔者以前简单对接过微信的开发平台，受权流程多采用该模式，因此想来它必定会更合适（后边即使采用其余的模式也能够切换自如）。

笔者接到的第二个需求是：寻找合适的受权框架。

由于笔者所在公司很早就已经开始研究微服务，而且技术上也已经落地了一整套微服务架构，目前处于持续拆分服务阶段，因此毫无疑问，若是在框架上作选择，为了与spring cloud微服务架构完美契合，最佳理想的选择恐怕是spring security这个框架。从官方文档介绍来看，它确实与spring cloud完美结合，而相比较其余框架，好比apache 的shiro框架其实也能够接入，而且它的接入成本也不会很高，可是从整个技术生态圈来讲，不合适。

然而接入spring security的成本恐怕不低，由于spring security自己很是重，由于它自己就是一套很是完善的安全框架，除了受权以外，还有诸如服务于权限控制等功能模块，而笔者手头上的项目是本身实现的受权框架，并不须要权限控制等功能模块，若是投入时间将原先的权限框架进行改造，彻底采用spring security来作，成本无疑是公司不能接受的。

思来想去，毫无头绪，没有一个合适的框架能够完美解决眼下赶上的问题，该如何是好【其实投入了不少时间在研究spring security框架，可是从架构上并不符合咱们的当前的技术生态（也许没有找到合适的方案），主要问题在于咱们的api-gateway的实现迥异】无奈之下，硬着头皮去请教个人顶头上司，寻求一个较好的解决方案。

上司的原话以下：

咱们目前的项目之因此很差采用spring security的缘由，无非是咱们最开始就没有使用它来解决软件的安全问题，因此接入成本很大，既然如此，那就本身实现一套ouath2.0的协议，不难处理，初版本先把受权码模式实现出来能够投入使用，后续版本迭代再把其余受权模式实现起来便可。

纠结了一会最后仍是正式投入时间来研究开发oauth2.0协议，自己对于协议理解只能算入门，幸好有阮一峰老师的博客。

先理解相关的名词定义：

Resource Owner：资源全部者，即用户

Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，能够是同一台服务器，也能够是不一样的服务器。

Client：第三方应用程序

Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器

             

oauth2.0的受权协议流程大体以下：

（A）用户打开客户端之后，客户端要求用户给予受权。

（B）用户赞成给予客户端受权。

（C）客户端使用上一步得到的受权，向认证服务器申请令牌。

（D）认证服务器对客户端进行认证之后，确认无误，赞成发放令牌。

（E）客户端使用令牌，向资源服务器申请获取资源。

（F）资源服务器确认令牌无误，赞成向客户端开放资源。

受权码模式认证流程以下：

（A）用户访问客户端，后者将前者导向认证服务器。

（B）用户选择是否给予客户端受权。

（C）假设用户给予受权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个受权码。

（D）客户端收到受权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。

（E）认证服务器核对了受权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。

使用通俗的说法能够理解为：用户须要访问系统资源，此时应当检查用户是否有可用（没有或者过时）令牌（access token）,若是没有可用令牌，则向资源服务发起受权服务（从笔者的项目来讲，既是外部应用请求认证服务器发起受权请求）。这个时候须要认证用户是否授信（即要求用户登陆系统，好比经过app打开登陆），登陆以后跳转至是否受权页面，该页面须要展现的内容有：受权用户协议，以及用户受权的资源（好比用户受权获取用户昵称，手机号等资源）等相关信息。用户确认受权以后，认证服务器发送受权码（code），此时客户端的服务端拿到受权码向认证服务器申请令牌。认证服务器发放令牌，客户端服务器获取令牌后向资源服务器申请开放资源，资源服务器校验令牌合法性后决定是否发放资源。

笔者在实现第一个版本的简陋开放平台赶上的几个问题整理以下：

A、受权相关接口。

    一、发起受权接口：authorize

    二、确认受权接口：confirm_access

    三、换取token/刷新token接口：access_token

    四、校验token：check_token

接口的实现不会复杂，spring security也就经过这种方式实现，内置的几个受权相关接口，相关的代码设计能够优先参考spring security简单实现。spring security经过filter作了不少事，可是只须要提早出受权相关的模块。

B、受权资源

用户进入受权页面须要肯定须要授予那些资源给到客户端来请求，这个确定会跟随不一样的业务作不一样的设计了。不过大体上是采用一种设计：接口即为资源，设计好资源组。

资源是受权双方都须要很是谨慎的一个问题，用户谨慎受权，资源服务器谨慎开放资源，保证整个过程的合法以及安全。其次，将资源分配安排好，对后期的维护以及扩展都将很是友好。好比资源是对特定的接入方开放特定的数据权限，或者统一开放可开放的数据权限等等。

C、应用接口设计 

主要考虑做为第三方接入，如何让他们快速接入咱们的应用，为咱们带来价值。若是一套设计很是 不合理的接口将会形成对方接入混乱，成本高，难以维护等各类问题。一套好的设计方案，双方都很是爽，接入方能够快速接入，而且极易维护，岂不快哉？目前从市面上了解得开放平台api设计大多为如下两类：

一、裸露的api接口：好比微信的公众号开放，翻开微信公众号的开放平台文档能够看到他们罗列的一堆的接口列表。每一个接口都提供了很是的demo，调用以及调试都很是简单，因此接入成本不高。

二、接口统一：好比淘宝的开放平台，对外是统一的api地址，经过参数method做为api名称。淘宝的开放提供了很是友好的SDK集成，因此集成快速，而且成本会更低。

两边的接口设计各有优缺点。很差说那种更优。可是就目前我的喜爱来讲，笔者倾向喜欢淘宝这种api设计风格，调用目标很是清晰，做为接入方，只须要维护一个method列表，而不是一个接口列表，总以为接口列表维护会更费劲一些，并且若是提供相应的SDK可让接入更加方便快捷。

D、token生命周期管理

最合适的应该是经过redis的定时过时，不过这里涉及了几种状况来讨论（站在对方接入的角度来讨论）

    一、token永不过时，这种设计其实不是很好，即用户受权一次即可永久使用。网关中心最好对其作白名单控制。

    二、token过时时间很是常，1个月至一年，这种token其实不太适合将其放在redis上，由于这个token存在时间太长了，维护成本过高了，况且接入方的使用率不见得很高。

    三、token过时时间很是短，通常为几个小时至几天，该token彻底能够交给redis来管理。

    四、此处省略……

基于接入方可能会使用以上几种情形来考虑该如何设计token过时时间会略微合适一点。

E、接口文档

好的接口文档一目了然。有些接口文档一整套都本身实现，很是辛苦，有些则经过第三方插件直接生成，这种方式比较理想，好比Swagger文档。

F、错误码

这是很是关键的一套接入方与被接入方之间通讯的信息。接入方经过提供的错误码能够很是快速的定位问题并解决问题，因此一套优良的错误设计也是至关重要的。