通过第三方的身份认证系统和方法

文档序号:7917438阅读:504来源:国知局
专利名称:通过第三方的身份认证系统和方法
技术领域
本发明涉及一种通过第三方的身份认证系统和方法。
背景技术
互联网提供的资源和服务的数量非常巨大并增长迅猛,互联网已经成为人们获 取信息资源和信息服务的主要渠道,许多网上资源和服务要求用户进行登录和验 证,这就出现了一些问题。首先,每个网络资源都采用不同的登录信息,登录信息 繁多难记。其次,简单的用户名加密码的方式也存在着安全性太低的问题,满足不 了很多网上应用的需要。 一些对用户来说重要的资源和服务,如网络游戏帐号、 电子商务帐号等等,常常面临着网上安全性不足的困扰。
通过第三方的认证方法是一种解决以上问题的有效途径,但是现有的第三方认 证的解决方案都存在一些缺陷。
例如,有的解决方案是用户将在网上资源的用户名和密码保存在一个固定的网 上认证服务方,用户登录该网上资源时由网上认证服务方以用户的用户名和密码自 动完成网上资源的登录,这种方式虽然便捷,但是仍然采用固定不变的用户名和密 码的方式向网上资源登录,安全性得不到保证。
又例如,有的解决方案采用终端用户在通过网上认证服务方的身份认证后,发 送一个基于时间有效期的用户认证确认信息保存在用户终端的COOK正中。这种方 式里由于在有效期内认证确认信息是相同的,导致认证确认信息可能被盗用,如 无法防止同一 IP或同一终端的重放攻击。而且,这类解决方案在有些禁用COOKIE 的终端环境里无法使用。另外,这类解决方案还要求网上资源进行数字摘要验证计 算,对于中小型服务商的服务设备也是不小的负荷压力。
再例如,有的解决方案通过其它通信终端进行认证,如釆用向用户即时通讯 终端发送一个认证信息再由网络终端返回的方式。但是在这种方式里,用户的其它 通信终端(如QQ)不能自动识别认证信息从而主动参与传递过程,因此,认证 号码的传递不能由计算机和网络完成而需要经过用户本人,需要用户进行再输入或 拷贝粘贴的工作,具有繁琐、容易出错、安全性不高的缺陷。

发明内容
本发明采用一种通过第三方的身份认证系统和方法,来解决以上提到的问題。 本发明是这样实现的, 一种通过第三方的身份认证系统和方法,其中,三个系 统分别连接于同一网络,三个系统分别为服务方、请求方和第三方,其中,服务方 对请求方的认证要通过第三方来完成,其中,当请求方向服务方请求接入认证时, 所述三方能够完成以下步骤 一方获取认证信息并发起在以上三方之间的源于该认 证信息的闭合传递,其中另外两方上运行的程序能够自动识别闭合传递的信息和路 径并响应完成该闭合传递,其中,以上三方中的闭合传递的终点能够验证收到的信 息是否起源于闭合传递的起点,只有当收到的信息起源于闭合传递的起点时认证才 能通过。
其中,所述同一网络为互联网。
其中,只有当请求方通过第三方的认证时,第三方才会参与完成该闭合传递。 其中,只有当服务方通过第三方的认证后,第三方才会参与完成该闭合传递。 其中,所述闭合传递的路径由三个系统中每两者之间的信息传递组成,具体为: 闭合传递的起点和终点是同一方,首先一方向另一方发出信息,然后另一方向最后 一方发出信息,然后最后一方向第一方返回信息,完成闭合传递;或者,闭合传递 的起点和终点不是同一方,首先一方分别向其它两方分别发出信息,然后其它两方 中的一方向另一方发出信息,从而完成闭合传递。
其中,在所述闭合传递中,在从一方至另一方传递时闭合传递的信息的内容是 不变的。闭合传递的信息不能是数据包报头中的IP地址和端口号,因为例如其中 一方处于NAT后,则其应用程序对象的内网IP地址和端口号在NAT处理后会映射 为外网IP地址和端口号。
其中,不同的服务方能够通过同一第三方对同一请求方进行认证。 其中,所述的三方之间的源于该认证信息的闭合传递是指所传递的信息是相同 的或者所传递的信息是不同的并符合特定数学计算的对应规律。
其中,在所述闭合传递中,传递的信息就是认证信息本身,这时,闭合传递的 终点验证收到的信息与发出的认证信息是否一致或者收到的两个信息是否一致,如 果一致则证明收到的信息起源于闭合传递的起点。这时,闭合传递中每两者之间传 递的信息都是相同的,都是认证信息。其中,认证信息可以是由任何符号组成的序
5列。例如认证信息可以是由一随机函数生成的随机数。
或者,在所述闭合传递中,传递的信息中至少有一个信息不是认证信息,该信 息是由一方或两方基于认证信息生成的,这时,闭合传递的终点能够验证收到的信 息是否是基于认证信息生成的或者收到的两个信息是否是基于同一认证信息生成 的,如果是基于认证信息生成的或者是基于同一认证信息生成的则证明收到的信息 起源于闭合传递的起点。这时,闭合传递中每两者之间传递的信息不都是相同的。 例如当闭合传递的起点和终点不是同一方时,认证信息可以是随机生成的符合特 定规律的一对数字,闭合起点方将这对数字中的两个分别发给其余两方,闭合终点 方通过验证得到的两个数字是否符合特定规律来判断收到的两个信息是否是起源 于同一认证信息的。又如认证信息可以是一随机序列, 一方收到该认证信息后以 约定算法计算其单向散列值并将散列值发往闭合传递的终点。再如认证信息可以 是密钥、单向散列函数或其它函数, 一方收到该认证信息后将约定值以该密钥、单 向散列函数或其它函数进行计算后发给闭合终点,闭合终点通过对约定值验算来判 断该方的信息是否起源于闭合传递的起点。
其中,在所述闭合传递中,三方中任意两者之间的信息传递路径不经过三方中 的其余一方。
其中,在所述闭合传递中,由请求方发出的每个信息只用于一次认证,由请求 方发出的每个信息无法由请求方先前发出的信息推知。
其中,所述闭合传递的过程是由所述三个系统上运行的程序通过计算机网络完 成的,传递路径中不包括系统的用户,系统的用户不需要知道传递信息的内容,系 统的用户不需要参与传递的过程。
其中,服务方为通过互联网向用户提供资源和服务的计算机系统,请求方为用 户使用的连接于互联网的具有计算机功能的终端设备,第三方为能够通过互联网对 请求方的用户进行身份认证的计算机系统,其中,只有请求方的用户通过了服务方 的身份认证时服务方才向请求方提供资源和服务,服务方对用户的身份认证是通过 第三方来完成的。
其中,请求方可以为PC终端、手机终端等,服务方和第三方可以是服务器或
服务器群组。
其中,服务方和请求方也可以是使用第三方服务的用户终端。例如,本发明可用于即时通讯系统中两个用户终端通过即时通讯系统建立两个终端间点对点连接 的握手过程,如第三方是一个即时通讯服务方,服务方和请求方是该即时通讯服 务的用户,其中,当服务方需要向请求方发送文件或者请求方需要与服务方建立对 话连接时,服务方或请求方可以生成一个认证信息并分别直接和通过第三方发送给 对方,收到认证信息的请求方或服务方验证收到的认证信息以判断对方的连接认证 是否通过。
其中,在所述闭合传递中,当一方生成认证信息时或者当闭合传递终点一方收 到第一个信息时还会生成时间标记,只有当闭合传递终点一方收到信息或者收到第 二个信息的时间未超过规定有效期时,认证才会通过。例如当服务方是闭合传递 的起点和终点时,服务方在生成认证信息时会对当前系统时间进行标记,当信息经 过闭合传递返回时服务方会对比返回时间和生成时间,只有当时间差小于规定值是 认证才能通过。又如当请求方是闭合传递的起点而服务方是闭合传递的终点时, 服务方会对比收到第一个信息和第二个信息的时间差,只有当时间差小于规定值是 认证才能通过。
其中,所述三个系统是相互独立的,三者分别独立运营,三者分别独立地连接 于互联网,三者不属于同一独立实体,三者之间不具有归属关系,三者中任何一方 对另一方的系统权限不拥有管理权或控制权。
其中,请求方用户在服务方系统中具有用户识别码(APID),请求方用户在第 三方系统中也具有用户识别码(AUID), APID与AUID存在对应关系。其中,该 对应关系由服务方系统或者第三方系统所掌握。其中,所述用户识别码是由任何符 号组成的序列。
其中,所述服务方为多个, 一个请求方用户可以在几个应用服务系统上分别拥 有几个不同的APID,这些APID可以对应于该用户在同一个第三方系统上的同一 个AUID。
其中,所述第三方系统为一个或多个, 一个请求方用户可以分别在几个第三方 系统上拥有AUID,这些AUID可以对应于该用户在同一个服务方系统上的同一个 APID。
其中,三方中每两者之间通讯信路可以是加密的,如采用SSL方式建立的连接。 其中,所述同一网络的连接方式包括有线方式和无线方式。其中,为防止恶意爆发登陆请求等问题,服务方可以在通过第三方对请求方用 户进行身份认证前先以登陆密码对请求方用户进行一次认证。
其中,所述闭合传递的终点是服务方或第三方,其中,当第三方是闭合传递的 终点的时候,第三方需要将认证的结果通知服务方。
其中,所述认证信息是由一方在发起闭合传递时即时生成的或者是预先生成即 时获取的。
其中,所述闭合传递的信息不是数据报头中的IP地址和端口号。所述闭合传递
的信息不依赖于IP地址和端口号,这就提供了更好安全性,同时更好地解决NAT 穿透等问题。
其中,在所述闭合传递进行之前或进行的同时,请求方会直接向服务方或通过 第三方向服务方发出连接请求,该连接请求可以是由所述闭合传递的信息完成或者 是爽悉独的步骤和信息完成。
其中,在认证通过后服务方允许请求方接入的端口或连接就是所述闭合传递中 请求方与服务方进行信息传递的端口或连接。例如请求方为一 NAT网关内的局 域网用卢,请求方通过NAT分配的端口 P与服务方进行所述闭合传递中的信息传 递,认证通过后服务方就会允许端口P接入指定的服务或资源。
其中,请求方与服务方之间的信息传递是通过互联网进行的。服务方与第三方 之间的信息传递是通过互联网或不通过互联网进行的。请求方与第三方之间的信息 传递是通过互联网或不通过互联网进行的。
本发明的内容是关于第三方如何向服务方传递请求方的认证凭证,而第三方对 请求方进行身份认证的方式则可结合采用任何可行的方式,例如简单的用户名和 密码的方式,对称密钥或非对称密钥认证的方式,动态密码的方式,单向函数计算 的方式,采用生物特征进行认证的方式、可移动式IC芯片的方式、通过用户的其 它通信终端进行认证的方式、SIM卡识别等等,具体的方法不限于以上列出的方式, 而且也可以是几种方式的组合。
本发明采用起源于认证信息的闭合传递的方式来传递第三方对请求方的认证 凭证给服务方,服务方通过比较收到的信息是否相匹配来判断认证是否通过。这个 方案具体实现方式多样、对服务方的工作负荷小、程序简单且容易实现。而且,闭 合传递的信息不依赖于IP地址和端口号,提供更好安全性的同时可以更好地解决NAT穿透等问题。


图1是实施例1的信息传递路径图; 图2是实施例2的信息传递路径图; 图3是实施例3的信息传递路径图; 图4是实施例4的信息传递路径图; 图5是实施例5的信息传递路径图; 图6是本发明一种典型的网络结构图。
具体实施方式
, 实施例l
图1是实施例1的信息传递路径图,本实施例的网络结构请见图6。 实施例1中闭合传递的信息是相同的一个认证信息而且闭合传递的起点与终点 相同。在本实施例中,请求方为用户网络终端,服务方为一网络资源,第三方为在 互联网上提供第三方身份认证服务的认证服务系统,认证信息为一随机数。 实施例1包括以下步骤
1) 用户网络终端通过认证服务系统的身份认证;
2) 用户网络终端向网络资源请求服务;
3) 网络资源生成一随机数和时间标记;
4) 网络资源将随机数、网络资源URL、用户标识发送给认证服务系统;
5) 认证服务系统根据用户标识将随机数和网络资源URL发送给用户网络 终端;
6) 用户网络终端根据网络资源URL将随机数返回给网络资源;
7) 网络资源对比自己生成的随机数和从用户终端返回的随机数,如果随机 数相同而且未超过规定的时间有效期则用户通过身份认证;
用户标识是指用户的APID或AUID。
在本实施例中,用户网络终端上的一个应用程序可以与认证服务系统建立安全 连接。在能通过认证服务系统的身份认证情况下,该应用程序可以完成以下步骤 该应用程序通过安全连接收到来自认证服务系统的随机数和网络资源URL;该应用程序在终端上运行的浏览器对象中寻找与网络资源URL相同的,如果没有找到就 生成一个新浏览器对象;该应用程序使找到的或新生成的浏览器对象向网络资源 URL发送连接请求并将随机数添加到的该连接请求中,如将随机数加到连接请求 的表单中。
在本实施例中,步骤l)也可以移动至步骤4)和步骤5)之间来执行,这时, 用户网络终端可以将用户的身份认证信息在步骤4)中一起发给认证服务系统,认 证服务系统确认用户的身份无误后再执行步骤5)。
本实施例可以结合即时通讯工具方便地实现。例如,可以在即时通讯工具(如 MSN、 Yahoo Messenger或QQ)的客户端软件上增加一个能够识别认证信息路径并 执行认证信息转发的模块,再在网络资源提供方的服务器端增加一个可以生成并发 送认证信息、从接入请求中提取认证信息并进行比对的软件模块,这样就可以构成 了本实施例。其中,网络资源和客户端软件都可以由即时通讯工具提供方来开发和 提供,网络资源和客户下载就可以使用,非常方便可行。
另外,本实施例还可以通过增加浏览器工具项的方式来实现,也可以通过在网 络终端执行一个专门程序来实现。
在本实施例中,在网络资源生成随机数前还可先以用户名和密码的方式对用户 进行一次认证,以避免恶意登陆攻击。
在本实施例中,网络资源可以在登录页面上设置一个针对本实施例登录方式的 选项或按键,当用户选择此选项或按键时就发起本实施例的登录流程。
在本实施例中,请求方是在步骤2)通过一个单独的信息和步骤向瓶务方请求 接入认证的。
本实施例中,闭合传递的流程为服务方一(认证信息)一第三方一(认证信 息)一请求方—(认证信息)一服务方。实施例1中闭合传递的信息是一个相同的 认证信息而且闭合传递的起点与终点相同,与本实施例类似的其它流程还有服务 方—(认证信息) 一请求方—(认证信息)一第三方—(认证信息)4服务方;第 三方—(认证信息)一请求方一(认证信息)一服务方—(认证信息)一第三方; 第三方—(认证信息)—服务方一(认证信息)—请求方—(认证信息)—第三方, 等等。
实施例2图2是实施例2的信息传递路径图,本实施例的网络结构请见图6。 实施例2中闭合传递的信息是一个相同的认证信息而且闭合传递的起点与终点 不同。在本实施例中,请求方为用户网络终端,服务方为一网络资源,第三方为在 互联网上提供第三方身份认证服务的认证服务系统,认证信息为一随机序列。 实施例2包括以下步骤
1) 用户网络终端通过认证服务系统的身份认证;
2) 用户网络终端生成一随机序列;
3) 用户网络终端向网络资源发送用户名和随机序列并请求认证,同时用户 网络终端向认证服务系统发送用户标识、网络资源URL和随机序列;
4) 认证服务系统根据用户网络终端发来网络资源URL将用户标识和随机 序列发送给网络资源;
5) 网络资源对比收到的两个随机序列,如果随机序列相同而且收到的时间 差未超过规定值则用户通过身份认证;
用户标识是指用户的APID或AUID。
在本实施例中,用户网络终端上的一个应用程序能够与认证服务系统建立安全 连接。在能通过认证服务系统的身份认证情况下,该应用程序可以完成以下步骤 该应用程序生成一随机序列;该应用程序将该随机序列、用户名和密码等通过一个 浏览器对象的接入请求发往网络资源,同时该应用程序将该随机序列、网络资源 URL和用户标识通过安全连接发往认证服务系统。
在本实施例中,步骤l)也可以移动至步骤3)和步骤4)之间来执行,这时, 用户网络终端可以将用户的身份认证信息在步骤3)中一起发给认证服务系统,认 证服务系统确认用户的身份无误后再执行步骤4)。
在本实施例中,可以在用户终端程序上设置针对具体网络资源的选项或按键, 当用户选择此选项或按键时就发起登录流程。
本实施例可以结合即时通讯工具方便地实现,也可以通过增加浏览器工具项的 方式来实现,还可以通过在网络终端执行一个专门程序来实现。
在本实施例中,网络资源还可以设置登录密码,用户在步骤3)将登录密码、 用户名和随机序列一起发给网络资源。
在本实施例中,请求方是在步骤3)中通过直接向服务方发送闭合传递的信息(随机序列)来向服务方请求接入认证的。
本实施例中,闭合传递的方式为请求方一(认证信息)一服务方,同时,请 求方一(认证信息)一第三方一 (认证信息)一服务方。实施例2中闭合传递的信
息是一个相同的认证信息而且闭合传递的起点与终点不同,与本实施例类似的其它 流程还有请求方一(认证信息)一第三方,同时,请求方一(认证信息)一服务 方—(认证信息)—第三方;第三方一(认证信息)—服务方,同时,第三方—(认 证信息)一请求方一(认证信息)一服务方;服务方一(认证信息)一第三方,同 时,服务方一(认证信息)一请求方一(认证信息)一第三方,等等。
实施例3
图3是实施例3的信息传递路径图,本实施例的网络结构请见图6。 在实施例3中闭合传递的信息包括基于认证信息生成的认证生成信息而且闭合 传递的起点与终点不同。在本实施例中,请求方为用户网络终端,服务方为一网络 资源,第三方为在互联网上提供第三方身份认证服务的认证服务系统,认证信息为 一随机序列、或数学算法、或算法参数,用户网络终端根据该认证信息和与认证服 务系统约定的信息生成己方在闭合传递中需要发送的信息。 实施例3包括以下步骤
1) 用户网络终端通过认证服务系统的身份认证;
2) 用户网络终端将网络资源URL和用户标识发给认证服务系统;
3) 认证服务系统生成认证信息,并以认证信息和约定的信息得出认证生成 信息;
4) 认证服务系统向网络资源发送用户标识和认证生成信息,同时认证服务 系统向用户网络终^S:送认证信息和网络资源URL;
5) 用户网络终端以认证信息和与认证服务系统约定的信息得出认证生成信 息;
6) 用户网络终端将得出的认证生成信息和用户标识等发送给相应的网络资 源;
7) 网络资源对比收到的两个认证生成信息,如果相同而且收到的时间差未 超过规定值则用户通过身份认证;
用户标识是指用户的APID或AUID。在本实施例中,用户网络终端上的一个应用程序能够与认证服务系统建立安全 连接。在能通过认证服务系统的身份认证情况下,该应用程序可以完成以下步骤 该应用程序将网络资源URL和用户标识发给认证服务系统;在得到认证服务系统 的反馈后,该应用程序以认证信息和与认证服务系统约定的信息得出认证生成信 息;该应用程序将得出的认证生成信息通过一个浏览器对象的接入请求发往网络资 源。
在本实施例中,步骤l)也可以移动至步骤2)和步骤3)之间来执行,这时, 用户网络终端可以将用户的身份认证信息在步骤2)中一起发给认证服务系统,认 证服务系统确认用户的身份无误后再执行步骤3)。
在本实施例中,可以在认证服务系统的页面上设置针对具体网络资源的选项或 按键,当用户选择此选项或按键时就发起登录流程。
本实施例可以结合即时通讯工具方便地实现,也可以通过增加浏览器工具项的 方式来实现,还可以通过在网络终端执行一个专门程序来实现。
在本实施例中,网络资源还可以设置登录密码,用户在步骤6)将登录密码、 用户名和随机序列一起发给网络资源。
在本实施例中,请求方是在步骤2)、 3)和4)中通过向第三方传递闭合传递 的信息再由第三方向服务方发送賴合传递的信息的方式向服务方发出接入认证请 求。
在本实施例中,认证信息可以包括以下内容的部分或全部服务方名称或地址, 请求方名称或地址,第三方的名称或地址,信息生成时间,随机信息,等等。约定 的信息可以是数字摘要算法、加密解密算法、动态密码算法等等。
本实施例中,闭合传递的方式为第三方一(认证生成信息)一服务方,同时, 第三方—(认证信息)~*请求方一(认证生成信息)一服务方。在实施例3中闭合 传递的信息包括基于认证信息生成的认证生成信息而且闭合传递的起点与终点不 同,与本实施例类似的还有其它流程,例如第三方—(认证信息)4服务方,同 时,第三方一(认证信息)一请求方一 (认证生成信息)一服务方;服务方一(认 证信息)一第三方,同时,服务方一(认证信息)一请求方—(认证生成信息)一 第三方;请求方—(认证生成信息)一服务方,同时,请求方—(认证信息)一第 三方一(认证生成信息)—服务方;等等。
13实施例4
图4是实施例4的信息传递路径图,本实施例的网络结构请见图6。
在实施例4中闭合传递的信息包括基于认证信息生成的同源认证信息A和同源 认证信息B而且闭合传递的起点与终点不同。在本实施例中,请求方为用户网络终 端,服务方为一网络资源,第三方为在互联网上提供第三方身份认证服务的认证服 务系统。在本实施例中,认证信息为随机生成的符合特定规律的一对数字,如乘 积或和为一固定值或在一固定范围内的一对数,这对数字分别称为同源认证信息A 和同源认证信息B。
实施例4包括以下步骤
1) 用户网络终端通过认证服务系统的身份认证;
2) 用户网络终端将网络资源URL和用户标识发给认证服务系统;
3) 认证服务系统生成认证信息,得到同源认证信息A和同源认证信息B;
4) 认证服务系统向网络资源发送用户标识和同源认证信息A,同时认证服 务系统向用户网络终端发送网络资源URL和同源认证信息B;
5) 用户网络终端将同源认证信息B和用户标识发送向网络资源URL;
6) 网络资源核对收到的同源认证信息A和同源认证信息B是否匹配,如果 匹配而且收到的时间差未超过规定值则用户通过身份认证;
用户标识是指用户的APID或AUID。
在本实施例中,用户网络终端上的一个应用程序能够与认证服务系统建立安全 连接。在能通过认证服务系统的身份认证情况下,该应用程序可以完成以下步骤 该应用程序通过安全连接收到来自认证服务系统的同源认证信息B和网络资源 URL;该应用程序在终端上运行的浏览器对象中寻找与网络资源URL相同的,如 果没有找到就生成一个新浏览器对象;该应用程序使找到的或新生成的浏览器对象 向网络资源URL发送连接请求并将同源认证信息B和用户标识添加到的该连接请 求中。
在本实施例中,步骤l)也可以移动至步骤2)和步骤3)之间来执行,这时, 用户网络终端可以将用户的身份认证信息在步骤2)中一起发给认证服务系统,认 证服务系统确认用户的身份无误后再执行步骤3)。
在本实施例中,网络资源还可以设置登录密码,用户在步骤6)将登录密码、用户名和随机序列一起发给网络资源。
本实施例中,同源认证信息A和同源认证信息B的具体实现可以与实施例5相同。
本实施例中,闭合传递的方式为第三方一(同源认证信息A)—服务方,同 时,第三方一(同源认证信息B)—请求方一(同源认证信息B)—服务方。在实 施例4中闭合传递的信息包括基于认证信息生成的同源认证信息A和同源认证信息 B而且闭合传递的起点与终点不同,与本实施例类似的还有其它流程,在此不一一 列举了。
实施例5
图5是实施例5的信息传递路径图,本实施例的网络结构请见图6。 本实施例中,闭合传递的方式为服务方一(认证信息)一第三方一(同源认 证信息A)—请求方一(同源认证信息B)—服务方。其中,同源认证信息A是基 于认证信息生成的,而同源认证信息B是基于同源认证信息A生成的,作为闭合传 递终点的服务方可以验证同源认证信息B是否是起源于认证信息的。例如认证信 息可以是由服务方随机生成的一个1024位的质数,服务方将此质数发往第三方, 第三方生成一个64位的质数并计算两质数的乘积得到乘积A,第三方将乘积A发 往请求方,请求方也生成一个64位的质数并计算该质数与乘积A的乘积得到乘积 B,请求方将乘积B返回服务方,服务方以乘积B除以1024位的质数,如果可以 整除则说明乘积B是起源于该大数的则认证通过。
与本实施例类似的还有其它流程,在此不一一列举了。
实施例4和5的同源认证信息A和B也可以分别是一认证信息和其数字签名等等。
在与所列实施例类似的流程中,当第三方是闭合传递的终点的时候,第三方需 要将认证的结果通知服务方。例如当服务方向第三方请求对请求方的认证时,服 务方同时向第三方发送一个认证序号,第三方完成认证后向服务方一起返回认证结 果和这个认证序号。
当然,本发明还可有其他多种实施例,在不背离本发明精神及其实质的情况下, 本领域技术人员当可根据本发明作出各种相应的改变和变形,但这些相应的改变和 变形都应属于本发明所附的权利要求的保护范围。
权利要求
1、一种通过第三方的身份认证系统和方法,其特征在于,三个系统分别连接于同一网络,三个系统分别为服务方、请求方和第三方,其中,服务方对请求方的认证要通过第三方来完成,其中,当请求方向服务方请求接入认证时,所述三方能够完成以下步骤一方获取认证信息并发起在以上三方之间的源于该认证信息的闭合传递,其中另外两方上运行的程序能够自动识别闭合传递的信息和路径并响应完成该闭合传递,其中,以上三方中的闭合传递的终点能够验证收到的信息是否起源于闭合传递的起点,只有当收到的信息起源于闭合传递的起点时认证才能通过。
2、 根据权利要求1所述的通过第三方的身份认证系统和方法,其特征在于,只有当请求方通过第三方的认证时,第三方才会参与完成该闭合传递。
3、 根据权利要求1所述的通过第三方的身份认证系统和方法,其特征在于, 所述闭合传递的路径由三个系统中每两者之间的信息传递组成,具体为闭合传递 的起点和终点是同一方,首先一方向另一方发出信息,然后另一方向最后一方发出 信息,然后最后一方向第一方返回信息,完成闭合传递;或者,闭合传递的起点和 终点不是同一方,首先一方分别向其它两方分别发出信息,然后其它两方中的一方 向另一方发出信息,从而完成闭合传递。
4、 根据权利要求1所述的通过第三方的身份认证系统和方法,其特征在于, 在所述闭合传递中,传递的信息就是认证信息本身,这时,闭合传递的终点验证收 到的信息与发出的认证信息是否一致或者收到的两个信息是否一致,如果一致则证 明收到的信息起源于闭合传递的起点。
5、 根据权利要求1所述的通过第三方的身份认证系统和方法,其特征在于, 在所述闭合传递中,传递的信息中至少有一个信息不是认证信息,该信息是由一方 或两方基于认证信息生成的,这时,闭合传递的终点能够验证收到的信息是否是基 于认证信息生成的或者收到的两个信息是否是基于同一认证信息生成的,如果是基 于认证信息生成的或者是基于同一认证信息生成的则证明收到的信息起源于闭合 传递的起点。
6、 根据权利要求1所述的通过第三方的身份认证系统和方法,其特征在于, 在所述闭合传递中,三方中任意两者之间的信息传递路径不经过三方中的其余一 方。
7、 根据权利要求1所述的通过第三方的身份认证系统和方法,其特征在于,在所述闭合传递中.,由请求方发出的每个信息只用于一次认证,由请求方发出的每 个信息无法由请求方先前发出的信息推知。
8、 根据权利要求1所述的通过第三方的身份认证系统和方法,其特征在于, 在所述闭合传递中,当一方生成认证信息时或者当闭合传递终点一方收到第一个信 息时还会生成时间标记,只有当闭合传递终点一方收到信息或者收到第二个信息的 时间未超过规定有效期时,认证才会通过。
9、 根据权利要求1所述的通过第三方的身份认证系统和方法,其特征在于, 所述闭合传递的信息不是数据报头中的IP地址和端口号。
10、 根据权利要求1所述的通过第三方的身份认证系统和方法,其特征在 于,不同的服务方能够通过同一第三方对同一,求方进行认证。
全文摘要
本发明采用一种通过第三方的身份认证系统和方法,来解决互联网用户通过第三方提供的身份认证后向网上服务提供方传递认证凭证的问题。本发明采用起源于认证信息的闭合传递的方式来传递第三方对请求方的认证凭证给服务方,服务方通过比较收到的信息是否相匹配来判断认证是否通过。这个方案具体实现方式多样、对服务方的工作负荷小、程序简单且容易实现。
文档编号H04L29/06GK101442523SQ20081013525
公开日2009年5月27日 申请日期2008年8月6日 优先权日2008年1月18日
发明者任少华 申请人:任少华
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1