一种面向服务技术框架下不同应用间统一授权认证的方法与流程

本发明涉及一种面向服务技术框架下不同应用间统一授权认证的方法。

背景技术：

随着近年来soa(面向服务技术架构)的兴起，越来越多的应用系统开始进行分布式的设计和部署。系统由原来单一的技术架构变成面向服务的多系统架构。原来在一个系统之间可以完成的业务流程，通过多系统之间多次交互来实现，再加上不同系统访问第三方应用的情况，导致各个服务系统的互访存在规则混乱、标准不统一、安全度不够和重复建设等问题。

技术实现要素：

为克服上述现有技术的缺陷，本发明实施例提供了一种面向服务技术框架下不同应用间统一授权认证的方法，为系统内大量的面向服务的应用之间提供统一授权认证，并由统一认证中心规范系统内应用和第三方应用访问的授权和令牌的管理问题。

为了达到上述目的，提供一种面向服务技术框架下不同应用间统一授权认证的方法，该方法设置有一统一认证中心，包括如下步骤：

a)终端通过统一认证中心绑定应用系统，统一认证中心向终端返回一统一令牌；

b)终端使用统一令牌向应用系统请求数据；

c)应用系统向统一认证中心请求认证；

d)统一认证中心进行认证，并向应用系统返回认证结果；

e)若认证结果校验成功，应用系统向终端返回请求的数据；否则，应用系统向终端返回校验失败信息。

优选的，步骤a)的实现方法为：终端向统一认证中心提交注册信息，注册绑定成功后，统一认证中心向终端返回统一令牌；若终端存在与第三方应用有授权认证的情况，需先向第三方应用请求授权认证，得到第三方应用发放的第三方令牌后，将第三方令牌和第三方的认证渠道信息在统一认证中心与统一令牌进行映射绑定。

优选的，步骤b)中，终端向应用系统请求数据时，发送统一令牌时一并发送认证渠道，认证渠道包括第三方应用授权认证渠道与统一认证中心认证渠道。

优选的，若认证渠道为统一认证中心认证渠道，步骤c)中的认证由统一认证中心认证；若认证渠道为第三方应用授权认证渠道，步骤c)中的认证经统一认证中心根据映射绑定向第三方应用请求认证。

优选的，统一认证中心向第三方应用请求认证时，若第三方令牌过期，统一认证中心使用终端的注册信息向第三方应用请求更新第三方令牌，第三方应用生成新的第三方令牌，并重新将新的第三方令牌与统一令牌进行映射绑定。

优选的，若终端请求信息返回结果为统一令牌已过期，则需要重新向统一认证中心请求新的统一令牌，并用该统一令牌再次发起数据请求。

优选的，终端至少有一个，应用系统至少有一个。

优选的，统一令牌为统一认证token令牌。

优选的，第三方令牌为第三方token令牌。

优选的，统一令牌与第三方令牌均具有一定的有效期。

本发明与现有技术相比的优点为：

本发明通过使用了建立统一认证中心的应用，解决了不同应用之间授权认证的问题，以及多个终端(app、web)和不同第三方应用授权认证后，证书和令牌多而混乱，存在网络状信息交互、管理不方便的问题。对于企业的系统框架来说，建立一个统一认证中心，方便和规范了应用系统间的访问认证问题，减少了不同应用间功能的重复建设，解决不同应用间多证书和多令牌管理，简化网络拓扑结构，减少了企业软件开发成本。

附图说明

图1是本发明终端和应用系统绑定的流程示意图；

图2是本发明终端向soa应用请求受保护资源的流程示意图。

具体实施方式

在本发明描述中,术语“上”、“下”、“前”及“后”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明而不是要求本发明必须以特定的方位构造和操作，因此不能理解为对本发明的限制。

下面结合附图对本发明的具体实施方式作进一步说明。

作为优选实施例，本发明提出了一种基于oauth开放的授权标准,解决soa面向服务技术框架下不同应用间统一授权认证的方法，该方法包括以下步骤：

1、终端(app、web)和应用系统绑定步骤，具体参照图1。

s01，终端向统一认证中心发起注册认证和绑定申请，如果终端是app的情况，需要提交终端app的appkey、appid和认证渠道等信息给统一认证中心；

s02，注册绑定成功后，统一认证中心对终端发放统一认证token令牌，统一认证token令牌存在有效期；

s03，终端存在和第三方应用有授权认证的情况，比如使用qq、微信、微博等账号登录系统，需先向第三方应用请求授权认证；

s04，第三方应用成功返回授权认证信息，终端得到第三方应用发放的第三方token令牌；

s05，终端将第三方token令牌、用户id等信息向统一认证中心提交绑定；

s06，统一认证中心将第三方token令牌和认证渠道等信息与统一认证token令牌进行映射绑定。

2、终端(app、web)向soa应用请求受保护资源的步骤，具体参照图2。

s07，终端向soa服务框架的应用请求数据的时候，需将统一认证token令牌和认证渠道等信息发送给服务提供方；

s08，服务提供方在收到请求后，将统一认证token令牌和认证渠道等信息发给统一认证中心做校验；统一认证中心收到统一认证token令牌和认证渠道，根据认证渠道判断是系统内校验，还是第三方应用校验。

s09，若认证渠道为统一认证中心认证渠道，则为系统内的渠道，仅需要由统一认证中心本身做校验即可；

s10，若认证渠道为第三方应用认证渠道，则由统一认证中心根据映射绑定关系，获取第三方token令牌，再向第三方应用发起认证请求；倘若第三方token令牌已经过期，还是由统一认证中心根据终端提供的appkey和appid向第三方应用请求更新第三方token令牌，并将新的第三方token令牌和统一认证token令牌重新做绑定关系；

s11，第三方应用将认证结果反馈给统一认证中心；

s12，统一认证中心做完认证或收到第三方应用认证结果后，并将校验结果返回给服务提供方；

s13，服务提供方根据校验结果，倘若校验成功，则返回数据请求；否则，返回校验失败信息；

s14，倘若终端请求信息返回结果为：统一认证token令牌已过期，则需要重新向统一认证中心请求新的统一认证token令牌，并用该统一认证token令牌再次发起soa服务应用请求，即从步骤s07重新开始。

当然，上述方法中的oauth开放的授权标准，可以用任何成熟的其他技术框架所替代，统一令牌与第三方令牌种类可以根据实际情况进行改变。

本实施例基于token的web后台认证机制，采用oauth(开放授权)授权标准。

oauth开放的授权标准，允许用户让第三方应用访问该用户在某一web服务上存储的私密的资源(如照片，视频，联系人列表)，而无需将用户名和密码提供给第三方应用。oauth允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的第三方系统(例如，视频编辑网站)在特定的时段(例如，接下来的2小时内)内访问特定的资源(例如仅仅是某一相册中的视频)。这样，oauth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非所有内容。

而tokenauth的更是具有非常多的优点：

(1)支持跨域访问:cookie是不允许垮域访问的，这一点对token机制是不存在的，前提是传输的用户认证信息通过http头传输。

(2)无状态(也称：服务端可扩展行):token机制在服务端不需要存储session信息，因为token自身包含了所有登录用户的信息，只需要在终端的cookie或本地介质存储状态信息。

(3)更适用cdn:可以通过内容分发网络请求你服务端的所有资料(如：javascript，html,图片等)，而服务端只要提供api即可。

(4)去耦:不需要绑定到一个特定的身份验证方案。token可以在任何地方生成，只要在api被调用的时候，进行token生成调用即可。

(5)更适用于移动应用:终端是一个原生平台(ios,android，windows8等)时，cookie是不被支持的(需要通过cookie容器进行处理)，这时采用token认证机制就会简单得多。

(6)csrf:因为不再依赖于cookie，所以不需要考虑对csrf(跨站请求伪造)的防范。

(7)性能:一次网络往返时间(通过数据库查询session信息)总比做一次hmacsha256计算的token验证和解析要费时得多。

(8)不需要为登录页面做特殊处理:如果使用protractor做功能测试的时候，不再需要为登录页面做特殊处理。

(9)基于标准化:api可以采用标准化的jsonwebtoken(jwt)。这个标准已经存在多个后端库(.net,ruby,java,python,php)和多家公司的支持(如：firebase,google,microsoft)。

此外，面向服务技术架构系统之间是解耦，系统之间的通讯通过socket、ftp/文件共享服务器、数据库共享数据和message等方式进行交互，上述方法解决了通过socket和message的方式进行交互的应用之间信任问题，以及统一规范不同应用间信任授权的问题。

综上所述，本发明使用了建立统一认证中心的应用，解决了不同应用之间授权认证的问题，以及多个终端(app、web)和不同第三方应用授权认证后，证书和令牌多而混乱，存在网络状信息交互，管理不方便的问题。对于终端(app、web)只需要一次在统一认证中心注册，登记渠道、appkey和appid等信息，并将涉及的第三方应用的令牌等信息在统一认证中心做绑定后，往后只需要管理统一认证中心发放的令牌即可，使用该令牌访问服务框架内的任何服务。对于企业的系统框架来说，建立一个统一认证中心，方便和规范了应用系统间的访问认证问题，减少了不同应用间功能的重复建设，解决不同应用间多证书和多令牌管理，简化网络拓扑结构，并减少了企业软件开发成本。

根据上述说明书的揭示和教导，本发明所属领域的技术人员还可以对上述实施方式进行变更和修改。因此，本发明并不局限于上面揭示和描述的具体实施方式，对本发明的一些修改和变更也应当落入本发明的权利要求的保护范围内。此外，尽管本说明书中使用了一些特定的术语，但这些术语只是为了方便说明，并不对本发明构成任何限制。