CN105763547A - 第三方授权方法和第三方授权系统 - Google Patents

Abstract

本发明属于通信技术领域，具体涉及一种第三方授权方法和第三方授权系统。该第三方授权方法，包括步骤：获取请求用户的用户ID、访问业务的业务ID以及所述请求用户与所述访问业务两者之间的交互记录；在第三方授权系统中已绑定所述访问业务，且存有所述请求用户的身份信息的条件下，通过所述请求用户的身份认证；在所述请求用户的身份认证成功的条件下，查询所述用户ID和所述业务ID之间的信任度，根据用户侧和业务侧的权限匹配，对所述请求用户访问所述访问业务进行对应权限的授权确认。该第三方授权方法和第三方授权系统实现了用户资源的真正共享，又有效保护了用户隐私性。

Description

第三方授权方法和第三方授权系统

技术领域

本发明属于通信技术领域，具体涉及一种第三方授权方法和第三方授权系统。

背景技术

互联网提供的资源和服务的数量非常巨大且增长迅猛，已成为人们获取信息和服务的主要渠道。然而网络用户隐私安全形势愈加严峻，由于用户往往习惯于简单密码的登录方式，因而存在弱口令、“拖库”、“撞库”等安全隐患。为了进一步降低用户信息泄露以及认证关键信息被截获的风险，通过第三方实现授权登录、分享以及获取用户资料，是解决这些问题的有效途径。

第三方授权认证的优势是便携性和安全性。对用户而言，由第三方权威认证机构统一管理身份数据更为安全、可靠，统一账号登录也避免记忆大量账户密码，简化登录流程；对第三方认证机构而言，把控用户互联网接入入口，能够对用户和服务提供商的接入行为有效监管；对服务提供商而言，能够共享用户资源，并且无需自行建设身份认证系统，降低运营开销成本。

在第三方授权认证系统中，用户终端访问业务平台时，只有通过第三方认证机构的服务认证后才能被授权接入相应服务。认证系统采用统一账号登录，即采用第三方认证平台的统一用户名密码访问其他业务平台，例如AppleID、QQ账号登录、微博账号登录、邮箱登录等。第三方授权认证系统根据用户提供的账号进行身份验证，当用户名和密码均正确且匹配，则认为用户身份合法，认证成功，用户终端才有访问业务平台的权限。

然而事实上每个用户访问业务平台时都具有不同的访问权限，访问权限的划定通常基于用户和业务的安全级别。特别是对于一些付费业务，用户的权限直接与业务平台的经济利益相关。例如优酷视频，一般用户只能观看一些免费视频，而对于一些高级别的用户可以开放部分付费视频权限，而随着用户级别的增加，开放权限也随之增大。

遗憾的是，在现有技术中第三方授权认证系统仅仅具备了用户身份认证的功能，却不具备对用户权限的管理功能。因此用户访问业务平台需要先进行第三方认证，待身份合法后再由业务平台根据用户身份去判断用户权限等级。这便意味着第三方认证机构和业务平台都要建立一套用户身份管理体系，两者存储的用户身份数据既有重复性又有区别性。这样既造成了业务流程的繁琐和资源设备的浪费，对于两个系统的数据互通性也存在挑战。例如，用户的身份信息由第三方认证机构监管，用户权限则由业务平台进行判定，而权限的判定往往又以身份信息为依据。这便意味着第三方认证机构需要向业务平台开放用户身份数据，换言之第三方认证机构更多的是仅仅实现了一个数据库功能，而非对用户权限的认证和管理功能。另一方面，第三方授权认证的机制是通过将用户与业务隔离以增强认证的权威性和安全性，而事实上第三方认证机构绑定的业务平台又不仅仅只有一个，这又意味着多业务之间的用户信息可以随意调用，因而存在严重的安全隐患。

综上所述，现有方法的出发点是通过第三方权威机构解决授权认证的安全性和便携性。但在技术实现上由于现有技术将认证和授权两个步骤混为一起，第三方认证机构仅仅通过认证实现了访问行为的授权，缺乏对行为权限的管理，因而造成了上述安全隐患以及业务流程的繁琐。

发明内容

本发明所要解决的技术问题是针对现有技术中存在的上述不足，提供一种第三方授权方法和第三方授权系统，该第三方授权方法和第三方授权系统实现了做到了用户资源的真正共享，又有效保护了用户隐私性。

解决本发明技术问题所采用的技术方案是该第三方授权方法，包括步骤：

获取请求用户的用户ID、访问业务的业务ID以及所述请求用户与所述访问业务两者之间的交互记录；

在第三方授权系统中已绑定所述访问业务，且存有所述请求用户的身份信息的条件下，通过所述请求用户的身份认证；

在所述请求用户的身份认证成功的条件下，查询所述用户ID和所述业务ID之间的信任度，根据用户侧和业务侧的权限匹配，对所述请求用户访问所述访问业务进行对应权限的授权确认。

优选的是，如果所述用户ID和所述业务ID之间存在交互记录，直接查询出所述请求用户与所述访问业务两者之间的信任度；

在查询出所述请求用户与所述访问业务两者之间的信任度之前，包括计算所述用户ID和所述业务ID之间的交互记录的信任度的步骤，具体为：

针对所述请求用户对所述访问业务的类型，对不同类型业务根据不同的信任度计算法则生成初始信任矩阵，所述初始信任矩阵包括多个用户与多个业务平台之间的信任度；业务类型至少包括电子商务类业务、社交类业务和付费类业务中的至少一种，其中：

所述电子商务类业务的用户与所述业务平台的信任度为：

n为维度的个数，w_j为第j维度的维度权重，Score_j为第j维度的维度得分；

所述社交类业务的用户与所述业务平台的信任度为：

r_ij为肯定事件因素，s_ij为否定事件因素，w(i)为事件权重；

所述付费类业务的用户与所述业务平台的信任度为：

a_ij为所述业务平台反馈的初始价值量，q_ij为用户的消费累计量，b_j为由所述业务平台设定的递增系数。

优选的是，如果所述用户ID和所述业务ID之间不存在交互记录，根据所述初始信任矩阵M，利用：

$\begin{array}{ccc}{\min }_{\tilde{M}}\left|\right|\tilde{M}|{|}_{tr}& s.t.& P_{\mathrm{\Ω}}(\tilde{M}-M)=0\end{array}$

通过最小化所述初始信任矩阵的迹范数预估所述初始信任矩阵中的缺失项，从而获得所述请求用户与所述业务平台之间的信任度，然后查询出所述请求用户与所述访问业务两者之间的信任度，其中，为预估信任矩阵。

优选的是，根据用户侧和业务侧的权限匹配，对所述请求用户访问所述访问业务进行对应权限的授权确认包括：

若所述用户ID和所述业务ID之间的信任度为所述访问业务的信任阈值为这里的m为信任等级对应的服务类型数量，当这里的k为所述业务平台能提供的服务级别，则所述访问业务对所述请求用户提供第k级别以下的所有类型服务；

所述用户ID对所述业务ID的信任阈值为θ_ij，当所述请求用户当前时刻申请的业务类型级别为第i级别，则授权行为决策包括：

1)当i≤k且所述业务平台能提供用户请求的服务类型，用户也可以接受所述业务平台的服务，用户与所述业务平台之间通过安全通道进行信息交互和访问；

2)当i≤k且所述业务平台能提供用户请求的服务类型，用户却认为所述业务平台的服务不够安全，第三方授权系统向用户卡应用发送授权请求，再根据用户反馈决定是否接受所述业务平台的服务；

3)当i>k且所述业务平台认为用户不具备该服务请求权限，而用户对所述业务平台充分信任，第三方授权系统向用户卡应用发送授权请求，再根据用户反馈决定是否提供所述业务平台的服务；

4)当i>k且所述业务平台认为用户不具备该服务请求权限，而用户对所述业务平台也不够信任，终止用户与所述业务平台之间的服务请求。

优选的是，对所述请求用户访问所述访问业务进行对应权限的授权确认之后，还进一步包括：根据当次交互行为记录更新所述请求用户与所述业务平台之间对应的访问业务的交互记录的信任度。

一种第三方授权系统，包括用户层、业务层和授权层，所述用户层与所述业务层通过所述授权层隔离，其中：

所述用户层，用于对用户身份信息的管理以及与用户移动终端的交互，包括卡应用管理、用户ID管理以及身份数据库；

所述业务层，用于对授权业务进行管理和监控，包括操作记录、业务管理、业务ID管理、IP管理和IP地址分配；

所述授权层，用于计算用户与访问业务的信任度，并通过身份认证、信任调用以及权限匹配完成访问业务对所述请求用户的鉴权管理。

优选的是，所述授权层包括信任度查询模块和信任度计算模块，其中：

所述信任度查询模块，用于查询所述用户ID和所述业务ID之间的信任度；

所述信任度计算模块，用于计算所述用户ID和所述业务ID之间的交互记录的信任度，对不同类业务根据不同的信任度计算法则，生成初始信任矩阵，所述初始信任矩阵包括多个用户与多个所述业务平台之间的信任度；所述信任度计算模块至少包括电子商务类业务子模块、社交类业务子模块和付费类业务子模块中的任一种，其中：

所述电子商务类业务子模块中，用户与所述业务平台的信任度的计算法则为：

n为维度的个数，w_j为第j维度的维度权重，Score_j为第j维度的维度得分；

所述社交类业务子模块中，用户与所述业务平台的信任度的计算法则为：

r_ij为肯定事件因素，s_ij为否定事件因素，w(i)为事件权重；

所述付费类业务子模块中，用户与所述业务平台的信任度E_ij的计算法则为：

E_ij＝a_ij+b_jq_ij,s.t.b_j>0

a_ij为所述业务平台反馈的初始价值量，q_ij为用户的消费累计量，b_j为由所述业务平台设定的递增系数。

优选的是，所述授权层还包括信任度矩阵填充模块，用于通过最小化所述初始信任矩阵M的迹范数预估所述初始信任矩阵中的缺失项，从而获得所述请求用户ID与所述业务ID之间的信任度，所述信任度矩阵填充模块的矩阵预估法则为：

$\begin{array}{ccc}{\min }_{\tilde{M}}\left|\right|\tilde{M}|{|}_{tr}& s.t.& P_{\mathrm{\Ω}}(\tilde{M}-M)=0\end{array}$

其中，为预估信任矩阵。

优选的是，所述授权层还包括授权模块，所述授权模块用于根据用户侧和业务侧的权限匹配，对所述请求用户访问所述访问业务进行对应权限的授权确认，包括：

若用户ID和业务ID之间的信任度为访问业务的信任阈值为这里的m为信任等级对应的服务数量，当这里的k为所述业务平台能提供的服务类型级别，则所述访问业务对所述请求用户提供第k级别以下的所有类型服务；

用户ID对业务ID的信任阈值为θ_ij，当所述请求用户当前时刻申请的业务类型级别为第i级别，则授权行为决策包括：

1)当i≤k且所述业务平台能提供用户请求的服务类型，用户也可以接受所述业务平台的服务，用户与所述业务平台之间通过安全通道进行信息交互和访问；

2)当i≤k且所述业务平台能提供用户请求的服务类型，用户却认为所述业务平台的服务不够安全，第三方授权系统向用户卡应用发送授权请求，再根据用户反馈决定是否接受所述业务平台的服务；

3)当i>k且所述业务平台认为用户不具备该服务请求权限，而用户对所述业务平台充分信任，第三方授权系统向用户卡应用发送授权请求，再根据用户反馈决定是否提供所述业务平台的服务；

4)当i>k且所述业务平台认为用户不具备该服务请求权限，而用户对所述业务平台也不够信任，终止用户与所述业务平台之间的服务请求。

优选的是，所述授权层还包括信任度更新模块，所述信任度更新模块用于根据当次交互行为记录更新所述请求用户与所述业务平台之间对应的访问业务的交互记录的信任度。

本发明的有益效果是：本发明第三方授权方法和第三方授权系统采用基于手机SIM卡应用的授权方式，并引入信任计算、信任填充和信任决策的授权机制，通过第三方授权系统与手机端卡应用进行数据短信交互以完成用户身份认证以及授权确认，实现了用户资源的真正共享，提高认证授权业务的安全性和便携性。

附图说明

图1为本发明实施例中第三方授权机制的示意图；

图2为本发明实施例中第三方授权方法的流程示意图；

图3为本发明实施例中第三方授权系统的总体架构的示意图；

附图标记中：

1-用户；

2-业务平台；

3-第三方授权系统；31-用户层；32-业务层；33-授权层。

具体实施方式

为使本领域技术人员更好地理解本发明的技术方案，下面结合附图和具体实施方式对本发明第三方授权方法和第三方授权系统作进一步详细描述。

本发明的技术构思在于：考虑到手机SIM卡在安全方面的独特优势，结合移动终端的普适性和便携性，本发明第三方授权方法在用户与业务平台的信任度基础上，采用基于手机SIM卡应用的授权方式，通过第三方授权系统与手机端卡应用进行数据短信交互以完成用户身份认证以及授权确认，提高认证授权业务的安全性和便携性。

该第三方授权系统采用三层架构设计，参阅图3，其包括用户层31、业务层32和授权层33。其中，授权层33主要实现两大功能，一是通过信任评估方法估算出用户与访问业务的信任度，另一是通过身份认证、信任调用(也即信任度调用)以及权限匹配完成访问业务对用户身份的鉴权管理。

信任评估作为本发明第三方授权方法的核心部分，也是信任机制实现的关键。考虑到不同的业务类型与用户之间的交互方式不一样，对两者之间的信任评估准则也会有所差异。本发明第三方授权方法本着公平性、合理性原则，首先将现有授权业务划分为四大类，再针对每类业务设计不同的信任度计算法则，生成初始信任矩阵；其次针对不存在交互数据的用户与业务通过矩阵填充预估其信任度；然后根据估算出的信任度以及获取到的用户侧和业务侧的信任阈值，分配用户对应的业务权限，并将授权结果反馈给业务平台；最后根据当次交互行为记录更新用户与业务的信任度。

本发明实施例中第三方授权方法的授权机制如图1所示：

(1)假设用户1通过移动终端向业务平台2发送访问请求，访问请求信息包括：用户ID、访问时间等。其中用户ID为认证系统中用户身份的唯一标示，可以为用户手机号码、邮箱、账户名等。

(2)业务平台2将用户1的访问请求以及业务ID封装成授权请求信息发送给第三方授权系统3。授权请求信息包括用户手机号、访问时间、业务ID、业务类型码等。其中，本实施例第三方授权方法优选采用手机SIM卡应用授权机制，所以在此将所有用户ID转换为用户手机号标识；业务ID即所访问业务平台2在第三方授权系统3中对应的ID标识；业务类型码为业务平台2对应的业务类型。

(3)第三方授权系统3根据授权请求的用户ID和业务ID先与用户终端的SIM卡应用进行认证交互，以确认用户身份是否真实。本实施例采用的是基于手机SIM卡应用的认证方式，在认证过程中第三方授权系统3需要与用户终端进行不同等级的行为交互：比如在卡应用弹窗中点击确认、输入PIN码、输入密码或者指纹识别等。关于认证等级的确定以及认证方式的选择由业务平台2根据自身业务需求设定。若用户身份认证成功，再进一步基于用户身份进行权限鉴定。

(4)第三方授权系统3根据用户1和业务平台2之间的信任度，以及两者各自的信任阈值判定用户1的访问权限。再与终端卡应用进行授权交互，以确认用户权限的分配。交互形式与第(3)步类似，需要用户1在移动终端完成卡应用弹窗的相应反馈。关于信任度的计算主要是基于用户1和业务平台2之间的交互记录进行信任评估和填充。关于信任阈值主要是用户1或者业务平台2根据自身业务的安全级别设定。

(5)第三方授权系统3将授权结果返回给业务平台2。授权结果的状态包括认证结果+鉴权结果，认证结果包括以下状态：

00：认证成功：用户身份真实，可以访问业务平台。

01：认证失败：业务平台提示用户登录失败，可重新发送请求。

02：用户ID不存在：业务平台提示用户ID错误。

03：参数错误：业务平台修改参数后重新提交验证请求。

04：请求超时：认证过程中用户端在指定时限内未做出应有反应。

05：用户ID未开通：第三方授权系统中没有用户信息。

06：系统标识不存在。第三方授权系统中没有业务平台信息。

当认证结果状态为00时同时反馈鉴权结果。鉴权结果为用户1对业务平台2的可访问权限级别编码。以搜狐视频为例，假设根据视频片源设置了8个业务等级，则编码000—111可以分别代表从低到高的8个访问权限编码。

(6)业务平台2将授权结果反馈给用户1，若授权结果为认证成功，用户可以根据第三方授权系统3反馈的鉴权状态建立安全通道，从而按权限访问业务平台2。

综上所述，本发明设计的第三方授权系统利用请求用户的用户ID与访问业务的业务ID之间的信任度进行用户访问权限的判定，相应的第三方授权方法大体包括步骤：

步骤1)获取请求用户的用户ID、访问业务的业务ID以及请求用户与访问业务两者之间的交互记录。这里，请求用户为当前发出授权申请的用户，区别于统称的用户。

步骤2)在第三方授权系统中已绑定访问业务，且存有请求用户的身份信息的条件下，通过请求用户的身份认证。这里，用户请求访问一个业务，首先这个业务和用户必须分别绑定的第三方授权系统，即要求授权系统需要同时有两者信息；但是，并不代表该用户与该业务有过交互信息。比如说用户虽然第一次访问某业务，但是这个用户访问过授权系统绑定的其他类似业务，而该业务平台也被其他类似用户访问过，这样就可以通过这些已知访问信息，推算出该用户与该业务的信任度(即后续的信任度填充)。

步骤3)在请求用户的身份认证成功的条件下，查询用户ID和业务ID之间的信任度，根据用户侧和业务侧的权限匹配，对请求用户访问访问业务进行对应权限的授权确认。

具体的第三方授权机制的工作流程参考图2：

步骤S1)授权层事先从用户层和业务层分别获取请求用户的用户ID(user_ID)，访问业务的业务ID(service_ID)以及两者之间的交互记录。

步骤S2)首先根据业务ID(service_ID)判断第三方授权系统中是否绑定了该认证平台，若暂无绑定记录，返回认证结果06(系统标识不存在)，退出认证流程。

步骤S3)然后根据用户ID(user_ID)判断第三方授权系统中是否存有请求用户的身份信息，若暂无用户信息，返回认证结果05(用户ID未开通)，用户可在完成注册、存档身份信息后重新跳转至登录界面，回到步骤S1)。

对于步骤S2)和步骤3)，基于业务平台所能提供的业务类型出发，采用先判断业务ID(service_ID)再判断用户ID(user_ID)的顺序，能节省判断时间，有效的提高认证授权效率。

步骤S4)接下来先通过SIM卡应用进行用户身份认证，通过卡应用弹窗交互反馈验证结果，当用户身份认证成功后，进行下一步用户授权。

步骤S5)判断用户ID(user_ID)和业务ID(service_ID)之间是否存在交互记录(也即访问记录)。

步骤S6)如果用户ID(user_ID)和业务ID(service_ID)之间存在交互记录，直接查询出两者之间的信任度；如果用户ID(user_ID)和业务ID(service_ID)之间不存在交互记录，通过信任填充预估出两者信任度大小。

步骤S7)最后根据用户ID(user_ID)与业务ID(service_ID)之间的信任度大小，结合两者信任阈值判断用户权限进行信任决策，从而决定是否是通过卡应用进行用户授权确认，进而建立用户的安全访问通道。如果授权成功，用户与业务平台之间通过安全通道进行信息交互访问。

在上述第三方授权机制的工作流程中，步骤S5)中的信任评估和步骤S6)中的信任决策，关系着本发明基于信任的授权机制的实现。

信任评估作为本发明第三方授权方法的核心部分，也是信任机制实现的关键。考虑到不同的业务类型与用户之间的交互方式不一样，对两者之间的信任评估准则也会有所差异。该第三方授权方法本着公平性、合理性原则，首先将现有授权业务划分为四大类，再针对每类业务设计不同的信任度计算法则，生成初始信任矩阵；其次针对不存在交互数据的用户与业务通过矩阵填充预估其信任度；然后根据估算出的信任度以及获取到的用户侧和业务侧的信任阈值，分配用户对应的业务权限，并将授权结果反馈给业务平台；最后根据当次交互行为记录更新用户与业务的信任度。

针对存在交互数据的用户与业务，初始信任矩阵中不同类型业务的信任计算分别说明如下：

第一类业务：电子商务类，以淘宝、京东为例的C2C电子商务网站。用户与此类业务之间存在大量频繁的金钱交易往来记录，并且交易双方有互评机制，这些都可以作为信任评估的重要参考。本实施例根据现有电子商务类网站的评价指标设计了以下两级五维的指标体系，表1给出了一种示例，实际操作中的评价指标需要跟业务平台协商确定。

表1电子商务类评价指标

具体信任度计算法则如下所示：

(1)利用因子分析计算维度得分。在计算信任度前，首先需要确定各个指标对用户信任度的影响方向，即确定指标是正向指标、负向指标还是适度指标。对负向指标和适度指标要转化为正向指标，负向指标可以采用取倒数或极大化的方式：或max-x，其中x为原始指标；适度指标应趋于适度值(假设为k)，则可以将指标转化为

当所有指标都转化为正向指标时，对各维度的指标进行因子分析。因子分析的主要步骤如下：

1)对原始评估指标体系进行标准化，标准化为原始指标减去平均值除以标准差，标准化的指标均值为0，方差为1，消除指标量纲和数量级的影响；

2)根据标准化的结果求相关系数矩阵；

3)求解矩阵的特征值、特征向量和方差贡献率，把累计方差贡献率作为公因子的权重；

4)根据累计方差贡献率确定公因子个数，一般选择累计方差贡献率超过85％的前T个公因子，或者选择特征值大于1的T个公因子；

5)根据每个公因子的权重对因子得分加权求和，得到每个二级指标得分。由于因子得分相对数性质不明显，可能出现负值，需要对因子得分进行归一化处理，采用逻辑函数对因子得分线性化处理。假设第i评价指标对应的因子得分为f_i，则归一化后为：

$f_i^{\′}=\frac{1}{1+e^{-f_i}}$ (公式1)

再根据各因子的权重ρ_i计算各维度得分为：

$Score=\underset{i}{\Σ}{\mathrm{\ρ}}_i\×f_i^{\′}$ (公式2)

(2)利用熵值法计算维度权重。熵是对不确定性的一种度量，一般而言信息量越大，不确定性就越小，熵也就越小；信息量越小，不确定性越大，熵也越大。根据熵的特性，本实施例可以通过计算熵值来判断某个指标的离散程度，指标的离散程度越大，说明该指标对综合评价的影响越大。

首先计算每个维度的熵值，计算公式如下：

$H_j=\frac{-\underset{k=1}{\overset{m}{\Σ}}{g}_{ij}{\ln }^{\left(g_{ij}\right)}}{{\ln }^m},s.t.g_{ij}=\frac{s_{ij}}{\underset{i=1}{\overset{m}{\Σ}}{s}_{ij}}$ (公式3)

其中m是样本数，s_ij是第i样本在j维度上的指标值。则第j维度最终的权重为：

$w_j=\frac{(1-H_j)}{\underset{i=1}{\overset{n}{\Σ}}(1-H_j)}$ (公式4)

其中n是维度的个数。最后根据维度得分和维度权重，加权求和可以得到用户i与业务j的信任度

(公式5)

第二类业务：社交类，以微博、微信、人人为例的社交类网站。此类业务主要是通过用户与业务平台的交互活跃度以及交互反馈评价彼此之间的信任度。考虑到用户对业务平台提供的服务满意则彼此更加信任，如果不满意或者发现恶意行为则更不信任。在本实施例中，根据业务平台的操作记录，若用户对业务平台的操作任务成功完成则对其肯定经验记数增加，若操作任务失败则否定经验记数增加。因此，user_i和service_j的信任度中的三个元素可以根据操作行为中肯定事件因素r_ij和否定事件因素s_ij来计算，具体计算方法如公式6表示：

(公式6)

其中，w(i)为事件权重，根据业务类型的重要程度进行设定，安全级别越高的业务所占的权重越大。在本实施例中可根据第三方认证服务绑定的业务类型将操作事件的权重分为4档：机密事件权重为4，如银行支付类涉及到金钱交易的业务；秘密事件权重为3，涉及到用户隐私权限的业务，比如加密云空间等；隐私事件权重为2，包括微博、微信及到用户隐私信息的业务；普通业务权重为1，如网页浏览等简单页面跳转业务。

阶跃函数δ(i)和是一对反函数，取值为0或者1，分别表示操作成功或者失败，定义公式7：

事件成功： $\left\{\begin{array}{c}\mathrm{\δ}\left(i\right)=1\\ \stackrel{\‾}{\mathrm{\δ}\left(i\right)}=0\end{array}\right.,$ 事件失败： $\left\{\begin{array}{c}\mathrm{\δ}\left(i\right)=0\\ \stackrel{\‾}{\mathrm{\δ}\left(i\right)}=1\end{array}\right.$ (公式7)

第三类业务：付费类业务，以视频类业务为例。此类业务通常都是用户向其账户充值或者购买一定的业务量，由其消费量决定服务权限。因此这类业务的信任度主要取决于用户的价值量估量。假设user_i在service_j平台注册后，平台反馈的初始价值量为a_ij，用户的消费累计量为q_ij，则用户的价值估量与q_ij正相关，公式8为一种示例：

(公式8)

其中b_j为递增系数，由业务平台设定。

第四类业务为自有业务，主要是企业面向内部用户开放不同权限的业务。由于此类业务用户数量不大且固定，权限设置简单。本实施例中可以采用手动配置固定权限的方案。

根据公式1-8可以计算出用户与部分业务之间的信任度。但是第三方授权系统的每个用户并不可能对绑定的每个业务都有交互记录，也就意味着依靠公式1-8不能生成完备的信任度集合。针对上述四类业务，除了第四类自有业务外，每类业务类型对应一个信任度矩阵。

本实施例在信任度计算过程中充分考虑到授权业务的差异，按照服务类型设计了不同的信任计算法则，同类型业务之间体现了竞争性，不同类型业务之间又体现了差异性，兼顾了公平性和合理性。

针对不存在交互记录数据的用户与业务，基于初始信任矩阵的信任矩阵填充说明如下：

如表2的信任度矩阵所示，假设针对某业务类型，第三方授权系统绑定了m个用户和n个业务，即共有m个用户ID和n个业务ID，每个用户i和业务j之间通过彼此的信任度关联，如果把所有信任度列成一张大表，可以得到矩阵M'∈R^m×n。

表2信任度矩阵

可以想象，由于不可能做到每个用户对所有的业务平台都有操作的交互记录，因而这个张量中只有少部分元素是已知的，即初始信任度张量M'是稀疏的。

本实施例利用推荐系统中协同滤波技术，基于矩阵的迹范数，根据矩阵中的已知观测数据元素推测出未知项的信任度估计值。假设M'∈R_m×n是上述要预估的信任度矩阵，{M'_ij,(i,j)∈Ω}是M'中已知的矩阵元素的集合。一般来讲，从矩阵部分元素准确预估其全部元素基本就是不可能完成的任务。即使只有一个元素未知，这个矩阵也不可能唯一。但是根据矩阵填充理论，通过加入一些约束条件进行优化，可以期望预估矩阵中的绝大多数元素。在本实施例的第三方授权方法中，经过分类后每个类别下的业务平台数量m<<用户数量n，加之实际影响用户与业务之间信任度的因素往往只有少数几个，因此信任度矩阵M'是一个低秩矩阵，rank(M')＝r,r＝m。要预估一个低秩矩阵，可以先将其转化为求解矩阵秩的最小化问题，即公式9：

$\begin{array}{cc}{\min }_{\tilde{M}}rank\left(\tilde{M}\right)& s.t.{\tilde{M}}_{ij}={M^{\&prime;}}_{ij},(i,j)\&Element;\mathrm{\&Omega;}\end{array}$ (公式9)

其中是预估矩阵的秩。设P_Ω()表示在子集Ω上的投影映射，即公式10：

$P_{\mathrm{\&Omega;}}\left(M\right)=\left\{\begin{array}{cc}{M^{\&prime;}}_{ij},& (i,j)\&Element;\mathrm{\&Omega;}\\ 0,& (i,j)\&Element;\mathrm{\&Omega;}\end{array}\right.$ (公式10)

这样，可将公式9改写为：

$\begin{array}{ccc}{\min }_{\tilde{M}}rank\left(\tilde{M}\right)& s.t.& P_{\mathrm{\&Omega;}}(\tilde{M}-M^{\&prime;})=0\end{array}$ (公式11)

从公式11来看，矩阵预估的本质是找到这么一个矩阵使得其在已有的数据上和信任度尽可能的一致，同时具有比较低的秩。其中对于秩的约束，是为了降低模型自身的复杂度。

针对公式11，可以利用二范数等条件约束，将求解问题进一步简化。受到压缩感知理论的启发，目前国际上最前沿的做法是将迹范数或核范数最小化方法应用于矩阵填充问题。定义矩阵M的迹范数||M||_tr(tracenorm)为矩阵奇异值σ_i(M)之和，即有：

$\left|\right|M|{|}_{tr}=\underset{i}{\&Sigma;}{\mathrm{\&sigma;}}_i\left(M\right)$ (公式12)

矩阵的秩(rank)相当于这个矩阵奇异值σ_i(M)的0范数；矩阵的迹范数相当于σ_i(M)的1范数。为此，如果这个矩阵足够稀疏，则可参照向量的稀疏表示，利用矩阵的迹范数代替矩阵的秩(rank)。则可将要解决的问题改为公式13：

$\begin{array}{ccc}{\min }_{\tilde{M}}\left|\right|\tilde{M}|{|}_{tr}& s.t.& P_{\mathrm{\&Omega;}}(\tilde{M}-M)=0\end{array}$ (公式13)

从数学意思上讲，假设初始信任矩阵M，公式13的目标是估算出一个新矩阵尽可能逼近于M(s.t.后的约束条件)，同时其的迹范数最小。由于迹范数是凸的，上式是一个凸优化问题，故而必有唯一的最优解。本实施例采用的是奇异值阈值(SingularValueThresholding)算法。这个算法受到压缩感知中Bregman迭代算法的启发，在迭代过程中对矩阵进行奇异值分解，然后将较小的奇异值设为0，生成新的矩阵进行迭代。

在第三方授权机制中，信任决策过的过程中主要根据用户对业务的信任度大小进行不同权限级别的服务。每个业务平台根据自身业务需求设置不同的信任阈值等级Φ，每个等级定义不同的业务权限。每个用户根据自身的安全需求针对各个业务设置阈值θ，信任度超过这个阈值则用户认为可以安全访问业务平台。假设通过授权系统计算出的user_i和service_j的信任度为service_j设置的信任阈值为共计m个等级(LoA1～LoAm)的服务，user_i对service_j的信任阈值为θ_ij。当则service_j可以对user_i提供第k级别以下(LoA1～LoAk)的所有类型服务。假设用户当前时刻申请的服务请求类型级别为LoAi，存在以下几类行为决策：

1.当i≤k且业务平台可以提供用户请求的服务类型，用户也可以接受业务平台的服务，用户与业务平台之间通过安全通道进行信息交互和访问；

2.当i≤k且业务平台可以提供用户请求的服务类型，用户却认为业务平台的服务不够安全，第三方授权系统向用户卡应用发送授权请求(如XX网站存在安全隐患，是否继续访问)，再根据用户反馈决定是否接受业务平台的服务；

3.当i>k且业务平台认为用户不具备该服务请求权限，而用户对业务平台充分信任，第三方授权系统向用户卡应用发送授权请求(如您当前等级不够，是否支付XX元担保金完成服务)，再根据用户反馈决定是否提供业务平台的服务；

4.当i>k且业务平台认为用户不具备该服务请求权限，而用户对业务平台也不够信任，终止用户与业务平台之间的服务请求。

本实施例在设计信任计算法则以及信任决策时都充分考虑到了用户和业务平台的互信机制，如果两者之间的信任度超过彼此的信任阈值都需要再次进行卡应用授权确认才能完成最终的授权。这种第三方授权方法机制的设计有效保护了两者的共同利益，提高认证授权业务的安全性和便携性。

当然，进一步完成第三方授权机制中的信任矩阵，优选在每一用户服务完成后，业务平台将服务完成情况返回给第三方授权系统用以定期更新数据库中的信任度信息，也即进行用户与业务二者之间的信任更新。例如在第二类业务中，假设用户user_i成功访问业务service_j并且成功完成当次服务任务，则在user_i和service_j的信任度计算中，增加肯定事件因素r_ij，提高信任度。如果访问失败或者成功访问后任务完成失败，则在user_i和service_j的信任度计算中，增加否定事件因素s_ij，降低信任度。

相应的，本实施例还提供了一种基于信任评估的第三方授权系统，如图3所示，第三方授权系统采用三层架构设计，包括用户层31、业务层32和授权层33。另外，第三方授权系统针对三层架构各自的职能分工提供不同类型的对外接口。利用中间授权层33的隔离对用户信息和业务信息进行分类存储和管理，在授权过程中只对彼此交互记录数据进行调用，不涉及到其他业务或者用户信息，从而有效保证授权的安全性和公平性。与此同时，通过用户与业务之间的信任度进行业务权限的分配，以实现可信性、安全性和便携性的权衡。

用户层31主要涉及与用户相关的信息，用于对用户身份信息的管理以及与用户移动终端的交互，主要包括卡应用管理、用户ID管理以及身份数据库。卡应用管理模块负责管理用户终端卡应用，包括应用推送、激活、PIN码重置等；用户ID管理负责对用户进行ID匹配，每个用户与ID属于一一映射的关系，在第三方授权系统中用户ID为其电话号码；每个ID对用着此用户的身份数据，以用户ID为索引，将这些用户的身份数据按照固定的格式存储，生成身份数据库。

业务层32主要涉及与业务相关的信息，负责对授权业务进行管理和监控。主要包括操作记录、业务管理、ID管理和IP管理等模块。操作记录主要负责记录用户每次访问请求的完成情况，包括访问时间、访问时长、用户ID、业务ID、访问成功或失败等信息；业务管理主要是对业务平台进行业务监管，防止用户在访问互联网业务时存在安全隐患；ID管理负责对业务ID进行匹配、业务类型码对应的权限阈值管理等，每个业务对应唯一业务ID，与服务提供商无关，例如腾讯微博和腾讯新闻属于两个不同的业务ID；IP管理负责为每个业务分配并管理IP地址。

授权层33为中间层，主要实现两大功能，一类是通过信任评估方法估算出用户与访问业务的信任度，另一类是通过身份认证、信任调用以及权限匹配完成访问业务对用户身份的鉴权管理。在身份认证中第三方授权系统需要与用户终端进行不同等级的行为交互：比如在SIM卡应用弹窗中点击确认、输入PIN码、输入密码或者指纹识别等；信任调用即授权系统根据业务ID从业务层中提取出该ID的业务类型码以及对应的权限阈值，根据用户ID从用户层中该提取出该ID用户对应的权限阈值；最后结合信任评估计算出的用户与该访问业务的信任度，结合业务ID和用户ID对应的权限阈值进行权限匹配。这里的用户终端可以为SIM卡、短信验证码、USSID等方式，出于安全性考虑，优选采用SIM卡应用，采用SIM卡应用弹窗、机卡交互技术进行与用户身份认证相关操作的交互，这种交互方式的安全性最高，但是对SIM卡类型和手机终端有一定要求(比如应该为开源卡或能预置卡应用，且SWP卡、JAVA卡和Native卡相应的卡应用不同)。在实际应用中，可根据实际情况对各种交互方式进行灵活选用，这里不做限定。

这里应该理解的是，业务平台不属于第三方授权系统，业务平台主要是例如携程、淘宝之类的第三方网站。用户、业务平台和第三方授权系统是三个独立的个体，第三方授权系统中的业务层和用户层主要负责与用户和业务平台的交互。

优选的是，第三方授权系统中的授权层33包括信任度查询模块和信任度计算模块，其中：

信任度查询模块，用于查询用户ID和业务ID之间的信任度；

信任度计算模块，用于计算用户ID和业务ID之间的交互记录的信任度，对不同类业务根据不同的信任度计算法则，生成初始信任矩阵，初始信任矩阵包括多个用户与多个业务平台之间的信任度；信任度计算模块至少包括电子商务类业务子模块、社交类业务子模块和付费类业务子模块中的任一种，其中：

电子商务类业务子模块中，用户与业务平台的信任度的计算法则为：

n为维度的个数，w_j为第j维度的维度权重，Score_j为第j维度的维度得分；

社交类业务子模块中，用户与业务平台的信任度的计算法则为：

r_ij为肯定事件因素，s_ij为否定事件因素，w(i)为事件权重；

付费类业务子模块中，用户与业务平台的信任度E_ij的计算法则为：

E_ij＝a_ij+b_jq_ij,s.t.b_j>0

a_ij为业务平台反馈的初始价值量，q_ij为用户的消费累计量，b_j为由业务平台设定的递增系数。

针对不存在交互数据的用户与业务，基于初始信任矩阵的信任填充，授权层还包括信任度矩阵填充模块，用于通过最小化初始信任矩阵M的迹范数预估请求用户ID与业务ID之间的信任度，信任度矩阵填充模块的矩阵预估法则为：

$\begin{array}{ccc}{\min }_{\tilde{M}}\left|\right|\tilde{M}|{|}_{tr}& s.t.& P_{\mathrm{\&Omega;}}(\tilde{M}-M)=0\end{array}.$

在第三方授权机制中，授权层还包括授权模块，授权模块用于根据用户侧和业务侧的权限匹配，对请求用户访问访问业务进行对应权限的授权确认，包括：

若用户ID和业务ID之间的信任度为访问业务的信任阈值为这里的m为信任等级对应的服务数量，当这里的k为业务平台能提供的服务类型级别，则访问业务对请求用户提供第k级别以下的所有类型服务；

用户ID对业务ID的信任阈值为θ_ij，当请求用户当前时刻申请的业务类型级别为第i级别，则授权行为决策包括：

1)当i≤k且业务平台能提供用户请求的服务类型，用户也可以接受业务平台的服务，用户与业务平台之间通过安全通道进行信息交互和访问；

2)当i≤k且业务平台能提供用户请求的服务类型，用户却认为业务平台的服务不够安全，第三方授权系统向用户卡应用发送授权请求，再根据用户反馈决定是否接受业务平台的服务；

3)当i>k且业务平台认为用户不具备该服务请求权限，而用户对业务平台充分信任，第三方授权系统向用户卡应用发送授权请求，再根据用户反馈决定是否提供业务平台的服务；

4)当i>k且业务平台认为用户不具备该服务请求权限，而用户对业务平台也不够信任，终止用户与业务平台之间的服务请求。

相应的，授权层还包括信任度更新模块，信任度更新模块用于根据当次交互行为记录更新请求用户与业务平台之间对应的访问业务的交互记录的信任度。在每一用户服务完成后，业务平台将服务完成情况返回给第三方授权系统用以定期更新数据库中的信任度信息，也即进行用户与业务二者之间的信任更新。例如在第二类业务中，假设用户user_i成功访问业务service_j并且成功完成当次服务任务，则在user_i和service_j的信任度计算中，增加肯定事件因素r_ij，提高信任度。如果访问失败或者成功访问后任务完成失败，则在user_i和service_j的信任度计算中，增加否定事件因素s_ij，降低信任度。

为便于理解，针对本实施例的第三方授权方法及其相应的第三方授权系统，列举几种常用场景如下：

场景1：用户登录视频网站观看视频A，该视频网站将服务请求发送给第三方授权系统。第三方授权系统根据用户与视频网站的信任度判定该用户级别无权限观看视频A，故向用户卡应用发送授权确认请求：“对不起，您的等级无法免费观看此视频，如需继续观看请付费XX元”。待用户点击确认并完成支付则完成授权，点击取消则此次服务请求结束。

场景2：用户在POS机刷卡，银行将服务请求发送给第三方授权系统。平台根据用户在该银行的交易记录等判断信任度，给予用户该笔交易的权限。但是用户自身的信用卡有单次额度限制，故第三方授权系统向用户卡应用发送授权确认请求：“对不起，您的单次消费额度不得高于XX元，如需继续交易请确认”。待用户点击确认则完成交易授权，点击取消则此次服务请求结束。

本发明中的第三方授权方法及其第三方授权系统，基于信任评估的方法，引入信任计算、信任填充和信任决策的第三方授权机制将现有孤岛式授权方法进行整合，由授权系统作为权威机构统一保管用户身份数据，并采用基于手机SIM卡应用的授权方式，完成用户访问权限的分配和授权确认，业务平台既做到了用户资源的真正共享，又无需建设自己的身份认证系统；并且，业务平台调用的是授权结果，而无法真正接触到用户的身份的数据，有效保护了用户隐私性。

可以理解的是，以上实施方式仅仅是为了说明本发明的原理而采用的示例性实施方式，然而本发明并不局限于此。对于本领域内的普通技术人员而言，在不脱离本发明的精神和实质的情况下，可以做出各种变型和改进，这些变型和改进也视为本发明的保护范围。

Claims (10)

1.一种第三方授权方法，其特征在于，包括步骤：

获取请求用户的用户ID、访问业务的业务ID以及所述请求用户与所述访问业务两者之间的交互记录；

在第三方授权系统中已绑定所述访问业务，且存有所述请求用户的身份信息的条件下，通过所述请求用户的身份认证；

在所述请求用户的身份认证成功的条件下，查询所述用户ID和所述业务ID之间的信任度，根据用户侧和业务侧的权限匹配，对所述请求用户访问所述访问业务进行对应权限的授权确认。

2.根据权利要求1所述的第三方授权方法，其特征在于，如果所述用户ID和所述业务ID之间存在交互记录，直接查询出所述请求用户与所述访问业务两者之间的信任度；

在查询出所述请求用户与所述访问业务两者之间的信任度之前，包括计算所述用户ID和所述业务ID之间的交互记录的信任度的步骤，具体为：

针对所述请求用户对所述访问业务的类型，对不同类型业务根据不同的信任度计算法则生成初始信任矩阵，所述初始信任矩阵包括多个用户与多个业务平台之间的信任度；业务类型至少包括电子商务类业务、社交类业务和付费类业务中的至少一种，其中：

所述电子商务类业务的用户与所述业务平台的信任度为：

n为维度的个数，w_j为第j维度的维度权重，Score_j为第j维度的维度得分；

所述社交类业务的用户与所述业务平台的信任度为：

$s.t.\left\{\begin{array}{c}{r}_{ij}=\underset{k=0}{\overset{n}{\mathrm{\&Sigma;}}}\mathrm{\&delta;}\left(i\right)\&CenterDot;w\left(i\right)\\ s_{ij}=\underset{k=0}{\overset{n}{\mathrm{\&Sigma;}}}\stackrel{\&OverBar;}{\mathrm{\&delta;}\left(i\right)}\&CenterDot;w\left(i\right)\end{array}\right.$

r_ij为肯定事件因素，s_ij为否定事件因素，w(i)为事件权重；

所述付费类业务的用户与所述业务平台的信任度为：

a_ij为所述业务平台反馈的初始价值量，q_ij为用户的消费累计量，b_j为由所述业务平台设定的递增系数。

3.根据权利要求2所述的第三方授权方法，其特征在于，如果所述用户ID和所述业务ID之间不存在交互记录，根据所述初始信任矩阵M，利用：

$\begin{array}{ccc}{\min }_{\tilde{M}}\left|\right|\tilde{M}|{|}_{tr}& s.t.& P_{\mathrm{\&Omega;}}(\tilde{M}-M)=0\end{array}$

通过最小化所述初始信任矩阵的迹范数预估所述初始信任矩阵中的缺失项，从而获得所述请求用户与所述业务平台之间的信任度，然后查询出所述请求用户与所述访问业务两者之间的信任度，其中，为预估信任矩阵。

4.根据权利要求1所述的第三方授权方法，其特征在于，根据用户侧和业务侧的权限匹配，对所述请求用户访问所述访问业务进行对应权限的授权确认包括：

若所述用户ID和所述业务ID之间的信任度为所述访问业务的信任阈值为这里的m为信任等级对应的服务类型数量，当这里的k为所述业务平台能提供的服务级别，则所述访问业务对所述请求用户提供第k级别以下的所有类型服务；

所述用户ID对所述业务ID的信任阈值为θ_ij，当所述请求用户当前时刻申请的业务类型级别为第i级别，则授权行为决策包括：

1)当i≤k且所述业务平台能提供用户请求的服务类型，用户也可以接受所述业务平台的服务，用户与所述业务平台之间通过安全通道进行信息交互和访问；

2)当i≤k且所述业务平台能提供用户请求的服务类型，用户却认为所述业务平台的服务不够安全，第三方授权系统向用户卡应用发送授权请求，再根据用户反馈决定是否接受所述业务平台的服务；

3)当i>k且所述业务平台认为用户不具备该服务请求权限，而用户对所述业务平台充分信任，第三方授权系统向用户卡应用发送授权请求，再根据用户反馈决定是否提供所述业务平台的服务；

4)当i>k且所述业务平台认为用户不具备该服务请求权限，而用户对所述业务平台也不够信任，终止用户与所述业务平台之间的服务请求。

5.根据权利要求1所述的第三方授权方法，其特征在于，对所述请求用户访问所述访问业务进行对应权限的授权确认之后，还进一步包括：根据当次交互行为记录更新所述请求用户与所述业务平台之间对应的访问业务的交互记录的信任度。

6.一种第三方授权系统，其特征在于，包括用户层、业务层和授权层，所述用户层与所述业务层通过所述授权层隔离，其中：

所述用户层，用于对用户身份信息的管理以及与用户移动终端的交互，包括卡应用管理、用户ID管理以及身份数据库；

所述业务层，用于对授权业务进行管理和监控，包括操作记录、业务管理、业务ID管理、IP管理和IP地址分配；

所述授权层，用于计算用户与访问业务的信任度，并通过身份认证、信任调用以及权限匹配完成访问业务对所述请求用户的鉴权管理。

7.根据权利要求6所述的第三方授权系统，其特征在于，所述授权层包括信任度查询模块和信任度计算模块，其中：

所述信任度查询模块，用于查询所述用户ID和所述业务ID之间的信任度；

所述信任度计算模块，用于计算所述用户ID和所述业务ID之间的交互记录的信任度，对不同类业务根据不同的信任度计算法则，生成初始信任矩阵，所述初始信任矩阵包括多个用户与多个所述业务平台之间的信任度；所述信任度计算模块至少包括电子商务类业务子模块、社交类业务子模块和付费类业务子模块中的任一种，其中：

所述电子商务类业务子模块中，用户与所述业务平台的信任度的计算法则为：

n为维度的个数，w_j为第j维度的维度权重，Score_j为第j维度的维度得分；

所述社交类业务子模块中，用户与所述业务平台的信任度的计算法则为：

$s.t.\left\{\begin{array}{c}{r}_{ij}=\underset{k=0}{\overset{n}{\mathrm{\&Sigma;}}}\mathrm{\&delta;}\left(i\right)\&CenterDot;w\left(i\right)\\ s_{ij}=\underset{k=0}{\overset{n}{\mathrm{\&Sigma;}}}\stackrel{\&OverBar;}{\mathrm{\&delta;}\left(i\right)}\&CenterDot;w\left(i\right)\end{array}\right.$

r_ij为肯定事件因素，s_ij为否定事件因素，w(i)为事件权重；

所述付费类业务子模块中，用户与所述业务平台的信任度E_ij的计算法则为：

E_ij＝a_ij+b_jq_ij,s.t.b_j>0

a_ij为所述业务平台反馈的初始价值量，q_ij为用户的消费累计量，b_j为由所述业务平台设定的递增系数。

8.根据权利要求7所述的第三方授权系统，其特征在于，所述授权层还包括信任度矩阵填充模块，用于通过最小化所述初始信任矩阵M的迹范数预估所述初始信任矩阵中的缺失项，从而获得所述请求用户ID与所述业务ID之间的信任度，所述信任度矩阵填充模块的矩阵预估法则为：

$\begin{array}{ccc}{\min }_{\tilde{M}}\left|\right|\tilde{M}|{|}_{tr}& s.t.& P_{\mathrm{\&Omega;}}(\tilde{M}-M)=0\end{array}$

其中，为预估信任矩阵。

9.根据权利要求6所述的第三方授权系统，其特征在于，所述授权层还包括授权模块，所述授权模块用于根据用户侧和业务侧的权限匹配，对所述请求用户访问所述访问业务进行对应权限的授权确认，包括：

若用户ID和业务ID之间的信任度为访问业务的信任阈值为这里的m为信任等级对应的服务数量，当这里的k为所述业务平台能提供的服务类型级别，则所述访问业务对所述请求用户提供第k级别以下的所有类型服务；

用户ID对业务ID的信任阈值为θ_ij，当所述请求用户当前时刻申请的业务类型级别为第i级别，则授权行为决策包括：

1)当i≤k且所述业务平台能提供用户请求的服务类型，用户也可以接受所述业务平台的服务，用户与所述业务平台之间通过安全通道进行信息交互和访问；

2)当i≤k且所述业务平台能提供用户请求的服务类型，用户却认为所述业务平台的服务不够安全，第三方授权系统向用户卡应用发送授权请求，再根据用户反馈决定是否接受所述业务平台的服务；

3)当i>k且所述业务平台认为用户不具备该服务请求权限，而用户对所述业务平台充分信任，第三方授权系统向用户卡应用发送授权请求，再根据用户反馈决定是否提供所述业务平台的服务；

4)当i>k且所述业务平台认为用户不具备该服务请求权限，而用户对所述业务平台也不够信任，终止用户与所述业务平台之间的服务请求。

10.根据权利要求6所述的第三方授权系统，其特征在于，所述授权层还包括信任度更新模块，所述信任度更新模块用于根据当次交互行为记录更新所述请求用户与所述业务平台之间对应的访问业务的交互记录的信任度。