CN103716326B - 一种资源访问方法及用户资源网关 - Google Patents

Abstract

本发明提供一种资源访问方法及用户资源网关，该方法包括：用户资源网关URG接收客户端发送的资源请求；其中，资源请求中包含一个或多个资源ID，每个资源ID对应一个资源；URG对客户端进行权限验证；URG在验证通过后基于一个或多个资源ID生成对应一个或多个资源服务器的一个或多个单个资源请求；每个单个资源请求中包含与所请求资源对应的访问令牌，访问令牌表征资源所有者允许URG访问资源；URG分别发送一个或多个单个资源请求给一个或多个资源服务器；URG从对应的资源服务器接收一个或多个单个资源请求的一个或多个响应消息，一个或多个响应消息中携带与一个或多个单个资源请求对应的资源；URG将资源发送给客户端。

Description

一种资源访问方法及用户资源网关

技术领域

本发明涉及通信技术领域，尤其涉及一种资源访问方法及用户资源网关。

背景技术

OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAUTH的授权不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此OAUTH是安全的。

OAUTH2.0中有四个逻辑功能实体，分别为资源所有者、资源服务器、第三方客户端以及授权服务器。下面就对四个逻辑功能实体进行简要的阐释：

资源所有者：一个实体能够授权访问一个受保护的资源。当资源所有者是一个人，就称为一个终端用户。

资源服务器：用于接收第三方客户端发送的访问令牌，并返回第三方应用所需的相关数据，或返回相关应用业务的结果。

第三方客户端：第三方应用系统通过开放平台入口，访问内部服务，从而完成跨域的业务整合。例如，第三方开发者为新浪微博开放平台开发的应用“新浪微博登陆”，可以使用自己的域名，独立运行在该第三方服务器上，通过远程应用程序编程接口（ApplicationProgramming Interface；API）调用完成业务功能。

授权服务器：开放平台中用于鉴别第三方客户端业务请求及颁布访问令牌的服务器。

资源服务器与授权服务器可以是分离的也可以是一体的。

OAUTH2.0的认证流程请参考图1所示：

步骤A.第三方客户端向资源所有者发送认证请求，请求资源所有者给予授权许可；

步骤B.资源所有者根据实际情况，选择对第三方客户端授权或者不授权，如果授权的话，则返回授权信息给第三方客户端；

步骤C.第三方客户端发送资源所有者的授权信息给授权服务器；

步骤D.授权服务器经过校验后，确认有效，给予访问令牌；

步骤E.第三方客户端利用获得的访问令牌访问资源服务器，获取资源；

步骤F.资源服务器把受保护的资源传送给第三方客户端。

由以上流程可以看出，第三方客户端在不使用用户的用户名与密码就可以申请获得该用户资源的授权。

然而，本发明人在实现本发明实施例中的技术方案的过程中发现，在上述授权访问过程中，第三方客户端可能要与服务提供商进行许多信令交互，例如交互访问协议等；进一步，对于访问同一资源服务器或者同一业务的多个资源的话，就需要资源所有者多次授权，所以就需要第三方客户端和授权服务器之间进行多次交互，所以访问资源的执行和响应时间长。

发明内容

本发明实施例提供一种资源访问方法及用户资源网关，用以解决现有技术中存在的客户端访问资源时客户端与资源服务器或者授权服务器之间信令交互多，所以访问资源的执行和响应时间长的技术问题。

本发明第一方面提供了一种资源访问方法，包括：

用户资源网关URG接收资源所有者发送的资源聚合请求，所述资源聚合请求中包含用户ID和M类业务的资源的资源标识；其中，M为正整数；所述URG基于所述资源聚合请求向与所述M类业务相关的一个或多个授权服务器发送授权请求；所述URG接收所述一个或多个授权服务器基于所述授权请求返回的一个或多个访问令牌；所述一个或多个访问令牌分别与所述M类业务相关联；所述URG存储所述一个或多个访问令牌；当所述URG接收到客户端发送的携带所述用户ID的资源请求时，对所述客户端进行权限验证，并在验证通过后使用所述一个或多个访问令牌中与所请求资源的业务类型相对应的访问令牌从一个或多个资源服务器获取所述资源；所述URG将所述资源发送给所述客户端。

结合第一方面，在第一方面的第一种可能的实现方式中，在所述URG存储所述一个或多个访问令牌之后，还包括：接收所述客户端发送的所述资源请求；所述对所述客户端进行权限验证，包括：所述URG向所述资源所有者发送授权请求；所述URG接收所述资源所有者的授权响应消息，所述授权响应消息表征验证通过。

结合第一方面或第一方面的第一种可能的实现方式，在第一方面的第二种可能的实现方式中，在所述资源请求中包含一个或多个资源ID，并涉及一个或多个资源服务器时，所述使用所述一个或多个访问令牌中与所请求资源的业务类型相对应的访问令牌从一个或多个资源服务器获取所述资源，具体包括：所述URG基于所述一个或多个资源ID生成对应所述一个或多个资源服务器的一个或多个单个资源请求；每个所述单个请求中包含与所请求资源对应的访问令牌；所述URG分别发送所述一个或多个单个资源请求给所述一个或多个资源服务器；所述URG从所述一个或多个资源服务器接收所述一个或多个单个资源请求的一个或多个响应消息，所述一个或多个响应消息中携带与所述一个或多个单个资源请求分别对应的资源。

结合第一方面或第一方面的第一种可能的实现方式或第一方面的第二种可能的实现方式，在第一方面的第三种可能的实现方式中，所述访问令牌在预定时间段内有效，则所述方法还包括：所述URG在所述一个或多个访问令牌超过所述预定时间段后删除所述一个或多个访问令牌；所述URG向所述一个或多个授权服务器发送授权请求。

本发明第二方面提供一种用户资源网关，包括：

第一接收单元，用于接收资源所有者发送的资源聚合请求，所述资源聚合请求中包含用户ID和M类业务的资源的资源标识；其中，M为正整数；第一发送单元，用于基于所述资源聚合请求向与所述M类业务相关的一个或多个授权服务器发送授权请求；第二接收单元，用于接收所述一个或多个授权服务器基于所述授权请求返回的一个或多个访问令牌；所述一个或多个访问令牌分别与所述M类业务相关联；处理单元，用于控制存储所述一个或多个访问令牌；并当所述URG接收到客户端发送的携带所述用户ID的资源请求时，对所述客户端进行权限验证，并在验证通过后使用所述一个或多个访问令牌中与所请求资源的业务类型相对应的访问令牌从一个或多个资源服务器获取所述资源；第二发送单元，用于将所述资源发送给所述客户端。

结合第二方面，在第二方面的第一种可能的实现方式中，所述用户资源网关还包括：第三接收单元，用于接收所述客户端发送的所述资源请求；第三发送单元，用于向所述资源所有者发送授权请求；第四接收单元，用于接收所述资源所有者的授权响应消息；所述处理单元具体用户根据授权响应消息确定验证通过。

结合第二方面或第二方面的第一种可能的实现方式，在第二方面的第二种可能的实现方式中，在所述资源请求中包含一个或多个资源ID，并涉及一个或多个资源服务器时，所述处理单元具体用于基于所述一个或多个资源ID生成对应所述一个或多个资源服务器的一个或多个单个资源请求；每个所述单个请求中包含与所请求资源对应的访问令牌；所述用户资源网关还包括：第四发送单元，用于分别发送所述一个或多个单个资源请求给所述一个或多个资源服务器；第五接收单元，用于从所述一个或多个资源服务器接收所述一个或多个单个资源请求的一个或多个响应消息，所述一个或多个响应消息中携带与所述一个或多个单个资源请求分别对应的资源。

结合第二方面或第二方面的第一种可能的实现方式或第二方面的第二种可能的实现方式，在第二方面的第三种可能的实现方式中，所述访问令牌在预定时间段内有效，所述处理单元还用于在所述一个或多个访问令牌超过所述预定时间段后删除所述一个或多个访问令牌；所述第一发送单元，还用于再向所述一个或多个授权服务器发送授权请求。

本发明第三方面提供一种用户资源网关，包括：

第一接收器，用于接收资源所有者发送的资源聚合请求，所述资源聚合请求中包含用户ID和M类业务的资源的资源标识；其中，M为正整数；第一发送器，用于基于所述资源聚合请求向与所述M类业务相关的一个或多个授权服务器发送授权请求；第二接收器，用于接收所述一个或多个授权服务器基于所述授权请求返回的一个或多个访问令牌；所述一个或多个访问令牌分别与所述M类业务相关联；处理器，用于控制存储所述一个或多个访问令牌；并当所述URG接收到客户端发送的携带所述用户ID的资源请求时，对所述客户端进行权限验证，并在验证通过后使用所述一个或多个访问令牌中与所请求资源的业务类型相对应的访问令牌从一个或多个资源服务器获取所述资源；第二发送器，用于将所述资源发送给所述客户端。

结合第三方面，在第三方面的第一种可能的实现方式中，所述用户资源网关还包括：第三接收器，用于接收所述客户端发送的所述资源请求；第三发送器，用于向所述资源所有者发送授权请求；第四接收器，用于接收所述资源所有者的授权响应消息；所述处理器具体用户根据授权响应消息确定验证通过。

结合第三方面或第三方面的第一种可能的实现方式，在第三方面的第二种可能的实现方式中，在所述资源请求中包含一个或多个资源ID，并涉及一个或多个资源服务器时，所述处理器具体用于基于所述一个或多个资源ID生成对应所述一个或多个资源服务器的一个或多个单个资源请求；每个所述单个请求中包含与所请求资源对应的访问令牌；所述用户资源网关还包括：第四发送器，用于分别发送所述一个或多个单个资源请求给所述一个或多个资源服务器；第五接收器，用于从所述一个或多个资源服务器接收所述一个或多个单个资源请求的一个或多个响应消息，所述一个或多个响应消息中携带与所述一个或多个单个资源请求分别对应的资源。

结合第三方面或第三方面的第一种可能的实现方式或第三方面的第二种可能的实现方式，在第三方面的第三种可能的实现方式中，所述访问令牌在预定时间段内有效，所述处理器还用于在所述一个或多个访问令牌超过所述预定时间段后删除所述一个或多个访问令牌；所述第一发送器，还用于再向所述一个或多个授权服务器发送授权请求。

本发明第四方面还提供一种资源访问方法，包括：

用户资源网关URG接收客户端发送的资源请求；其中，所述资源请求中包含一个或多个资源ID，每个所述资源ID对应一个资源；所述URG对所述客户端进行权限验证；所述URG在验证通过后基于所述一个或多个资源ID生成对应所述一个或多个资源服务器的一个或多个单个资源请求；每个所述单个资源请求中包含与所请求资源对应的访问令牌，所述访问令牌表征资源所有者允许所述URG访问所述资源；所述URG分别发送所述一个或多个单个资源请求给所述一个或多个资源服务器；所述URG从所述一个或多个资源服务器接收所述一个或多个单个资源请求的一个或多个响应消息，所述一个或多个响应消息中携带与所述一个或多个单个资源请求对应的资源；所述URG将所述资源发送给所述客户端。

结合第四方面，在第四方面的第一种可能的实现方式中，所述URG对所述客户端进行权限验证，包括：所述URG向所述资源所有者发送授权请求；所述URG接收所述资源所有者的授权响应消息，所述授权响应消息表征验证通过。

结合第四方面，在第四方面的第二种可能的实现方式中，所述资源请求中携带访问标识，所述访问标识表征所述资源所有者允许所述客户端访问所述资源，所述URG对所述客户端进行权限验证，包括：所述URG基于所述访问标识对所述客户端进行权限验证。

结合第四方面的第二种可能的实现方式中，在第四方面的第三种可能的实现方式中，在所述用户资源网关URG接收客户端发送的资源请求之前，还包括：所述URG接收客户端发送的授权请求，请求授权访问所述资源；所述URG向所述资源所有者发送授权请求；所述URG接收所述资源所有者的授权响应消息；所述URG基于所述授权响应消息分配所述访问标识给所述客户端。

结合第四方面的第三种可能的实现方式中，在第四方面的第四种可能的实现方式中，在所述URG基于所述授权响应消息分配所述访问标识给所述客户端之前，还包括：所述URG接收所述资源所有者发送的资源聚合请求，所述资源聚合请求中包含用户ID和所述资源的标识；所述URG基于所述资源聚合请求向与所述资源所属业务相关的授权服务器发送授权请求；所述URG接收所述授权服务器返回的与所述业务相关联的所述访问令牌。

结合第四方面或第四方面的第一种可能的实现方式或第四方面的第四种可能的实现方式中的任意一种，在第四方面的第五种可能的实现方式中，在所述URG将所述资源发送给所述客户端之前，还包括：所述URG转换并合并每个所述资源服务器的响应消息；所述URG将所述资源发送给所述客户端具体为：所述URG将转换并合并后的响应消息发送给所述客户端。

结合第四方面或第四方面的第一种可能的实现方式或第四方面的第五种可能的实现方式中的任意一种，在第四方面的第六种可能的实现方式中，在所述用户资源网关URG接收客户端发送的资源请求之前，还包括：所述URG针对所述资源服务器所发布的业务的所述资源的URL，去掉域和协议相关的参数，关联所述业务的应用程序编程接口API的名字生成所述资源ID；所述URG发布所述资源ID。

结合第四方面或第四方面的第一种可能的实现方式或第四方面的第六种可能的实现方式中的任意一种，在第四方面的第七种可能的实现方式中，所述访问令牌在预定时间段内有效，所述方法还包括：所述URG在所述访问令牌超过所述预定时间段内后删除所述访问令牌；所述URG再向与所述资源所属业务相关的授权服务器发送授权请求。

本发明第五方面还提供一种用户资源网关，包括：

第一接收单元，用于接收客户端发送的资源请求；其中，所述资源请求中包含一个或多个资源ID，每个所述资源ID对应一个资源；处理单元，用于对所述客户端进行权限验证；并在验证通过后基于所述一个或多个资源ID生成对应所述一个或多个资源服务器的一个或多个单个资源请求；每个所述单个资源请求中包含与所请求资源对应的访问令牌，所述访问令牌表征资源所有者允许所述URG访问所述资源；第一发送单元，用于分别发送所述一个或多个单个资源请求给所述一个或多个资源服务器；第二接收单元，用于从所述一个或多个资源服务器接收所述一个或多个单个资源请求的一个或多个响应消息，所述一个或多个响应消息中携带与所述一个或多个单个资源请求对应的资源；第二发送单元，用于将所述资源发送给所述客户端。

结合第五方面，在第五方面的第一种可能的实现方式中，所述用户资源网关还包括：第三发送单元，用于向所述资源所有者发送授权请求；第三接收单元，用于接收所述资源所有者的授权响应消息；所述处理单元用于根据授权响应消息确定验证通过。

结合第五方面，在第五方面的第二种可能的实现方式中，所述资源请求中携带访问标识，所述访问标识表征所述资源所有者允许所述客户端访问所述资源，所述处理单元具体用于基于所述访问标识对所述客户端进行权限验证。

结合第五方面的第二种可能的实现方式，在第五方面的第三种可能的实现方式中，所述用户资源网关还包括：第四接收单元，用于在所述第一接收单元接收客户端发送的资源请求之前，接收客户端发送的授权请求，请求授权访问所述资源；第四发送单元，用于向所述资源所有者发送授权请求；第五接收单元，用于接收所述资源所有者的授权响应消息；所述处理单元用于基于所述授权响应消息分配所述访问标识给所述客户端。

结合第五方面的第三种可能的实现方式，在第五方面的第四种可能的实现方式中，所述用户资源网关还包括：第六接收单元，用于接收所述资源所有者发送的资源聚合请求，所述资源聚合请求中包含用户ID和所述资源的标识；第五发送单元，用于基于所述资源聚合请求向与所述资源所属业务相关的授权服务器发送授权请求；第七接收单元，用于接收所述授权服务器返回的与所述业务相关联的所述访问令牌。

结合第五方面或第五方面的第一种可能的实现方式至第五方面的第四种可能的实现方式中的任意一种，在第五方面的第五种可能的实现方式中，所述处理单元还用于转换并合并每个所述资源服务器的响应消息；所述第二发送单元具体用于将转换并合并后的响应消息发送给所述客户端。

结合第五方面或第五方面的第一种可能的实现方式至第五方面的第五种可能的实现方式中的任意一种，在第五方面的第六种可能的实现方式中，所述处理单元具体还用于针对所述资源服务器所发布的业务的所述资源的URL，去掉域和协议相关的参数，关联所述业务的应用程序编程接口API的名字生成所述资源ID；并发布所述资源ID。

结合第五方面或第五方面的第一种可能的实现方式至第五方面的第六种可能的实现方式中的任意一种，在第五方面的第七种可能的实现方式中，所述访问令牌在预定时间段内有效，所述处理单元具体还用于在所述访问令牌超过所述预定时间段内后删除所述访问令牌；所述用户资源网关还包括：第六发送单元，用于再向与所述资源所属业务相关的授权服务器发送授权请求。

本发明第六方面还提供一种用户资源网关，包括：

接收器，用于接收客户端发送的资源请求；其中，所述资源请求中包含一个或多个资源ID，每个所述资源ID对应一个资源；并从一个或多个资源服务器接收一个或多个单个资源请求的一个或多个响应消息，所述一个或多个响应消息中携带与所述一个或多个单个资源请求对应的资源；处理器，用于对所述客户端进行权限验证，并在验证通过后基于所述一个或多个资源ID生成对应所述一个或多个资源服务器的一个或多个单个资源请求；每个所述单个资源请求中包含与所请求资源对应的访问令牌，所述访问令牌表征资源所有者允许所述URG访问所述资源；发送器，用于发送所述一个或多个单个资源请求给所述一个或多个资源服务器，并将所述资源发送给所述客户端。

结合第六方面，在第六方面的第一种可能的实现方式中，所述发送器具体还用于向所述资源所有者发送授权请求；所述接收器还用于接收所述资源所有者的授权响应消息；所述处理器基于所述授权响应消息确定验证通过。

结合第六方面，在第六方面的第二种可能的实现方式中，所述资源请求中携带访问标识，所述访问标识表征所述资源所有者允许所述客户端访问所述资源，所述处理器具体用于基于所述访问标识对所述客户端进行权限验证。

结合第六方面的第二种可能的实现方式，在第六方面的第三种可能的实现方式中，在所述接收器接收客户端发送的资源请求之前，所述接收器还用于接收客户端发送的授权请求，请求授权访问所述资源；所述发送器还用于向所述资源所有者发送授权请求；所述接收器还用于接收所述资源所有者的授权响应消息；所述处理器还用于基于所述授权响应消息分配所述访问标识给所述客户端。

结合第六方面的第三种可能的实现方式，在第六方面的第四种可能的实现方式中，在所述处理器基于所述授权响应消息分配所述访问令牌给所述客户端之前，所述接收器还用于接收所述资源所有者发送的资源聚合请求，所述资源聚合请求中包含用户ID和所述资源的标识；所述发送器还用于基于所述资源聚合请求向与所述资源所属业务相关的授权服务器发送授权请求；所述接收器还用于接收所述授权服务器返回的所述访问令牌。

结合第六方面或第六方面的第一种可能的实现方式或第六方面的第四种可能的实现方式中的任意一种，在第六方面的第五种可能的实现方式中，所述处理器还用于转换并合并每个所述资源服务器的响应消息；所述发送器具体用于将转换并合并后的响应消息发送给所述客户端。

结合第六方面或第六方面的第一种可能的实现方式或第六方面的第五种可能的实现方式中的任意一种，在第六方面的第六种可能的实现方式中，所述处理器还用于在所述接收器接收客户端发送的资源请求之前，针对所述资源服务器所发布的业务的所述资源的URL，去掉域和协议相关的参数，关联所述业务的应用程序编程接口API的名字生成所述资源ID；发布所述资源ID。

结合第六方面或第六方面的第一种可能的实现方式或第六方面的第六种可能的实现方式中的任意一种，在第六方面的第七种可能的实现方式中，所述访问令牌在预定时间段内有效；所述处理器还用于在所述访问令牌超过所述预定时间段内后删除所述访问令牌；所述发送器还用于再向与所述资源所属业务相关的授权服务器发送授权请求。

本发明实施例中提供的一个或多个技术方案，至少具有如下技术效果或优点：

在本发明一实施例中，用户资源网关URG接收资源所有者发送的资源聚合请求，资源聚合请求中包含用户ID和M类业务的资源的标识；其中，M为正整数；URG基于资源聚合请求向与M类业务相关的一个或多个授权服务器发送授权请求；URG接收一个或多个授权服务器基于授权请求返回的一个或多个访问令牌；所述一个或多个访问令牌分别与M类业务相关联；URG存储所述一个或多个访问令牌；当URG接收到客户端发送的携带用户ID的资源请求时，对客户端进行权限验证，并在验证通过后使用所述一个或多个访问令牌中与所请求资源的业务类型相对应的访问令牌从资源服务器获取资源；URG将资源发送给客户端。即在本实施例中，先在URG聚合资源，URG获得对这些资源的访问令牌，当客户端向URG请求资源时，URG先对客户端进行验证，在验证通过后就由URG使用之前获得的访问令牌去资源服务器请求资源，然后将请求到的资源返回给客户端，所以客户端不需要与资源服务器做信令交互，按照不同资源服务器的格式访问资源服务器；进一步，在本实施例中，访问令牌与业务相关联，所以客户端可以在一个请求中请求同一业务下的多个资源，而只需要一次权限验证，就可以访问多个资源，所以客户端也不需要进行多次授权的信令交互，所以在本实施例中，客户端在访问资源的过程中，只需要做少量交互就可实现资源访问，即简化了客户端的交互，所以缩短了访问资源的执行和响应时间。

附图说明

图1为现有技术中的授权访问的流程交互示意图；

图2为本申请一实施例中的各逻辑功能实体的示意图；

图3为本申请一实施例中的各逻辑功能实体的实际部署图；

图4本申请一实施例中的注册、授权、访问资源的逻辑流程图；

图5a-图5b本申请一实施例中的注册资源的流程示意图；

图6a-图6c为本申请一实施例中的授权访问资源的流程示意图；

图7为本申请一实施例中的用户资源网关的功能框图；

图8为本申请一实施例中的用户资源网关的硬件实现示例的概念图；

图9为本申请一实施例中的用户资源网关的另一硬件实现示例的概念图；

图10a-图10b为本申请一实施例中注册资源的具体实例的流程示意图；

图11a-图11b为本申请一实施例中授权访问资源的具体实例的流程示意图。

具体实施方式

本发明实施例提供一种资源访问方法及用户资源网关，用以解决现有技术中存在的客户端访问资源时客户端与资源服务器或者授权服务器之间信令交互多，所以访问资源的执行和响应时间长的技术问题。

本发明实施例中的技术方案为解决上述的技术问题，总体思路如下：

在本发明一实施例中，用户资源网关（User Resource Gateway；URG）接收资源所有者发送的资源聚合请求，资源聚合请求中包含用户ID和M类业务的资源的标识，所述资源的标识具体可以是资源名称或资源存储地址；其中，M为正整数；URG基于资源聚合请求向与M类业务相关的一个或多个授权服务器发送授权请求；URG接收一个或多个授权服务器基于授权请求返回的一个或多个访问令牌；所述一个或多个访问令牌分别与M类业务相关联；URG存储所述一个或多个访问令牌；当URG接收到客户端发送的携带用户ID的资源请求时，对客户端进行权限验证，并在验证通过后使用所述一个或多个访问令牌中与所请求资源的业务类型相对应的访问令牌从资源服务器获取资源；URG将资源发送给客户端。即在本实施例中，先在URG聚合资源，URG获得对这些资源的访问令牌，当客户端向URG请求资源时，URG先对客户端进行验证，在验证通过后就由URG使用之前获得的访问令牌去资源服务器请求资源，然后将请求到的资源返回给客户端，所以客户端不需要与资源服务器做信令交互，按照不同资源服务器的格式访问资源服务器；进一步，在本实施例中，访问令牌与业务相关联，所以客户端可以在一个请求中请求同一业务下的多个资源，而只需要一次权限验证，就可以访问多个资源，所以客户端也不需要进行多次授权的信令交互，所以在本实施例中，客户端在访问资源的过程中，只需要做少量交互就可实现资源访问，即简化了客户端的交互，所以缩短了访问资源的执行和响应时间。

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

为了便于方便了解本申请的技术方案，以下先介绍本申请实施例中资源授权访问系统的构成。

请参考图2所示，本实施例中的资源授权访问系统包括以下逻辑功能实体：

资源所有者：资源所有者可以基于授权，在其可信任的用户资源网关上聚合来自多个不同服务提供商的资源。其中1：n表示一个资源所有者可以拥有n个资源，n为正整数；资源所有者还可以授权用户资源网关和客户端访问这n个资源，对于每一个资源的处理方式均相同。资源使用者进一步可以使用客户端。

资源服务器：托管资源所有者的资源，并能够接受和响应使用访问令牌方式的单个资源请求。其中，1：x表示一个资源所有者的资源可能分布在x个资源服务器上面。

客户端：一个应用程序，代表资源所有者发起资源请求，其授权方式也是使用访问令牌。术语“客户端”并不意味着任何特定的实现特征（例如可以是执行在服务器上，桌面设备或其他设备的应用程序）。客户端能够使用用户资源网关为客户端生成的API接口向用户资源网关发送资源请求，从用户资源网关获取用户资源，其中，该资源可以是由不同的服务提供商提供。当获取到资源后可以将资源通过客户端界面展示给资源所有者。

授权服务器：用户资源网关成功获得资源所有者的验证授权后，授权服务器负责分发访问令牌。

用户资源网关URG：能够支持单点访问客户端聚合的所有资源，能够提供单点授权访问资源所有者的全部资源，能够自动生成优化资源获取访问操作的API接口，简化客户端的操作。还能够协助授权服务器在资源服务器和客户端成功验证和获得用户授权之后，生成和更新访问令牌。URG与授权服务器交互实现访问令牌生命周期管理。在URG的协助下能够响应客户端提供基于访问令牌方式的资源请求，提供给客户端来自不同资源服务器的聚合资源，即返回资源请求的响应。URG还能够指定和管理基于一个应用程序的多种资源的授权控制。

进一步，各逻辑功能实体在实际部署时，可以合并也可以单独存在，例如授权服务器和资源服务器可以是单独的，也可以是在同一台服务器上。授权服务器和资源服务器之间具有互信的机制，所以不需要授权验证，而用户资源网关和资源所有者之间也可具有互信的机制，资源所有者和用户资源网关之间的操作无需验证授权。

请再参考图3所示，为图2中各逻辑功能实体的实际部署图，图3是以下一代业务叠加网络（Next Generation Service Overlay Network；NGSON）网络为例，NGSON仅以包括URG为例进行说明，在实际运用中，还包括业务目录、业务组合等。

其中，在图3中，R表示分布在信息技术（Information Technology；IT）网络和信息通信技术（Information Communication Technology；ICT）网络中的各种资源；App是应用程序：应用程序可以是在应用程序商店中，包括但不限于电信运营商提供的应用，还包括第三方的应用。资源所有者和资源R之间的连线表示资源所有者与资源的归属关系，URG与资源R之间的连线，例如：从一个URG出发，连接到三个资源R，表示URG为所聚合的三个资源提供单点访问，即通过一次授权，就可以访问所聚合的这三个资源。资源所有者与URG之间的连线表示资源所有者与用户资源网关的信令交互，包括：资源授权，应用程序访问等，后续章节有详细描述。资源所有者？与APP之间的连线表示资源所有者使用应用程序，App到业务叠加网络的箭头表示应用程序使用例如OAUTH2.0协议通过业务叠加网络访问资源。

接下来将描述本申请实施例中资源授权访问系统的实施流程，请参考图4所示，该流程包括：

在步骤101中，资源所有者在URG中注册资源所有者的业务的资源。

在步骤102中，URG为每个业务创建统一资源访问API，为每个资源分配全局唯一的资源ID。

在步骤103中，URG发布资源ID和统一资源访问API。

在步骤104中，应用程序开发者使用URG所发布的统一资源访问API开发应用程序，获得客户端。

在步骤105中，用户调用或者启动客户端。

在步骤106中，客户端通过URG访问资源服务器上的资源。

以下先来描述步骤101中注册资源的详细过程，请先参考图5a所示，为URG侧的方法流程图。请参考图5a，该方法包括：

在步骤1011中，URG接收资源所有者发送的资源聚合请求；资源聚合请求中包含用户ID和M类业务的资源的标识，所述资源的标识具体可以是资源名称或资源存储地址；其中，M为正整数。

在步骤1012中，URG基于资源聚合请求向与M类业务相关的一个或多个授权服务器发送授权请求。

在步骤1013中，URG接收一个或多个授权服务器基于授权请求返回的一个或多个访问令牌，一个或多个访问令牌分别与M类业务相关联。

请同时参考图5b所示，图5b为图5a中方法流程的各功能实体的交互流程图。其中，进一步，在步骤1011之前，步骤101还包括：URG接收资源所有者发送的资源所有者注册请求；URG在接收到该请求时，回复所有者资格证书给资源所有者，其中该步骤可以表示URG对注册请求的回复,同时也表示可以进行下一步操作，也可以表示返回用户所拥有的资源列表，也可以表示用户发起注册所需要的授权文件，也可以表示对资源所有者资格的认证通过。如图5b中所示的步骤201和步骤202。

然后执行步骤203，即资源所有者发送资源聚合请求给URG，那么对应的，URG即执行步骤1011，接收资源所有者发送的资源聚合请求，资源聚合请求中包含用户ID和M类业务的资源的标识，所述资源的标识具体可以是资源名称或资源存储地址，资源存储地址例如为资源的原始URL，或者是在资源服务器上的存储地址。M类业务例如为Twitter和Facebook两类业务。资源分别是每类业务的至少一个资源，例如有两个资源的资源名称，Twitter业务的好友列表资源和Facebokk业务的好友列表资源。其中，用户ID是从技术实现上代表资源所有者。

在实际运用中，在资源聚合请求中还可以包括资源对应的数据的类型，例如：“一般”或者“安全”。然后URG在接收到资源聚合请求后，就执行步骤1012，向与M类业务相关的一个或多个授权服务器发送授权请求，对应于图5b中的步骤204，在该步骤中，具体可以采用OAUTH协议发送授权请求。其中，与M类业务相关的一个或多个授权服务器，视实际授权服务器和业务之间的对应关系而决定，例如继续以前述例子为例进行说明，假设在实际部署中，Twitter业务有专属的授权服务器，Facebook业务也有自己专属的授权服务器，那么在步骤1012中就向Twitter业务有专属的授权服务器发送针对Twitter业务的授权请求，向Facebook业务专属的授权服务器发送针对Facebook业务的授权请求。当在实际部署中，这两个业务使用相同的授权服务器，那么就向该相同的授权服务器发送针对这两类业务的授权请求。

在每个授权服务器接收到授权请求后，就执行步骤205，即发送授权界面给资源所有者，授权界面例如：包括登录和授权两个部分，具体可以由对应业务的App界面来呈现。然后资源所有者执行步骤206，即登录并授权URG的访问；对应的，每个授权服务器就接收到资源所有者的登录和授权响应，如果授权成功获得，那么授权服务器就执行步骤207，即生成一个访问令牌给URG，那么对应M个业务类型，就会对应有一个或多个访问令牌，在实际运用中，具体可以是每个业务类型对应一个访问令牌，也可以是一个业务类型对应多个访问令牌，其中，该访问令牌在一个预定的时间段内有效，例如：一个月，一年，每个访问令牌的有效时间段可以不完全相同。那么对应的，URG即执行步骤1013，即URG接收一个或多个授权服务器基于授权请求返回的一个或多个访问令牌。

进一步，URG还存储该一个或多个访问令牌。

在进一步的实施例中，在URG获得访问令牌后，还可以事先去资源服务器请求资源并缓存在本地，如此一来，当有客户端请求资源时，可以直接从本地获取资源返回，所以进一步缩短了客户端访问资源的响应时间。因此，在步骤207或步骤1013之后，还可以包括：URG发送携带访问令牌的资源请求给资源服务器（请参考图5b中的步骤208），然后URG接收资源服务器基于该资源请求返回的所请求资源；URG将所请求资源中符合预定条件的数据缓存在本地（请参考图5b中的步骤209），其中预定条件可以是步骤203中资源聚合请求携带的资源对应的数据的某种类型，例如：“安全”类型；在实际运用中，预定条件还可以为以下一种或任意组合：资源的请求频率超过预定值、资源对应的数据的敏感度超过预定值，资源对应的数据的隐私度超过预定值。

请再参考图5b所示，因为同一个资源所有者，可能拥有多个服务提供商的资源，一个授权服务器加资源服务器或一个资源服务器，或一个授权服务器可以看做是一个服务提供商，一个服务提供商对应于一个业务，因为是以每个业务分类进行聚合资源，所以步骤203中的一个资源聚合请求针对同一个业务的不同资源，从步骤203至步骤209针对每一个业务而言都是同样的流程，只是所请求聚合的资源是不同的服务提供商的资源，所以需要注册几个业务的资源，就在步骤202后，重复执行几遍步骤203至步骤209即可，所以在此不再重复，例如：要注册两个业务的资源，那么就执行两遍步骤203至步骤209。当然在实际运用中，也可以是在同一个资源聚合请求中包含两类或两类以上的业务的资源。

如果URG还未给注册的业务创建统一资源访问API，或者还未给需要聚合的资源分配资源ID，那么接下来就执行步骤102，URG为每个业务创建统一资源访问API，为每个资源分配全局唯一的资源ID，当然，创建统一资源访问API的过程和分配资源ID的过程可以不是同时执行的。进一步，为每个资源分配资源ID和创建统一资源访问API的步骤可以在步骤101之前执行。

首先介绍如何分配资源ID，具体来说，URG针对资源服务器所发布的业务的资源的URL（Uniform Resource Locator；统一资源定位符）或者是资源聚合请求中携带的资源的URL，去掉域和协议相关的参数，关联该业务的API的名字生成资源ID。

举例来说，例如：对于业务xyz的资源“好友名称”，资源服务器发布的资源的URL为http://api.xyz.com/friends/getNames，那么URG就去掉域（api.xyz.com）和协议相关的参数（(http://），关联该业务的API的名字（xyzAPI）生成全局唯一资源ID，例如：为xyzAPI-friends-Names。正因为资源ID是全局唯一的，资源响应能够在URG本地以键值对的形式缓存，例如：资源ID是键，资源响应是值。URG能够使用资源ID作为搜索关键字获取本地存储的资源，而且URG能够访问任何使用资源ID为索引键的存储资源。

再例如：对应于http://api.xyz.com/self/activities的资源的资源ID为xyzAPI-self-activities，对应于http://api.xyz.com/self/messages的资源的资源ID为xyzAPI-self-messages。

其次，针对每个业务创建统一资源访问API，例如：业务xyz的API名称为xyzAPI，那么在统一资源访问API的接口描述里，对应于资源ID为xyzAPI-self-activities和xyzAPI-self-messages的统一资源访问API被描述为xyzAPI-self-activities to update selfactivities（更新自己动态）和xyzAPI-self-messages to update a message（更新自己信息）。

其中，统一资源访问API包含了资源名称，即资源ID，和操作方式，操作方式例如：为Get（获取）、Post（更新）、Delete（删除）和Add（增加）。

然后统一资源访问API和资源ID被发布出来，即执行步骤103，例如：发布在NGSON网络的业务目录中。

然后执行步骤104，应用程序开发者使用统一资源访问API开发应用程序，例如：在客户端开发的阶段就内嵌了统一资源访问API，这部分为本领域技术人员所熟知的内容，所以在此不再赘述。

当应用程序被开发出来，就可以被使用，例如：用户或者资源所有者调用启动该客户端，即执行步骤105。当URG接收到客户端发送的携带用户ID的资源请求时，对客户端进行权限验证，并在验证通过后使用一个或多个访问令牌中与所请求资源的业务类型相对应的访问令牌从资源服务器获取资源；然后URG将资源发送给客户端。即执行步骤106，即客户端通过URG访问资源服务器上的资源，以下将详细描述步骤106的实施过程。

请同时参考图6a和图6b所示，图6a为客户端获得资源所有者的授权的方法流程图，图6b为步骤105和步骤106中方法流程的各功能实体的交互图。

如图6a所示，该授权的方法包括：

在步骤1061中，URG接收客户端发送的授权请求，请求授权访问资源；

在步骤1062中，URG向资源所有者发送授权请求。

在步骤1063中，URG接收资源所有者的授权响应消息。

在步骤1064中，URG基于授权响应消息分配访问标识给客户端。

请同时参考图6b所示，客户端发送授权请求（请参考图6b中的步骤301）给URG，对应的，URG执行步骤1061，即接收客户端发送的授权请求。当URG接收到授权请求时，URG就执行步骤1062，即向资源所有者发送授权请求（请参考图6b中的步骤302），具体可以通过App的界面实现，请求资源所有者登录和授权客户端的访问。然后资源所有者登录和授权该客户端的访问，然后向URG发送授权响应消息（请参考图6b中的步骤303），那么对应的，URG就执行步骤1063，即接收资源所有者的授权响应消息。

当URG接收到授权响应消息，URG就执行步骤1064，即分配与该资源所属业务的访问标识给客户端（请参考图6b中的步骤304），访问标识表征资源所有者允许客户端访问资源，其中，该访问标识和该所属业务的访问令牌在技术实现上可以相同也可以不同；进一步，因为访问标识在一预定时间段内有效，所以步骤1061至步骤1064（图6a），步骤301至步骤304（图6b）不需要每次客户端访问资源时都执行，当访问标识失效之后可以再重复执行，进而获得新的访问令牌，所以可以进一步提高访问资源的响应速度，缩短了响应时间。

进一步，URG该访问标识的有效时间和该所属业务的访问令牌的有效时间可以相同也可以不相同，例如：两者的有效时间均为一个月；还可以是该访问标识的有效时间是依赖于该所属业务的访问令牌的剩余有效时间，例如：该所属业务的访问令牌的有效时间为一个月，在分配访问标识给客户端时，剩余有效时间为半个月，那么该访问标识的有效时间就为半个月。

当通过步骤1061至步骤1064获得访问标识时或者现有的访问标识还有效时或者还未获得访问标识时，接下来请再参考图6c所示，即进行访问资源的方法流程，该方法包括：

在步骤1065中，URG接收客户端发送的资源请求；其中，资源请求中包含所一个或多个资源ID，每个资源ID对应一个资源。

在步骤1066中，URG对客户端进行权限验证。

在步骤1067中，URG在验证通过后基于一个或多个资源ID生成对应一个或多个资源服务器的一个或多个单个资源请求；每个单个资源请求中包含与所请求资源对应的访问令牌；访问令牌表征资源所有者允许URG访问该资源。

在步骤1068中，URG分别发送一个或多个单个资源请求给对应的资源服务器。

在步骤1069中，URG从对应的资源服务器接收一个或多个单个资源请求的一个或多个响应消息，一个或多个响应消息中携带与一个或多个单个资源请求对应的资源。

在步骤1070中，URG将该资源发送给客户端。

请同时参考图6b所示，其中在步骤1065中（请参考图6b中的步骤305），例如：统一资源访问API的名字为xyzAPI，那么利用API的名字构造URG的统一资源访问URL例如：为http://<URG broker address>/xyzAPI/，客户端调用该API，将所请求资源的资源ID作为参数分别在各自的统一资源访问URL中传递，以资源ID关联，例如：将资源ID xyzAPI-friends-Names和xyzAPI-self-activities作为参数在两者的统一资源访问URL中传递，获得第一资源请求，在第一资源请求中携带URL：http://<URG broker address>/xyzAPI?resourceIDs=xyzAPI-friends-names，xyzAPI-self-activities。当然，在实际运用中，也可以利用应用的关键字，应用的属性，应用的提供商名称来构造URG的统一资源访问URL。

当然，在实际运用中，第一资源请求中携带资源ID可以不限于是URL，也可以采用其他协议工具，例如：XML（可扩展标记语言）、JSON（JavaScript Object Notation；数据交换格式）、SOAP（Simple Object Access Protocol；简单对象访问协议）和Custom XML（自定XML）。例如：客户端访问URL http://<URG broker address>/xyzAPI，然后对这两个资源ID对应资源的资源请求被转换为Custom XML格式并在各自的资源ID中合并，那么第一资源请求中就会携带<xyzAPI><request><xyzAPI-self-activities><activities><activity>[activity]</activity></activities></xyzAPI-self-activities><xyzAPI-friends-names><names><name>[name]<name></names></xyzAPI-friends-names></request></xyzAPI>。

接下来执行步骤1066，URG对客户端进行权限验证，在实际运用中，可以有但不限于有两种方式进行验证，第一种例如客户端通过如图6a中的方式获得了访问标识，那么在资源请求中就携带有访问标识，以表征客户端的该访问操作已经资源所有者授权，那么URG就根据该访问标识对客户端进行验证，例如检测资源请求中已包含访问标识且该访问令牌有效，那么就确定验证通过。

第二种，资源请求中并非包含访问标识或者访问标识已经失效，那么URG在执行步骤1065之后，就向资源所有者发送授权请求，资源所有者登录并授权后，URG就接收到资源所有者的授权响应消息，表示资源所有者允许客户端访问该资源，所以表征验证通过。

当URG验证通过后，可选的，还包括确定本地没有缓存资源ID对应的资源的步骤，如在前述描述资源聚合的过程中所描述的，URG可以根据预定条件在本地缓存资源，那么在资源访问的过程中，当URG接收到资源请求后，可以先利用资源ID检索本地是否缓存有对应的资源，如果本地缓存有资源ID对应的资源，那么URG就可以直接从本地返回资源给客户端（如图6b中的步骤306所示），如此一来，可以提高响应效率，并且也省去了URG和资源服务器的信令交互，所以可以节约带宽资源。

然而当确定本地没有缓存资源ID对应的资源或者在步骤1066之后，就直接执行步骤1067，即基于一个或多个资源ID生成对应一个或多个资源服务器对应的一个或多个单个资源请求，其中，每个单个资源请求中包含与所请求资源对应的访问令牌，访问令牌表征资源所有者允许URG访问该资源。继续以前述实例为例进行说明，URG解析出资源请求中携带的两个资源ID，例如为xyzAPI-friends-Names和xyzAPI-self-activities，并且同为业务xyz的资源的资源ID，如果资源请求具体为URL格式的请求，那么URG就可以基于资源ID和资源标识，所述资源的标识具体可以是资源名称或资源存储地址（例如资源的URL）之间的对应关系，获得与资源ID对应的原始存储地址（例如元素URL），然后基于原始存储地址，获得一个或多个单个资源请求，每个单个资源请求中包含与业务xyz对应的访问令牌；具体来说，例如使用键值对映射资源ID到提供的资源URL，获得两个URL，分别为http://api.xyz.com/friends/names和http://api.xyz.com/self/activities，基于这两个URL，就可以获得两个单个资源请求（请参考图6b所示的步骤307）。进一步，还可以将单个URL转换为其他协议格式，例如Custom XML格式，那么就会获得两个Custom XML格式的请求，分别为<activities><activity>[activity]</activity></activities>，{"names":[{"name":"[name]"}]}。

而当资源请求的请求格式为Custom XML格式的，那么分解后的单个资源请求为<activities><activity>[activity]</activity></activities>，{"names":[{"name":"[name]"}]}，当然也可以进一步转换为其他格式的，例如URL格式。

进一步，基于一个或多个资源ID生成一个或多个单个资源请求，在具体的数量对应上，可以是基于一个资源ID生成一个单个资源请求；如果所请求资源均在一个资源服务器上，那么基于多个资源ID可以生成一个单个资源请求；如果一个资源ID对应的资源分布在不同的资源服务器上，那么可以基于一个资源ID生成对应于不同的资源服务器的多个单个资源请求。

然后URG执行步骤1068，发送一个或多个单个资源请求给对应的资源服务器（请参考图6b所示的步骤308），同样，访问令牌在一定时间段内有效，所以在访问令牌的有效期内可以多次访问该资源而无需多次授权，而当访问令牌无效时，可以按照前述描述的授权流程再次获得授权，获得访问令牌。其中，对应的资源服务器取决于所请求资源存储在哪些资源服务器上，资源存储在哪些资源服务器上，就向哪些资源服务请求资源。

接下来，请参考图6b所示，在步骤308中发送单个资源请求给资源服务器后，资源服务器如果存储有单个资源请求对应的资源，就执行步骤309，返回响应消息给URG，那么对应的，URG就执行步骤1069，从资源服务器接收一个或多个单个资源请求的一个或多个响应消息，一个或多个响应消息中携带一个或多个单个资源请求对应的资源。通常来讲，一个单个资源请求对应一个响应消息，但是也不排除多个单个资源请求对应一个响应消息的情况，或者是一个单个资源请求对应多个响应消息的情况。

在接收到所请求的资源后，URG就执行步骤1070，将所请求资源发送给客户端，可选的，在步骤1070之前还包括：转换并合并每个资源服务器的响应消息（请参考图6b中的步骤310），具体来说，转换是指将响应消息进行格式转换，例如在XML、JSON、SOAP、URL和Custom XML（自定XML）之间互相转换，当然也可以采用其他协议工具。那么步骤1070具体为：URG将转换并合并后的响应消息发送给客户端（请参考图6b中的步骤311）。

举例来说，对应于单个资源请求http://api.xyz.com/friends/names的响应消息是XML格式的{"names":[{"name":"value"}]}，对应于单个资源请求http://api.xyz.com/self/activities的响应请求是XML格式的<activities><activity>[activity]</activity></activities>，那么URG转换并合并每个响应消息为JSON格式的响应消息，<xyzAPI><response><xyzAPI-friends-names><json><names><name>value</name></names></json></xyzAPI-friends-names><xyzAPI-self-activities>

<activities><activity>[activity]</activity></activities></xyzAPI-self-activities></response></xyzAPI>。然后将转换并合并后的响应消息发送给客户端。

需要说明的是，在图6b中，从步骤301至步骤311对于每一个客户端而言均是相似的流程，所以在此就不再重复描述。

由以上可以看出在本实施例中，由用户资源网关做代理，在接收到客户端发送的资源请求后对客户端进行权限验证，确定资源所有者是否允许客户端访问该资源，如果验证通过，就由用户资源网关根据资源ID分解成针对每个资源服务器的单个资源请求去向资源服务器请求资源，然后将请求到的资源返回给客户端，所以客户端不需要与资源服务器做信令交互，按照不同资源服务器的格式访问资源服务器；进一步，在本实施例中，访问令牌和资源所属业务相关联，所以一个资源请求可以同时请求该业务的多个资源，也就是说，客户端在通过一次授权之后，就可以访问同一业务的多个资源，所以客户端也不需要进行多次授权的信令交互，所以在本实施例中，客户端在访问资源的过程中，只需要做少量交互就可实现资源访问，即简化了客户端的交互，所以缩短了访问资源的执行和响应时间。另外，在本实施例中，访问令牌具有一定的有效时段，所以在可以保证资源的安全性的基础上，进一步减少了授权交互的次数，提高了访问资源的效率。

接下来将介绍用户资源网关的功能结构图，如图7所示，用户资源网关包括：

第一接收单元401，用于接收客户端发送的资源请求；其中，资源请求中包含一个或多个资源ID，每个资源ID对应一个资源；处理单元402，用于对客户端进行权限验证，并在验证通过后基于资源一个或多个资源ID生成对应一个或多个资源服务器的一个或多个单个资源请求；每个单个资源请求中包含与所请求资源对应的访问令牌，访问令牌表征资源所有者允许URG访问资源；第一发送单元403，用于分别发送一个或多个单个资源请求给一个或多个资源服务器；第二接收单元404，用于从一个或多个资源服务器接收一个或多个单个资源请求的一个或多个响应消息，一个或多个响应消息中携带与一个或多个单个资源请求对应的资源；第二发送单元405，用于将资源发送给客户端。

在一实施例中，用户资源网关还包括：第三发送单元，用于向资源所有者发送授权请求；第三接收单元，用于接收资源所有者的授权响应消息；处理单元402用于基于授权响应消息确定验证通过。

在另一实施例中，资源请求中携带访问标识，访问标识表征资源所有者允许客户端访问资源，处理单元402具体用于基于访问标识对客户端进行权限验证。

进一步，用户资源网关还包括：第四接收单元，用于在第一接收单元401接收客户端发送的资源请求之前，接收客户端发送的授权请求，请求授权访问资源；第四发送单元，用于向资源所有者发送授权请求；第五接收单元，用于接收资源所有者的授权响应消息；处理单元402具体还用于基于授权响应消息分配访问标识给客户端。

再进一步，用户资源网关还包括：第六接收单元，用于在处理单元402具体还用于基于授权响应消息分配访问令牌给客户端之前，接收资源所有者发送的资源聚合请求，资源聚合请求中包含用户ID和资源的标识，所述资源的标识具体可以是资源名称或资源存储地址；第五发送单元，用于基于资源聚合请求向与资源所属业务相关的授权服务器发送授权请求；第七接收单元，用于接收授权服务器返回的与业务相关联的访问令牌。

结合以上各实施例，处理单元402具体用于基于资源ID和资源名称或者资源存储地址之间的对应关系，获得与一个或多个资源ID对应的一个或多个原始存储地址；基于一个或多个原始存储地址，获得一个或多个单个资源请求。

结合以上各实施例，处理单元402还用于转换并合并每个资源服务器的响应消息，那么第二发送单元405具体用于将转换并合并后的响应消息发送给客户端。

进一步，处理单元402还用于针对资源服务器所发布的业务的所请求资源的URL，去掉域和协议相关的参数，关联业务的应用程序编程接口API的名字生成资源ID并发布资源ID。

结合以上各实施例，访问令牌在预定时间段内有效，处理单元402具体还用于在访问令牌超过预定时间段内后删除访问令牌；用户资源网关还包括：第六发送单元，用于再向与资源所属业务相关的授权服务器发送授权请求。

前述图4-图6c实施例中的资源访问的方法中的各种变化方式和具体实例同样适用于本实施例的用户资源网关，通过前述对资源访问的方法的详细描述，本领域技术人员可以清楚的知道本实施例中用户资源网关的实施方法，所以为了说明书的简洁，在此不再详述。

而在实际运用中，URG逻辑功能实体可以集成到业务叠加网络的业务路由器中，即URG映射到业务路由器，用户与业务路由器之间是可信的，之间的操作无需验证授权。App是发布在App store（应用商店）上的应用，该应用可以由业务叠加网络，运营商或者是第三方服务提供商提供，所有的应用都预先在业务叠加网的业务目录中注册后才能使用。应用可以使用OAUTH2.0协议请求远程资源的访问，业务路由器处理该资源访问请求。资源所有者，拥有资源和授权应用使用资源的权利。资源所有者所拥有的资源分布在电信，IT和网络等领域的各个业务中。业务路由器的URG功能实体能够提供资源聚集能力，从而提供资源所有者在基础网络资源，如电信，IT和网络等等领域登录访问这些资源。除此之外，业务路由器的URG功能实体还能提供资源缓存能力，有助于提高应用程序的响应时间和性能。在实际运用中，用户资源网关也可以是一个单独的物理实体。

请参考图8所示，为用户资源网关的硬件实现示例的概念图，该用户资源网关包括：

接收器501，用于接收客户端发送的资源请求；其中，资源请求中包含一个或多个资源ID，每个资源ID对应一个资源；并从一个或多个资源服务器接收一个或多个单个资源请求的一个或多个响应消息，一个或多个响应消息中携带与一个或多个单个资源请求对应的资源；处理器502，用于对客户端进行权限验证，并在验证通过后基于一个或多个资源ID生成对应一个或多个资源服务器的一个或多个单个资源请求；每个单个资源请求中包含与所请求资源对应的访问令牌，访问令牌表征资源所有者允许URG访问资源；发送器503，用于发送一个或多个单个资源请求给一个或多个资源服务器，并将资源发送给客户端。

其中，在图8中，总线架构（用总线500来代表），总线500可以包括任意数量的互联的总线和桥，总线500将包括由处理器502代表的一个或多个处理器和存储器505代表的存储器的各种电路链接在一起。总线500还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口504在总线500和发送器503和接收器501之间提供接口。

处理器502负责管理总线500和通常的处理，而存储器505可以被用于存储处理器502在执行操作时所使用的数据。存储器505还可以用于存储节点设备的数据和软件。

在一实施例中，发送器503具体还用于向资源所有者发送授权请求；接收器501还用于接收资源所有者的授权响应消息；处理器502基于授权响应消息确定验证通过。

在另一实施例中，资源请求中携带访问标识，访问标识表征资源所有者允许客户端访问资源，处理器502具体用于基于访问标识对客户端进行权限验证。

进一步，在接收器501接收客户端发送的资源请求之前，接收器501还用于接收客户端发送的授权请求，请求授权访问资源；发送器503还用于向资源所有者发送授权请求；接收器501还用于接收资源所有者的授权响应消息；处理器502还用于基于授权响应消息分配访问标识给客户端。

进一步，在处理器502基于授权响应消息分配访问标识给客户端之前，接收器501还用于接收资源所有者发送的资源聚合请求，资源聚合请求中包含用户ID和资源的标识，所述资源的标识具体可以是资源名称或资源存储地址；

发送器503还用于基于资源聚合请求向与资源所属业务相关的授权服务器发送授权请求；

接收器501还用于接收授权服务器返回的访问令牌。

在一实施例中，处理器502具体用于基于资源ID和资源名称或者资源存储地址之间的对应关系，获得与一个或多个资源ID对应的一个或多个原始存储地址；基于一个或多个原始存储地址，获得一个或多个单个资源请求。

结合以上各实施例，处理器502还用于转换并合并每个资源服务器的响应消息；发送器503具体用于将转换并合并后的响应消息发送给客户端。

结合以上各实施例，处理器502具体用于基于资源ID和统一资源定位符URL之间的对应关系，获得与资源ID对应的原始URL，并基于原始URL，获得单个资源请求。

结合以上各实施例，处理器502还用于在接收器接收客户端发送的资源请求之前，针对资源服务器所发布的业务的资源的URL，去掉域和协议相关的参数，关联业务的应用程序编程接口API的名字生成资源ID；发布资源ID。

结合以上各实施例，访问令牌在预定时间段内有效；处理器502还用于在访问令牌超过预定时间段内后删除访问令牌；发送器503还用于再向与资源所属业务相关的授权服务器发送授权请求。

前述图4-图6c实施例中的资源访问的方法中的各种变化方式和具体实例同样适用于本实施例的用户资源网关，通过前述对资源访问的方法的详细描述，本领域技术人员可以清楚的知道本实施例中用户资源网关的实施方法，所以为了说明书的简洁，在此不再详述。

接下来再请参考图9所示，为用户资源网关的另一硬件实现示例的概念图，该用户资源网关包括：

第一接收器801，用于接收资源所有者发送的资源聚合请求，资源聚合请求中包含用户ID和M类业务的资源的标识，所述资源的标识具体可以是资源名称或资源存储地址；其中，M为正整数；第一发送器802，用于基于资源聚合请求向与M类业务相关的一个或多个授权服务器发送授权请求；第二接收器803，用于接收一个或多个授权服务器基于授权请求返回的一个或多个访问令牌；一个或多个访问令牌分别与M类业务相关联；存储器804，用于存储一个或多个访问令牌；处理器805，用于当接收到客户端发送的携带用户ID的资源请求时，对客户端进行权限验证，并在验证通过后使用一个或多个访问令牌中与所请求资源的业务类型相对应的访问令牌从资源服务器获取资源；第二发送器806，用于将资源发送给客户端。

其中，在图9中，总线架构（用总线800来代表），总线800可以包括任意数量的互联的总线和桥，总线800将包括由处理器805代表的一个或多个处理器和存储器804代表的存储器的各种电路链接在一起。总线800还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口807在总线800和第一发送器802、第一接收器801、第二发送器806和第二接收器803之间提供接口。

处理器805负责管理总线800和通常的处理，而存储器804可以被用于存储处理器805在执行操作时所使用的数据。

进一步，用户资源网关还包括第三接收器，用于接收客户端发送的资源请求，资源请求中包含一个或多个资源ID，每个资源ID对应一个资源；第三发送器，用于向资源所有者发送授权请求；第四接收器，用于接收资源所有者的授权响应消息；处理器805用于基于响应消息确定验证通过。

进一步，在所述资源请求中包含一个或多个资源ID，并涉及一个或多个资源服务器时，处理器805具体用于基于一个或多个资源ID生成对应一个或多个资源服务器凡人一个或多个单个资源请求；每个单个资源请求中包含与所请求资源对应的访问令牌；用户资源网关还包括：第四发送器，用于分别发送一个或多个单个资源请求给一个或多个资源服务器；第五接收器，用于从一个或多个资源服务器接收一个或多个单个资源请求的一个或多个响应消息，一个或多个响应消息中携带与一个或多个单个资源请求分别对应的资源。

进一步，处理器805具体用于基于资源ID和资源的标识，所述资源的标识具体可以是资源名称或资源存储地址之间的对应关系，获得与一个或多个资源ID对应的一个或多个原始存储地址；基于一个或多个原始存储地址，获得一个或多个单个资源请求。

结合以上各实施例，访问令牌在预定时间段内有效；处理器805还用于在一个或多个访问令牌超过预定时间段后删除一个或多个访问令牌；第一发送器802，还用于再向一个或多个授权服务器发送授权请求。

结合以上各实施例，第一接收器801、第二接收器803、第三接收器、第四接收器和第五接收器在实际运用中可以是同一个接收器，第一发送器802和第二发送器806、第三发送器和第四发送器在实际运用中可以是同一发送器。而接收器和发送器具体也可以是同一个物理元件，例如收发机。

前述图4-图6c实施例中的资源访问的方法中的各种变化方式和具体实例同样适用于本实施例的用户资源网关，通过前述对资源访问的方法的详细描述，本领域技术人员可以清楚的知道本实施例中用户资源网关的实施方法，所以为了说明书的简洁，在此不再详述。

以下将举一个由逻辑功能实体到物理实体的映射的实例来介绍本申请实施例中的资源访问方法的实施过程，URG映射到业务路由器，例如前述所描述的业务路由器，业务以Twitter和Facebook为例，对于Twitter业务来讲，资源服务器和授权服务器两个逻辑功能实体统一集成到Twitter业务中；对于Facebook业务来讲，资源服务器和授权服务器两个逻辑功能实体统一集成到Facebook业务中。Twitter业务和Facebook业务的资源所有者例如为用户X。聚合Twitter业务和Facebook业务的客户端应用是Social Media DB（社交媒体数据库）。

首先用户X需要在业务路由器上分别注册其在Twitter业务和Facebook业务中所拥有的资源，然后业务路由器分别为Twitter业务和Facebook业务生成统一资源访问API。当用户X使用客户端应用Social Media DB的时候，业务路由器Social Media DB根据业务路由器所提供的统一资源访问API访问用户X所授权的资源。

请参考图10a和图10b所示，为用户X在业务路由上注册其在Twitter业务和Facebook业务中所拥有的资源的流程图，首先请先参考图10a所示，为用户X注册Twitter业务的资源的流程图，包括如下步骤：

在步骤601中，用户X发送聚合Twitter业务中的Tweets（相册）、Followers（好友列表）资源的聚合资源请求到业务路由器。

在步骤602中，业务路由器请求Twitter（授权服务器）授权资源访问请求，业务路由器发送该访问请求到Twitter业务。

在步骤603中，Twitter发送请求登录授权的请求到用户X，例如是一个登陆和授权界面。

在步骤604中，用户X登录并通过授权，允许业务路由器访问该业务。

在步骤605中，Twitter（授权服务器）生成访问令牌，并返回该访问令牌给业务路由器，该访问令牌具有一定生命周期。

在步骤606中，业务路由器携带该访问令牌访问用户X的Twitter资源，例如用户的相册资源，具体例如使用GET http://api.twitter.com/my/tweets的访问请求到Twitter（资源服务器）。

在步骤607中，Twitter根据访问令牌返回业务路由器所请求的资源，即相册资源，返回的响应消息例如为{“tweets":[{“tweet":"value"}]}。

在步骤608中，业务路由器在本地缓存该相册资源。

在步骤609中，业务路由器携带该访问令牌访问用户X的Twitter资源，例如用户的好友列表资源，具体例如使用GET http://api.twitter.com/my/followers的访问请求到Twitter（资源服务器）。

在步骤610中，Twitter根据访问令牌返回业务路由器所请求的资源，即好友列表资源，返回的响应消息例如为<followers><follower>[follower ID]</follower><followers>。

在步骤611中，业务路由器在本地缓存该好友列表资源。

以上步骤606至步骤611为可选的步骤，通过这些步骤可以在本地缓存资源，当客户端应用访问资源时，可以直接从本地获取资源返回，提高响应效率和缩短响应时间。

然后业务路由器还可以为相册、好友列表资源分配全局唯一的资源ID，并为Twitter业务生成访问相册、好友列表资源的统一资源访问API并发布出来。

接下来请再参考图10b所示，为用户X注册Facebook业务的资源的流程图，与图10a中的流程类似，包括如下步骤：

在步骤612中，用户X发送聚合Facebook业务中的Posts（相册）、Friends（好友列表）资源的聚合资源请求到业务路由器。

在步骤613中，业务路由器请求Facebook（授权服务器）授权资源访问请求，业务路由器发送该访问请求到Facebook业务。

在步骤614中，Facebook发送请求登录授权的请求到用户X，例如是一个登陆和授权界面。

在步骤615中，用户X登录并通过授权，允许业务路由器访问该业务。

在步骤616中，Facebook（授权服务器）生成访问令牌，并返回该访问令牌给业务路由器，该访问令牌具有一定生命周期。

在步骤617中，业务路由器携带该访问令牌访问用户X的Facebook资源，例如用户的相册资源，具体例如使用GET http://api.facebook.com/my/posts的访问请求到Facebook（资源服务器）。

在步骤618中，Facebook根据访问令牌返回业务路由器所请求的资源，即相册资源，返回的响应消息例如为{“posts":[{“post":"value"}]}。

在步骤619中，业务路由器在本地缓存该相册资源。

在步骤620中，业务路由器携带该访问令牌访问用户X的Facebook资源，例如用户的好友列表资源，具体例如使用GET http://api.twitter.com/my/friends的访问请求到Facebook（资源服务器）。

在步骤621中，Facebook根据访问令牌返回业务路由器所请求的资源，即好友列表资源，返回的响应消息例如为<friends><friend>[friend ID]</friend><friends>。

在步骤622中，业务路由器在本地缓存该好友列表资源。

以上步骤617至步骤622为可选的步骤，通过这些步骤可以在本地缓存资源，当客户端应用访问资源时，可以直接从本地获取资源返回，提高响应效率和缩短响应时间。

然后业务路由器还可以为相册、好友列表资源分配全局唯一的资源ID，并为Facebook业务生成访问相册、好友列表资源的统一资源访问API并发布出来。

当应用开发者开发Social Media DB应用时，将上述发布出来的API内嵌在应用的代码中，那么Social Media DB应用就为集成了Twitter和Facebook业务的应用程序，当用户X启动Social Media DB应用时，Social Media DB应用需要分别调用Twitter和Facebook业务的资源，需要用户X认证授权。

然后接下来介绍用户X授权Social Media DB应用访问Twitter和Facebook资源，首先请参考图11a所示，为用户X授权Social Media DB应用访问Twitter资源的流程图，包括如下步骤：

在步骤701中，用户X使用Social Media DB应用。

在步骤702中，Social Media DB应用根据应用程序逻辑控制，例如访问的先后顺序，在本实施例中，例如先访问Twitter业务的资源，那么就根据Social Media DB应用所集成的Twitter的统一访问资源API，Social Media DB发送资源请求到业务路由器；资源请求例如为Get http://<URG broker address>/twitterAPI?resource IDs=twitterAPI-my-tweets,twitterAPI-my-followers。

在步骤703中：业务路由器发送验证授权请求给资源所有者，也就是用户X，对Social Media DB的资源访问授权。

在步骤704中：用户X登录并授权Social Media DB访问Twitter资源。

在步骤705中，业务路由器分配访问标识给Social Media DB，该访问标识的有效期是有限的。在有效期内，应用Social Media DB可以访问用户X的Twitter资源而无需用户多次验证授权，有效期后，需要重新验证授权。

在步骤706中，Social Media DB发送携带访问令牌的资源请求消息到业务路由器；此处的资源请求和步骤702中的资源请求除了访问令牌外，其余可相同。

在步骤707中，业务路由器解析资源请求，如果是业务路由器本地缓存的资源，使用READ/FETCH API在本地获取访问资源，该步骤对应于前述步骤606至步骤611，即如果在本地缓存了这些资源，就可以执行步骤707，在本地获取访问资源。

在步骤708中，如果不是本地缓存的资源，业务路由器就转换步骤706中的资源请求调用资源服务器上的资源。

在步骤709中，业务路由器使用访问令牌调用资源服务器的资源访问API，访问相册资源，例如发送的请求是Get http://api.twitter.com/my/tweets。

在步骤710中，资源服务器发送响应消息到业务路由器，响应消息中携带相册资源；响应消息例如为：{“tweets":[{“tweet":"value"}]}。

在步骤711中，业务路由器使用访问令牌调用资源服务器的资源访问API，访问好友列表资源，例如发送的请求是Get http://api.twitter.com/my/followers。

在步骤712中，资源服务器发送响应消息到业务路由器，响应消息中携带好友列表资源；响应消息例如为：<followers><follower>[follower ID]</follower><followers>。

在步骤713中，此步骤可选，业务路由器转换并合并资源服务器的相册、好友列表的响应消息，并集成相册和好友列表资源；其中，合并后的响应消息例如为：<twitter API><response><twitter API–my-tweets><json><tweets><tweet>value</tweet></tweets></json></twitter API-my-tweet><twitter API-my-followers>>followers><follower>[follower ID]</follower></followers>>/twitter API-my-followers></response></twitter API>；

在步骤714中，业务路由器发送资源访问请求的响应消息给Social Media DB应用。

根据Social Media DB的应用逻辑，先访问用户X的Twitter资源，然后再访问用户X的Facebook资源，Twitter资源和Facebook资源的访问方式和流程相似，请参考图11b所示，为访问Facebook资源的流程，包括如下步骤：

在步骤715中，根据Social Media DB应用所集成的Facebook的统一访问资源API，Social Media DB应用发送资源请求到业务路由器；资源请求例如为Get http://<URGbroker address>/facebookAPI?resource IDs=facebookAPI-my-posts,facebookAPI-my-friends。

在步骤716中，业务路由器发送验证授权请求给资源所有者，也就是用户X，对Social Media DB的资源访问授权。

在步骤717中，用户X登录并授权Social Media DB访问Facebook资源。

在步骤718中，业务路由器分配访问标识给Social Media DB，该访问标识的有效期是有限的。在有效期内，应用Social Media DB可以访问用户X的Facebook资源而无需用户多次验证授权，有效期后，需要重新验证授权。

在步骤719中，Social Media DB发送携带访问令牌的资源请求消息到业务路由器；此处的资源请求和步骤715中的资源请求除了访问令牌外，其余可相同。

在步骤720中，业务路由器解析资源请求，如果是业务路由器本地缓存的资源，使用READ/FETCH API在本地获取访问资源，该步骤对应于前述步骤617至步骤622，即如果在本地缓存了这些资源，就可以执行步骤720，在本地获取访问资源。

在步骤721中，如果不是本地缓存的资源，业务路由器就转换步骤706中的资源请求调用资源服务器上的资源。

在步骤722中，业务路由器使用访问令牌调用资源服务器的资源访问API，访问相册资源，例如发送的请求是Get http://api.facebook.com/my/posts。

在步骤723中，资源服务器发送响应消息到业务路由器，响应消息中携带相册资源；响应消息例如为：{“posts":[{“post":"value"}]}。

在步骤724中，业务路由器使用访问令牌调用资源服务器的资源访问API，访问好友列表资源，例如发送的请求是Get http://api.facebook.com/my/friends。

在步骤725中，资源服务器发送响应消息到业务路由器，响应消息中携带好友列表资源；响应消息例如为：<friends><friend>[friend ID]</friend><friends>。

在步骤726中：此步骤可选，业务路由器转换并合并资源服务器的相册、好友列表的响应消息，并集成相册和好友列表资源；合并后的响应消息例如为：<twitter API><response><facebook API–my-posts><json><posts><post>value</post></posts></json></facebook API-my-post><facebook API-my-friends>>friends><friend>[friend ID]</friend></friends>>/facebook API-my-friends></response></facebook API>。

在步骤727中，业务路由器发送资源访问请求的响应消息给Social Media DB应用。

在步骤728中，Social Media DB集成步骤714和步骤727中所获得的资源。

在步骤729中，Social Media DB发送所集成的Social Media(社交媒体)资源给用户X，即呈现给用户X。

另一个实例，例如用户使用用户资源网关注册用户存储在腾讯QQ，新浪微博和天涯网站的资源。用户资源网关分别为腾讯QQ,新浪微博和天涯网站的资源创建资源访问API并发布到业务目录中。当应用程序开发者创建应用时，可以根据需求任意选择所需的API，组合并创建应用程序。当用户使用该应用程序的时候，会根据应用开发者所创建应用程序的执行逻辑，依次调用腾讯QQ，新浪微博和天涯网站的资源，用户资源网关就需要用户对该资源的访问验证授权，获得用户授权后，用户资源网关就给该应用程序对腾讯QQ，新浪微博和天涯网站的资源访问获得一个有效时间段的访问权限，在该访问权限（技术上使用访问令牌）的有效期内，应用程序对任何一个资源的访问都无需用户再次授权。应用程序本身具有的资源集成能力会将所获取的资源集成后展示给用户。

在以上各实施例中，均以Get操作为例进行说明的，但是在实际运用中，其他操作的操作流程和信令均与Get操作类似，指示不同操作方式导致操作的结果不同，GET是获得资源，DELELE是删除资源，POST是更新资源，PUT是传递资源，本申请不再重复叙述流程。

本发明实施例中提供的一个或多个技术方案，至少具有如下技术效果或优点：

在本发明一实施例中，用户资源网关URG接收资源所有者发送的资源聚合请求，资源聚合请求中包含用户ID和M类业务的资源的标识，所述资源的标识具体可以是资源名称或资源存储地址；其中，M为正整数；URG基于资源聚合请求向与M类业务相关的一个或多个授权服务器发送授权请求；URG接收一个或多个授权服务器基于授权请求返回的一个或多个访问令牌；一个或多个访问令牌分别与M类业务相关联；URG存储一个或多个访问令牌；当URG接收到客户端发送的携带用户ID的资源请求时，对客户端进行权限验证，并在验证通过后使用一个或多个访问令牌中与所请求资源的业务类型相对应的访问令牌从资源服务器获取资源；URG将资源发送给客户端。即在本实施例中，先在URG聚合资源，URG获得对这些资源的访问令牌，当客户端向URG请求资源时，URG先对客户端进行验证，在验证通过后就由URG使用之前获得的访问令牌去资源服务器请求资源，然后将请求到的资源返回给客户端，所以客户端不需要与资源服务器做信令交互，按照不同资源服务器的格式访问资源服务器；进一步，在本实施例中，访问令牌与业务相关联，所以客户端可以在一个请求中请求同一业务下的多个资源，而只需要一次权限验证，就可以访问多个资源，所以客户端也不需要进行多次授权的信令交互，所以在本实施例中，客户端在访问资源的过程中，只需要做少量交互就可实现资源访问，即简化了客户端的交互，所以缩短了访问资源的执行和响应时间。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器和光学存储器等）上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (20)

1.一种资源访问方法，其特征在于，包括：

用户资源网关URG接收资源所有者发送的资源聚合请求，所述资源聚合请求中包含用户ID和M类业务的资源的资源标识；其中，M为正整数；

所述URG基于所述资源聚合请求向与所述M类业务相关的一个或多个授权服务器发送授权请求；

所述URG接收所述一个或多个授权服务器基于所述授权请求返回的一个或多个访问令牌；所述一个或多个访问令牌分别与所述M类业务相关联；

所述URG存储所述一个或多个访问令牌；

当所述URG接收到客户端发送的携带所述用户ID的资源请求时，对所述客户端进行权限验证，并在验证通过后使用所述一个或多个访问令牌中与所请求资源的业务类型相对应的访问令牌从一个或多个资源服务器获取所述资源；

所述URG将所述资源发送给所述客户端。

2.如权利要求1所述的方法，其特征在于，在所述URG存储所述一个或多个访问令牌之后，还包括：

接收所述客户端发送的所述资源请求；

所述对所述客户端进行权限验证，包括：

所述URG向所述资源所有者发送授权请求；

所述URG接收所述资源所有者的授权响应消息，所述授权响应消息表征验证通过。

3.如权利要求1或2所述的方法，其特征在于，在所述资源请求中包含一个或多个资源ID，并涉及一个或多个资源服务器时，所述使用所述一个或多个访问令牌中与所请求资源的业务类型相对应的访问令牌从一个或多个资源服务器获取所述资源，具体包括：

所述URG基于所述一个或多个资源ID生成对应所述一个或多个资源服务器的一个或多个单个资源请求；每个所述单个请求中包含与所请求资源对应的访问令牌；

所述URG分别发送所述一个或多个单个资源请求给所述一个或多个资源服务器；

所述URG从所述一个或多个资源服务器接收所述一个或多个单个资源请求的一个或多个响应消息，所述一个或多个响应消息中携带与所述一个或多个单个资源请求分别对应的资源。

4.如权利要求1或2所述的方法，其特征在于，所述访问令牌在预定时间段内有效，则所述方法还包括：

所述URG在所述一个或多个访问令牌超过所述预定时间段后删除所述一个或多个访问令牌；

所述URG再向所述一个或多个授权服务器发送授权请求。

5.一种资源访问方法，其特征在于，包括：

用户资源网关URG接收客户端发送的资源请求；其中，所述资源请求中包含一个或多个资源ID，每个所述资源ID对应一个资源；

所述URG对所述客户端进行权限验证；

所述URG在验证通过后基于所述一个或多个资源ID生成对应一个或多个资源服务器的一个或多个单个资源请求；每个所述单个资源请求中包含与所请求资源对应的访问令牌，所述访问令牌表征资源所有者允许所述URG访问所述资源；

所述URG分别发送所述一个或多个单个资源请求给所述一个或多个资源服务器；

所述URG从所述一个或多个资源服务器接收所述一个或多个单个资源请求的一个或多个响应消息，所述一个或多个响应消息中携带与所述一个或多个单个资源请求对应的资源；

所述URG将所述资源发送给所述客户端。

6.如权利要求5所述的方法，其特征在于，所述URG对所述客户端进行权限验证，包括：

所述URG向所述资源所有者发送授权请求；

所述URG接收所述资源所有者的授权响应消息，所述授权响应消息表征验证通过。

7.如权利要求5所述的方法，其特征在于，所述资源请求中携带访问标识，所述访问标识表征所述资源所有者允许所述客户端访问所述资源，所述URG对所述客户端进行权限验证，包括：

所述URG基于所述访问标识对所述客户端进行权限验证。

8.如权利要求7所述的方法，其特征在于，在所述用户资源网关URG接收客户端发送的资源请求之前，还包括：

所述URG接收客户端发送的授权请求，请求授权访问所述资源；

所述URG向所述资源所有者发送授权请求；

所述URG接收所述资源所有者的授权响应消息；

所述URG基于所述授权响应消息分配所述访问标识给所述客户端。

9.如权利要求8所述的方法，其特征在于，在所述URG基于所述授权响应消息分配所述访问标识给所述客户端之前，还包括：

所述URG接收所述资源所有者发送的资源聚合请求，所述资源聚合请求中包含用户ID和所述资源的标识；

所述URG基于所述资源聚合请求向与所述资源所属业务相关的授权服务器发送授权请求；

所述URG接收所述授权服务器返回的与所述业务相关联的所述访问令牌。

10.如权利要求5-9任一项所述的方法，其特征在于，在所述URG将所述资源发送给所述客户端之前，还包括：

所述URG转换并合并每个所述资源服务器的响应消息；

所述URG将所述资源发送给所述客户端具体为：

所述URG将转换并合并后的响应消息发送给所述客户端。

11.如权利要求5-9任一项所述的方法，其特征在于，在所述用户资源网关URG接收客户端发送的资源请求之前，还包括：

所述URG针对所述资源服务器所发布的业务的所述资源的URL，去掉域和协议相关的参数，关联所述业务的应用程序编程接口API的名字生成所述资源ID；

所述URG发布所述资源ID。

12.如权利要求5-9任一项所述的方法，其特征在于，所述访问令牌在预定时间段内有效，所述方法还包括：

所述URG在所述访问令牌超过所述预定时间段内后删除所述访问令牌；

所述URG再向与所述资源所属业务相关的授权服务器发送授权请求。

13.一种用户资源网关，其特征在于，包括：

接收器，用于接收客户端发送的资源请求；其中，所述资源请求中包含一个或多个资源ID，每个所述资源ID对应一个资源；并从一个或多个的资源服务器接收一个或多个单个资源请求的一个或多个响应消息，所述一个或多个响应消息中携带与所述一个或多个单个资源请求对应的资源；

处理器，用于对所述客户端进行权限验证，并在验证通过后基于所述一个或多个资源ID生成对应所述一个或多个资源服务器的一个或多个单个资源请求；每个所述单个资源请求中包含与所请求资源对应的访问令牌，所述访问令牌表征资源所有者允许所述URG访问所述资源；

发送器，用于发送所述一个或多个单个资源请求给所述一个或多个资源服务器，并将所述所请求资源发送给所述客户端。

14.如权利要求13所述的用户资源网关，其特征在于，所述发送器具体还用于向所述资源所有者发送授权请求；所述接收器还用于接收所述资源所有者的授权响应消息；所述处理器基于所述授权响应消息确定验证通过。

15.如权利要求13所述的用户资源网关，其特征在于，所述资源请求中携带访问标识，所述访问标识表征所述资源所有者允许所述客户端访问所述资源，所述处理器具体用于基于所述访问标识对所述客户端进行权限验证。

16.如权利要求15所述的用户资源网关，其特征在于，在所述接收器接收客户端发送的资源请求之前，所述接收器还用于接收客户端发送的授权请求，请求授权访问所述资源；所述发送器还用于向所述资源所有者发送授权请求；所述接收器还用于接收所述资源所有者的授权响应消息；所述处理器还用于基于所述授权响应消息分配所述访问标识给所述客户端。

17.如权利要求16所述的用户资源网关，其特征在于，在所述处理器基于所述授权响应消息分配所述访问令牌给所述客户端之前，所述接收器还用于接收所述资源所有者发送的资源聚合请求，所述资源聚合请求中包含用户ID和所述资源的标识；

所述发送器还用于基于所述资源聚合请求向与所述资源所属业务相关的授权服务器发送授权请求；

所述接收器还用于接收所述授权服务器返回的所述访问令牌。

18.如权利要求13-17任一项所述的用户资源网关，其特征在于，所述处理器还用于转换并合并每个所述资源服务器的响应消息；

所述发送器具体用于将转换并合并后的响应消息发送给所述客户端。

19.如权利要求13-17任一项所述的用户资源网关，其特征在于，所述处理器还用于在所述接收器接收客户端发送的资源请求之前，针对所述资源服务器所发布的业务的所述资源的URL，去掉域和协议相关的参数，关联所述业务的应用程序编程接口API的名字生成所述资源ID；发布所述资源ID。

20.如权利要求13-17任一项所述的用户资源网关，其特征在于，所述访问令牌在预定时间段内有效；所述处理器还用于在所述访问令牌超过所述预定时间段内后删除所述访问令牌；所述发送器还用于再向与所述资源所属业务相关的授权服务器发送授权请求。