CN105959267A - 单点登录技术中的主令牌获取方法、单点登录方法及系统 - Google Patents

Abstract

本发明提供的单点登录技术中的主令牌获取方法，涉及互联网领域，该方法通过手机端首先要通过识别码下发服务器的验证来换取识别码，之后在期望获取主令牌的时候，使用手机端将该识别码发送给令牌颁发服务器，之后令牌颁发服务器将该识别码提供给识别码下发服务器进行验证，只有该次验证通过后，令牌颁发服务器才会将对应的主令牌提供给手机端，这样，即使外部设备知悉了账户和密码，由于外部设备无法通过识别码下发服务器的验证，导致其依旧无法获取主令牌，保证了主令牌下发的安全性，也就保证了单点登录整体的安全性。

Description

单点登录技术中的主令牌获取方法、单点登录方法及系统

技术领域

本发明涉及互联网领域，具体而言，涉及单点登录技术中的主令牌获取方法、登录方法及系统。

背景技术

传统的互联网服务技术通常是由两端通过数据交互完成的，这两端分别是用户操作的终端(如手机、平板电脑)和网络服务商所提供的网络端(如各种类型的服务器)。在用户上线，或者用户发起操作之前，网络端需要对用户的身份进行认证，以确保用户是合法用户。随着网络服务商所提供网络应用的数量的增加，用户每操作一个应用，就需要对应的网络端对该用户进行一次认证，这使得用户的使用不同的应用时变得很繁琐，而且需要记录大量的账号和密码。针对此种情况，后续出现了单点登录记录。

首先，对单点登录技术(Single Sign On)进行简要介绍，该技术简称为SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

之后，随着移动互联网技术的发展，也出现了为移动端(用户所操作的终端)进行单点登录验证的技术，这种针对移动端进行单点登录验证的技术称为NAPPS是Native AppSSO的缩写，即移动应用程序单点登录。

通常情况下，NAPPS只支持OIDC协议的单点登录，并且，传统的单点登录技术的安全性较差。

发明内容

本发明的目的在于提供单点登录技术中的主令牌获取方法、登录方法及系统，以提高单点登录的安全性。

第一方面，本发明实施例提供了单点登录技术中的主令牌获取方法，包括：

手机端的认证请求模块向识别码下发服务器发出获取识别码请求；

识别码下发服务器对所述获取识别码请求进行验证，若验证通过，则识别码下发服务器向所述认证请求模块返回第一验证通过信息，所述第一验证通过信息中携带有识别码；

所述认证请求模块向所述手机端的令牌转发模块发送获取主令牌请求，所述获取主令牌请求中携带有识别码；

所述令牌转发模块将所述获取主令牌请求向令牌颁发服务器转发；

令牌颁发服务器向所述识别码下发服务器发送所述获取主令牌请求中的识别码；

识别码下发服务器验证所述识别码；

若所述识别码下发服务器验证所述获取主令牌请求中的识别码为真，则识别码下发服务器向令牌颁发服务器发出第二验证通过信息；

令牌颁发服务器在接收到所述第二验证通过信息后，向所述令牌转发模块颁发用于进行单点登录验证的主令牌。

第二方面，本发明实施例还提供了单点登录技术中的主令牌获取系统，包括：

手机端的认证请求模块，用于向识别码下发服务器发出获取识别码请求；

识别码下发服务器，用于对所述获取识别码请求进行验证，若验证通过，则识别码下发服务器，进一步用于向所述认证请求模块返回第一验证通过信息，所述第一验证通过信息中携带有识别码；

所述认证请求模块，还用于向所述手机端的令牌转发模块发送获取主令牌请求，所述获取主令牌请求中携带有识别码；

所述令牌转发模块，用于将所述获取主令牌请求向令牌颁发服务器转发；

令牌颁发服务器，用于向所述识别码下发服务器发送所述获取主令牌请求中的识别码；

识别码下发服务器，还用于验证所述识别码；

若所述识别码下发服务器验证所述获取主令牌请求中的识别码为真，则识别码下发服务器，进一步用于向令牌颁发服务器发出第二验证通过信息；

令牌颁发服务器，还用于在接收到所述第二验证通过信息后，向所述令牌转发模块颁发用于进行单点登录验证的主令牌。

第三方面，本发明实施例还提供了单点登录方法，包括如第一方面的单点登录技术中的主令牌获取方法，还包括：

手机端的接口调用模块在获取到登录指令后，向所述令牌转发模块发送登录指令所对应的子账户用户名和子应用标识；

令牌转发模块向令牌颁发服务器发送获取子令牌请求，所述获取子令牌请求中携带有所述子账户用户名、所述子应用标识和所述主令牌；

令牌颁发服务器根据子应用标识验证所述手机端是否已经在令牌颁发服务器中注册过；

若是，则令牌颁发服务器根据子应用标识，将所述子账户用户名和所述主令牌发送至相应的验证服务器；

验证服务器验证所述子账户用户名和所述主令牌是否符合预设要求；若是，则验证服务器将所述子账户用户名所对应的子令牌发送至令牌颁发服务器；

令牌颁发服务器将所述子令牌发送至所述令牌转发模块；

所述令牌转发模块将所述子令牌发送至手机端的应用模块；

所述应用模块向所述应用服务器发起登录请求，所述登录请求中携带有所述子令牌；

所述应用服务器验证所述子令牌是否为真，或是，则所述登录请求通过。

第四方面，本发明实施例还提供了单点登录系统，包括如第二的单点登录技术中的主令牌获取系统，还包括：

手机端的接口调用模块，用于在获取到登录指令后，向所述令牌转发模块发送登录指令所对应的子账户用户名和子应用标识；

令牌转发模块，还用于向令牌颁发服务器发送获取子令牌请求，所述获取子令牌请求中携带有所述子账户用户名、所述子应用标识和所述主令牌；

令牌颁发服务器，还用于根据子应用标识验证所述手机端是否已经在令牌颁发服务器中注册过；

若是，则令牌颁发服务器，还用于根据子应用标识，将所述子账户用户名和所述主令牌发送至相应的验证服务器；

验证服务器验证，用于所述子账户用户名和所述主令牌是否符合预设要求；若是，则验证服务器，进一步用于将所述子账户用户名所对应的子令牌发送至令牌颁发服务器；

令牌颁发服务器，还用于将所述子令牌发送至所述令牌转发模块；

所述令牌转发模块，还用于将所述子令牌发送至手机端的应用模块；

所述应用模块，用于向所述应用服务器发起登录请求，所述登录请求中携带有所述子令牌；

所述应用服务器，用于验证所述子令牌是否为真，或是，则所述登录请求通过。

本发明实施例提供的单点登录技术中的主令牌获取方法，采用只有在期望获取主令牌的手机端在识别码下发服务器进行二次验证后才能够获取主令牌，与现有技术中期望获取主令牌的手机需要通过多个步骤的验证，以及code(认证码)的传递才能够通过用户名和密码获取访问用的令牌相比，其通过手机端首先要通过识别码下发服务器的验证来换取识别码，之后在期望获取主令牌的时候，使用手机端将该识别码发送给令牌颁发服务器，之后令牌颁发服务器将该识别码提供给识别码下发服务器进行验证，只有该词验证通过后，令牌颁发服务器才会将对应的主令牌提供给手机端，这样，即使外部设备知悉了账户和密码，由于外部设备无法通过识别码下发服务器的验证，导致其依旧无法获取主令牌，保证了主令牌下发的安全性，也就保证了单点登录整体的安全性。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了相关技术中，进行单点登录的网络框架示意图；

图2示出了本发明实施例所提供的单点登录技术中的主令牌获取方法的基本流程图；

图3示出了本发明实施例所提供的单点登录技术的一种网络框架实例示意图；

图4示出了本发明实施例所提供的单点登录技术的基本流程图；

图5示出了本发明实施例所提供的单点登录技术的另一种网络框架实例示意图；

图6示出了本发明实施例所提供的单点登录技术中，进行单点退出流程的网络框架示意图。

具体实施方式

下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

随着网络技术的发展，网络供应商所提供的而网络服务也越来越多，如微信、迅雷等等。网络服务的网络框架通常可以由两端组成，也就是网络供应商所控制的网络端(通常也被称为服务器)和由用户所控制的终端(如手机)。为了提高用户使用的便捷性，技术人员研发出了单点登录技术，之后，进一步的开发出了针对移动应用程序的单点登录技术。但是传统的单点登录技术有一定的弊端，如图1所示，提供了传统的单点登录技术的网络架构图，对应的具体流程如下：

1，TA提供用户名/密码或其它进行认证，并且获取PT；通常，该步骤发生在内置或是共享的浏览器上；

2，TA利用code(认证码)换取PT(主令牌)，为将来换取ST(子令牌)做准备；

3，TA为一个应用发起获取令牌的请求；

4，AS(令牌服务器)返回子令牌；

5，TA转交ST给相应的App；

6，App使用ST访问应用RS受保护的资源；

7，RS(资源服务器)在AS处通过自我校验或通过AS验证签名，验证AT是否正确，决定是否放行。

图1中，TA(Token Agent)令牌代理，用于存储并发送令牌；AS为用于验证令牌的服务器；存储有App1-App3三个应用程序的终端是用户的手机，存储有RS1-RS3的服务器是网络服务商提供的存储有服务程序的服务器，其中，RS1-RS3服务程序和App1-App3三个应用程序是相对应的；PT是令牌，用于证明用户身份。

可见传统的单点登录流程中获取令牌的过程是通过层层的认证来获取的，其根本是使用用户名和密码进行验证，当用户名和密码泄露之后，其安全性也就难以得到保证了。有鉴于此，本申请提供了单点登录技术中的主令牌获取方法，如图1所示，包括如下步骤：

S101，手机端的认证请求模块向识别码下发服务器发出获取识别码请求；

S102，识别码下发服务器对获取识别码请求进行验证，若验证通过，则识别码下发服务器向认证请求模块返回第一验证通过信息，第一验证通过信息中携带有识别码；

S103，认证请求模块向手机端的令牌转发模块发送获取主令牌请求，获取主令牌请求中携带有识别码；

S104，令牌转发模块将获取主令牌请求向令牌颁发服务器转发；

S105，令牌颁发服务器向识别码下发服务器发送获取主令牌请求中的识别码；

S106，识别码下发服务器验证识别码；

S107，若识别码下发服务器验证获取主令牌请求中的识别码为真，则识别码下发服务器向令牌颁发服务器发出第二验证通过信息；

S108，令牌颁发服务器在接收到第二验证通过信息后，向令牌转发模块颁发用于进行单点登录验证的主令牌。

如图3所示，提供了图2所示方法的网络框架示意图。图中，Client为手机端的认证请求模块，TA为手机端的令牌转发模块，IDS为令牌颁发服务器，Server为识别码下发服务器。

通过上述流程可知，本申请所提供的方法中，如果手机端期望获取主令牌，则需要先在向识别码下发服务器进行验证，只有验证通过后(验证通过，则说明识别码下发服务器认为该手机端的认证请求模块是合法的)，识别码下发服务器才会将识别码提供给手机端。之后，手机端在需要获取主令牌的时候，是使用获取到的识别码来换取，具体的换取过程是先将该识别码发送给主令牌颁发服务器，由于该服务器无法验证识别码的真伪(识别码有识别码下发服务器才知晓)，因此，需要将识别码转发给识别码下发服务器进行识别。前序步骤(S102)中，识别码下发服务器在向手机端返回第一验证通过信息的同时，还会存储该识别码。之后识别码下发服务器比对接收到的识别码和步骤S102中所发出的识别码是否相同，如果相同就向令牌颁发服务器发出第二验证通过信息，以表达手机端所发出的识别码是真实有效的。之后，令牌颁发服务器才会将主令牌提供给手机端。该过程中，由于手机端获取主令牌前需要由识别码下发服务器进行校验，其校验的是该设备是否通过了步骤S102的验证(验证后便视为该设备注册过)，进而保证了只有注册过的设备才能够得到主令牌，而其他设备即使了解了账号、密码也无法获取主令牌(其他设备无法得到步骤S102中的识别码)。

具体的，执行步骤S101-步骤S108有两种具体情况，第一种情况是手机端还未进行注册，也就是首次使用的时候，需要使用识别码下发服务器所提供的激活链接进行识别码的获取，以保证安全性。在该种情况下，获取识别码请求中存在的是用户通过点击激活链接而生成的激活码。也就是：若获取识别码请求中携带有激活码，则识别码下发服务器对获取识别码请求进行验证包括：

识别码下发服务器验证激活码是否为真；若是，则验证通过；

其中，激活码是通过以下步骤生成的：

识别码下发服务器向手机端发送激活链接；

手机端触发激活链接，以获取激活码。

其中，手机端触发激活链接可以理解为用户通过按压触屏，或者其他指令下达方式向手机端下达了打开激活链接的指令，之后手机端通过读取激活链接，来自动生成了激活码，并且将该激活码发送给了识别码下发服务器。由于该过程完全是受到激活链接的控制，而且激活链接是有识别码下发服务器所下达的，因此，保证了识别码获取的安全性，进而保证了后续步骤中获取识别码和进行单点登录的安全性。

另一种方式是手机端已经进行了注册，则不再需要通过激活码来获取识别码，此时手机端再想识别码下发服务器发送请求的时候，需要将该描述设备和用户的信息一同发送给识别码下发服务器，以换取识别码。具体而言，若获取识别码请求中携带有主账户用户名、验证密码和设备编号，则识别码下发服务器对获取识别码请求进行验证包括：

识别码下发服务器分别对主账户用户名、验证密码和设备编号进行验证；若主账户用户名、验证密码和设备编号均为真，则验证通过。

其中，主账户用户名是和验证密码是存储在手机端中的，与相关技术汇总相类似的，这两个信息容易发生泄密。而设备编号是跟随着硬件设备的生产一同生成的，无法进行修改，因此通过设备编号，便能够保证获取识别码的安全性(使用其他设备发送获取识别码请求时，由于设备编号不同，是无法通过识别码下发服务器所进行的验证的)。

为了进一步提高安全性，还可以是令牌颁发服务器先对手机端进行查验，只有查验通过了才会将识别码交给识别码下发服务器进行验证，具体的，在步骤S105，令牌颁发服务器向识别码下发服务器发送获取主令牌请求中的识别码之前，还包括：

令牌颁发服务器根据获取主令牌请求中的APPKey和APPSecret，验证手机端是否已经在令牌颁发服务器中的注册表中注册过，若注册过，则执行步骤令牌颁发服务器向识别码下发服务器发送获取主令牌请求中的识别码。

具体而言，令牌颁发服务器会在其存储区的注册表中查找是否存在接收到的APPKey和APPSecret，如果二者均存在，则说明该手机端进行过注册(该注册的预先完成的)，才可以执行步骤S105。

下面提供两个实例来说明本申请所提供的单点登录技术中的主令牌获取方法：

首先对实例1-4中所设计的符号进行说明，具体如下表1所示，

表1

实例1，当手机端未在识别码下发服务器中进行注册的情况下，需要通过如下步骤获取主令牌，参见图3的步骤1-7：

①用户通过操作手机端，点击收到激活邮件中的激活链接，Client(即手机端的认证请求模块)向Server(识别码下发服务器)发起Http请求，该请求中包括：username(用户名)、Device ID(设备编号)、pincode(激活码)，请求绑定设备；其中，用户名可以是用户自己定义的名称，激活码是通过触发激活链接后得到的，设备编号是手机端出厂时便确认的号码，用以区分不同的手机；

②Server收到请求后，验证激活码(由于此激活码就是Server自己通过激活链接发送的，所以Server可以验证激活码是否正确)，如果激活码正确，则Server向Client发送secret数据，secret数据中包括：HostId(Server中某个用户的唯一标识，即识别码)，IDS(令牌颁发服务器)的URL(链接地址)，用于手机端访问令牌颁发服务器使用，并注销激活码，确保激活码只能使用一次，以提高安全性；

③Client收到secret数据后，向TA(即手机端的令牌转发模块)发送Http请求，该请求中携带Device ID，APPKey，APPSecret和secret数据，请求颁发PT；

④由于secret数据是Server端发送的，只有Server自己可以验证secret数据的真伪，TA无法判断secret是否正确，所以TA收到后将请求转发给IDS，此处只是转发，无其它附加操作；

⑤由于secret数据是Server端发送的，只有Server自己可以验证secret数据的真伪，IDS也无法判断secret数据是否正确，所以IDS收到请求后，先通过查找IDS中TA的注册表中是否存在要校验的APPKey，APPSecret，验证TA是否在IDS注册过，注册过IDS才会提供服务；如果通过验证，IDS提取secret数据中的识别码，并将该识别码通过http请求发送给Server；

⑥Server收到请求后，验证识别码，并根据验证结果返回相应的数据；如果验证通过，则返回username(主帐户用户名)给IDS；如果验证失败，返回错误码；

⑦IDS收到通知后，根据返回结果决定颁发token还是返回拒绝；如果IDS收到username(主帐户用户名)，则向TA颁发PT(Primary Token)，TA接收到PT后，将其存储起来，用户之后可以继续使用这个私有令牌进行访问，至此获取PT过程完成；如果IDS收到错误码，则通知TA获取PT失败。

实例2，当手机端已经在识别码下发服务器中进行注册的情况下，需要通过如下步骤获取主令牌，同样可以参考图3的步骤1-7(以下步骤中的名词解释可以参考实例1)：

①用户在Client端(即手机端的认证请求模块)向Server发送Http请求，请求中包括：username(主帐户用户名)、password(密码)，Device ID(设备编号)，请求secret数据；

②Server收到请求后，验证username(主帐户用户名)、password(密码)，DeviceID(设备编号)，如果三者全部正确，Server向Client发送secret数据；

③Client收到secret数据后，向TA(即手机端的令牌转发模块)发送Http请求，请求中包括：secret数据，Device ID，请求TA颁发PT；

④由于secret数据是Server端发送的，只有Server自己可以验证secret数据的真伪，TA无法判断secret是否正确，所以TA收到后将请求转发给IDS，此处只是转发，无其它附加操作；

⑤由于secret数据是Server端发送的，只有Server自己可以验证secret数据的真伪，IDS也无法判断secret数据是否正确，所以将以上secret数据中的识别码包装成JSON格式后，转发给Server；

⑥Server收到识别码后，验证secret数据中的识别码，将验证结果通知IDS；

⑦IDS收到通知后，根据结果决定颁发token还是返回拒绝，如果成功向TA颁发PT(Primary Token)，TA接收到PT后，将其存储在安全的应用空间中，用户之后可以继续使用这个私有令牌进行访问，至此获取PT过程完成；如果失败，通知TA获取PT失败。

获取主令牌的目的是进行单点登录，下面本发明还提供了基于上述单点登录技术中的主令牌获取方法的单点登录方法，除了包括步骤S101-S108，还包括如下步骤，如图4所示：

S201，手机端的接口调用模块在获取到登录指令后，向令牌转发模块发送登录指令所对应的子账户用户名和子应用标识；

S202，令牌转发模块向令牌颁发服务器发送获取子令牌请求，获取子令牌请求中携带有子账户用户名、子应用标识和主令牌；

S203，令牌颁发服务器根据子应用标识验证手机端是否已经在令牌颁发服务器中注册过；

S204，若是，则令牌颁发服务器根据子应用标识，将子账户用户名和主令牌发送至相应的验证服务器；

S205，验证服务器验证子账户用户名和主令牌是否符合预设要求；若是，则验证服务器将子账户用户名所对应的子令牌发送至令牌颁发服务器；

S206，令牌颁发服务器将子令牌发送至令牌转发模块；

S207，令牌转发模块将子令牌发送至手机端的应用模块；

S208，应用模块向应用服务器发起登录请求，登录请求中携带有子令牌；

S209，应用服务器验证子令牌是否为真，或是，则登录请求通过。

其中，登录指令是由用户通过按压手机端的触摸屏或者其他指令下达方式传达给手机的。

优选的，步骤S205中，验证服务器验证子账户用户名和主令牌是否符合预设要求可以按照如下方式执行：

验证服务器验证子账户用户名和主令牌所对应的主账户用户名是否已经授权关联。如果已经授权关联，则说明验证服务器可以将子账户用户名所对应的子令牌发送至令牌颁发服务器。

本申请所提供的登录方法，在执行过程中会有两种情况，是按照协议的不同，需要由不同的验证服务器来验证子账户用户名和主令牌是否能够对应上。因此，为了将子账户用户名和主令牌发送到对应的服务器进行验证，则需要首选确定协议所对应的认证方式，再按照认证方式所对应的记录，将这两个信息发送到对应的验证服务器中。具体的，步骤S205中，令牌颁发服务器根据子应用标识，将子账户用户名和主令牌发送至相应的验证服务器包括如下步骤：

令牌颁发服务器查找子应用标识查找对应的认证方式；

令牌颁发服务器将子账户用户名和主令牌发送至认证方式所对应的验证服务器。

优选的，还可以根据使用的场景来调整步骤S209中的验证子令牌的步骤，以使整体步骤更为安全，具体的，应用服务器验证子令牌是否为真的步骤可以由如下步骤组合而成：

应用服务器将子令牌转发至验证服务器；

验证服务器验证子令牌是否已经注册，若是，则向应用服务器返回验证通过信息；

若应用服务器接收到验证通过信息，则验证子令牌为真。

上述步骤S201-S209中，验证服务器有两种存在形式，分别是和令牌颁发服务器位于同一个物理服务器中的形式，和验证服务器与令牌颁发服务器位于不同的物理服务器中的形式。

下面给出两个具体的实例还说明本申请所提供的单点登录方法，以下两种实例均有共同的前提条件，即假设用户绑定设备(手机端)并获取PT后(已登录主应用)，在后续的使用中，没有进行SLO(单点退出)，然后继续进行SSO的过程。这两个实例要求先在TA上已经有相应的PT。如果要实现单点登录，首先要在IDS中，将RP APP的子用户名username与Client的主用户名username进行帐户授权关联，并将对应关系表存储在IDS中，后续单点登录时用来决定是否可以进行授权认证。具体实例如下，请参照图3所示：

实例3，该种情况是针对AS无权限进行认证，需要外部服务KDC进行认证，图3中R1～R10，其中R8和R9为可选项。该过程是针对IDS需要使用外置的KDC来辅助发放应用的ST，主要针对的协议如Kerberos等协议。

R1，TA发起和APP发起的区别在于这一步有还是没有，有的话，用户点击RP APP准备登录时，SDK(即手机端的接口调用模块)向TA发起SSO请求，请求中包括：RP username(子帐户用户名)和FacetID(子应用RP APP的唯一标识，即子应用标识)，请求TA颁发允许访问RP Server的ST(Secondary Token)；

R2，TA收到请求后，携带其存储的PT，向IDS发起Http请求，请求颁发允许访问RPServer的ST(Secondary Token)，请求中包括：PT，RP username(子帐户用户名)，FacetID(子应用RP APP的唯一标识)；

R3，IDS收到请求后，会首先验证FacetID所代表的RP APP是否在IDS注册，通过查找IDS中RP APP的注册表是否存在要校验的FacetID，如果有，则代表FacetID合法；验证通过后，IDS会根据FacetID找到对应RP Server配置的认证方式，确定是否将数据提交给AS处理就可以，还是需要到KDC(密匙分配中心，即验证服务器)进行认证；比如Kerberos协议，其配置的认证方式，需要将RP username(子帐户用户名)，SPN(加密虚拟网络)提交给KDC；

R4，KDC处理提交的请求：认证子帐户用户身份及访问权限，允许访问时，将ST(Secondary Token)返回给IDS；

R5，IDS收到ST后，发送给TA；

R6，TA将ST转发给TA SDK并通过RP SDK接口回传给RP APP；

R7，RP APP(即手机端的应用模块)收到ST后，携带ST向RP Server发起http请求，请求访问资源，RP Server(应用服务器)根据需要(即自身可以校验ST)，校验ST正确与否；

R8，(可选项)或者RP Server根据需要(即自身不可以校验ST)，将收到的请求转发给KDC校验，校验ST是否有访问权限；

R9，(可选项)在R8执行的情况下，则KDC验证ST，如果校验通过，通知RP Server允许访问；如果校验失败，将失败的结果返回到RP Server；

R10，RP Server根据返回的结果，提示RP APP访问成功或失败；如果成功，允许RPAPP访问并提供相应资源，至此用户完成单点登录。

实例4，该种情况是针对AS有权限进行认证，内部认证，图5中R1-R10,其中R8和R9为可选项。该过程是针对IDS本身内置的AS就可以直接发放应用的ST，主要针对的协议如OAuth，OIDC等。

R1，用户点击RP APP准备登录时，SDK(即手机端的认证请求模块)向TA发起SSO请求，请求中包括：RP username(子帐户用户名)和FacetID(子应用RP APP的唯一标识，即)，请求TA颁发允许访问RP Server的ST(Secondary Token)；

R2，TA收到请求后，携带其存储的PT，向IDS发起Http请求，请求颁发允许访问RPServer的ST(Secondary Token)，请求中包括：PT，RP username(子帐户用户名)，FacetID(子应用RP APP的唯一标识)；

R3，IDS收到请求后，会首先验证FacetID所代表的RP APP是否在IDS注册，通过查找IDS中RP APP的注册表是否存在要校验的FacetID，如果有，则代表FacetID合法；验证通过后，IDS会根据FacetID找到对应RP Server配置的认证方式，确定是否将数据提交给KDC(密匙分配中心)进行认证；如果是OAuth，Basic，OIDC等协议，其配置的认证方式，需要将数据提交给IDS Server内置的AS(验证服务器)进行认证；

R4，AS进行认证处理：因为AS内置于IDS，所以可以查询RP APP的子帐户Username是否与IDS中的主帐户Username授权关联，如果未关联，则返回响应错误码；如果已关联，则认证子帐户用户身份及访问权限，根据该应用注册的额外限制，如AppKey(也就是OAuthClient ID)，将ST(Secondary Token)返回给IDS；

R5，IDS收到ST后，返回给TA；

R6，TA将ST转送给SDK并通过接口回传给RP APP；

R7，RP APP(即手机端的应用模块)携带ST向RP Server发起http请求，请求访问资源，RP Server根据认证协议的需要(比如Basic协议下的ST，RP可以自己解析)，判断ST正确与否；

R8，(可选项)或者RP Server根据认证协议的需要(比如OAuth，OIDC等协议下的ST，RP不能自己解析)，将收到的请求转发给AS校验，校验ST是否有访问权限；

R9，(可选项)如果步骤R8执行的情况下，则AS验证ST，校验通过，返回RP APP的Username，并通知RP Server允许访问；校验失败，将失败的结果返回到RP Server；

R10，RP Server根据返回的结果，提示RP APP访问成功或失败；如果成功，允许RPAPP访问并提供相应资源，至此用户完成单点登录。

本发明实施例还提供了与上述登录方法相适应的单点退出流程，如图6所示，包括如下流程：

R1，用户点击Client或某个RP APP(如ST1)退出登录，TA或SDK发起SLO(单点退出)请求(一个广播，所有集成了TA或SDK的应用都能收到这个广播)；

R2，TA将请求提交给IDS，请求清除IDS中的PT；

R3，IDS验证请求内容，如果验证成功，则清除PT，IDS清除PT后，向TA发送SLO请求回复，通知TA清除各应用本地ST；

R4，TA将按照本地存储的ST列表顺序(如ST1，ST2，ST3...)通知各个SDK，依次清除各应用本地ST；

R5，TA清除完最后一个ST后，通过接口回传给RP APP，跳转到登录页面，至此单点退出流程完成。

其中：Secret在Client上并不保留，所以TA没有单独通知Client去清除。

整体来看本申请所提供的登录方法，有如下几点需要说明：

第一点，本申请所提供的方法和标准NAPPS方法在流程上的区别及如何保障安全性

前提条件：

客户端与服务端的传输已加密，端对端的传输过程认为是安全的。

1，标准结构分析：

标准NAPPS流程只定义了流程，至于每一步携带哪些数据，并未做具体规范。

标准NAPPS流程中，用户访问应用时，有时在客户端(Token Agent)使用内置的浏览器内输入用户名密码，提交给服务器(AS)验证，由于用户在身份认证时使用了第三方的应用(浏览器)，所以信息的传输过程中过程被认为是不安全的，故添加code作为验证信息，确保传输过程的安全性，只有每步的验证全部通过，才可以通过用户名密码换取AT(访问应用的令牌)。

2，本申请所提供的方法的分析：

与标准结构相比，本申请提供的解决方案多了硬件设备注册的过程，即“步骤S102”。这样即使有了帐户和密码，也只允许注册过的信任设备进行访问来获取PT，相比原来流程更加安全。

本申请所提供的方案，主要针对的是移动端，客户端应用直接集成在TA(不通过浏览器)，用户登录时进行身份认证的过程，是应用APP端直接与服务器端的信息直接通过HTTP Client交互，这个过程通过HTTPS，并且不涉及第三方(共享通道)，所以传输过程是安全的，故不需要code来做验证，直接就可以换取PT(AT)。

3，结论：

与标准NAPPS比起来，本申请所提供的方法增加了硬件设备注册流程，只允许受信任设备访问其应用下对应的资源服务器，并且将客户端应用登录直接集成在TA，不经过浏览器，在不降低安全性的前提下，用户使用起来更便捷，用户体验更好。

二，为什么本申请所提供的方案能让其他企业快速集成？

1，标准结构分析：

标准结构由三部分组成：客户端(App)、服务器端(RS)、令牌代理(TA)、认证服务器端(AS)。其中客户端、服务器端均需要相应的NAPPS协议实现代码。

因此企业如果想集成NAPPS功能，必须实现客户端、服务器端的NAPPS协议。这样就使得开发成本和周期就经较高。

本申请所提供的解决方案分析：

与标准结构相比，本申请的解决方案多了RP App(认证主应用客户端)，及相应RPServer，SDK(RP App客户端软件开发包及RP Server对应的服务端软件开发包)，IDS(认证服务端)，KDC(密钥分发中心)。此种解决方案以提供服务端的SDK、App端的IOS及AndroidSDK的方式提供服务，这样很多代码都是封装过的，配合SDK文档和样本程序，开发者集成NAPPS功能非常方便，提高了第三方RP应用服务使用NAPPS协议的效率。

同时，增加RP APP CLIENT及相应RP Server的目的是：IDS本身可以使用第三方的认证机制，便于和已有的帐户和认证的统一；

增加SDK的目的是：将复杂的服务器连接/请求等封装，应用只需调用接口，而不用关心其实现过程；

增加IDS的目的是：控制各RP集成的权限，不能让未授权的RP集成，同时集中管理各个RP应用需要的访问令牌ST；

增加KDC的目的是：有些令牌如Kerberos等，IDS并没有能力去发布和管理ST，这样需要一个管理员帐户去换取各个用户的子ST,起到免密码登录的效果。

3，结论：

与标准结构比起来，本公司此种解决方案以“统一认证，单点登录”的思想，保证各RP重用一个TA SDK实现。因此能显著降低RP开发成本，并且让RP快速集成。

三，为什么本申请的方案在不降低安全性的同时，让NAPPS实现多种认证协议

1，标准NAPPS分析：

NAPPS的规范是世界上顶级的移动安全人员在一起实现的。尽管NAPPS只定义了OIDC一种规范的实现，仍可以保证流程是安全的。

2，本申请的解决方案分析：

与标准NAPPS相比，本申请的解决方案在支持OIDC的基础上，扩展了对第三方设备管理和统一认证的实现；扩展了对除OIDC外其它认证协议如SAML，Kerberos，CAS等的实现。因为使用了一样的流程，只是传递的ID_token(OIDC令牌)，变成了其它的各种协议对应token,整个流程更严格了，所以可以认为这个过程也是足够安全的。

3，结论：

与标准NAPPS比起来，本申请的解决方案以“统一认证，单点登录”的思想，解决了多个移动应用的单点登录问题。与标准NAPPS相比，本申请的解决方案在支持OIDC的基础上，增加了Basic，OAuth，Kerberos，SMAL等协议的支持，同时提供相应的RP APP客户端和服务端SDK及演示代码。这样大大方便开发者在移动端集成RP APP，提高了NAPPS的兼容性，并且在保证安全的同时，提供了最佳的用户体验。

本申请实施例还提供了与单点登录技术中的主令牌获取方法相对应的单点登录技术中的主令牌获取系统，包括：

手机端的认证请求模块，用于向识别码下发服务器发出获取识别码请求；

识别码下发服务器，用于对所述获取识别码请求进行验证，若验证通过，则识别码下发服务器，进一步用于向所述认证请求模块返回第一验证通过信息，所述第一验证通过信息中携带有识别码；

所述认证请求模块，还用于向所述手机端的令牌转发模块发送获取主令牌请求，所述获取主令牌请求中携带有识别码；

所述令牌转发模块，用于将所述获取主令牌请求向令牌颁发服务器转发；

令牌颁发服务器，用于向所述识别码下发服务器发送所述获取主令牌请求中的识别码；

识别码下发服务器，还用于验证所述识别码；

若所述识别码下发服务器验证所述获取主令牌请求中的识别码为真，则识别码下发服务器，进一步用于向令牌颁发服务器发出第二验证通过信息；

令牌颁发服务器，还用于在接收到所述第二验证通过信息后，向所述令牌转发模块颁发用于进行单点登录验证的主令牌。

本申请实施例还提供了与单点登录方法相对应的单点登录系统，包括单点登录技术中的主令牌获取系统，还包括：

手机端的接口调用模块，用于在获取到登录指令后，向所述令牌转发模块发送登录指令所对应的子账户用户名和子应用标识；

令牌转发模块，还用于向令牌颁发服务器发送获取子令牌请求，所述获取子令牌请求中携带有所述子账户用户名、所述子应用标识和所述主令牌；

令牌颁发服务器，还用于根据子应用标识验证所述手机端是否已经在令牌颁发服务器中注册过；

若是，则令牌颁发服务器，还用于根据子应用标识，将所述子账户用户名和所述主令牌发送至相应的验证服务器；

验证服务器验证，用于所述子账户用户名和所述主令牌是否符合预设要求；若是，则验证服务器，进一步用于将所述子账户用户名所对应的子令牌发送至令牌颁发服务器；

令牌颁发服务器，还用于将所述子令牌发送至所述令牌转发模块；

所述令牌转发模块，还用于将所述子令牌发送至手机端的应用模块；

所述应用模块，用于向所述应用服务器发起登录请求，所述登录请求中携带有所述子令牌；

所述应用服务器，用于验证所述子令牌是否为真，或是，则所述登录请求通过。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。

Claims (10)

1.单点登录技术中的主令牌获取方法，其特征在于，包括：

手机端的认证请求模块向识别码下发服务器发出获取识别码请求；

识别码下发服务器对所述获取识别码请求进行验证，若验证通过，则识别码下发服务器向所述认证请求模块返回第一验证通过信息，所述第一验证通过信息中携带有识别码；

所述认证请求模块向所述手机端的令牌转发模块发送获取主令牌请求，所述获取主令牌请求中携带有识别码；

所述令牌转发模块将所述获取主令牌请求向令牌颁发服务器转发；

令牌颁发服务器向所述识别码下发服务器发送所述获取主令牌请求中的识别码；

识别码下发服务器验证所述识别码；

若所述识别码下发服务器验证所述获取主令牌请求中的识别码为真，则识别码下发服务器向令牌颁发服务器发出第二验证通过信息；

令牌颁发服务器在接收到所述第二验证通过信息后，向所述令牌转发模块颁发用于进行单点登录验证的主令牌。

2.根据权利要求1所述的方法，其特征在于，若所述获取识别码请求中携带有激活码，则所述识别码下发服务器对所述获取识别码请求进行验证包括：

所述识别码下发服务器验证激活码是否为真；若是，则验证通过；

其中，所述激活码是通过以下步骤生成的：

所述识别码下发服务器向所述手机端发送激活链接；

所述手机端触发所述激活链接，以获取所述激活码。

3.根据权利要求1所述的方法，其特征在于，若所述获取识别码请求中携带有主账户用户名、验证密码和设备编号，则所述识别码下发服务器对所述获取识别码请求进行验证包括：

所述识别码下发服务器分别对所述主账户用户名、验证密码和设备编号进行验证；若所述主账户用户名、验证密码和设备编号均为真，则验证通过。

4.根据权利要求1所述的方法，其特征在于，在步骤所述令牌颁发服务器向所述识别码下发服务器发送所述获取主令牌请求中的识别码之前，还包括：

所述令牌颁发服务器根据所述获取主令牌请求中的APPKey和APPSecret，验证所述手机端是否已经在令牌颁发服务器中的注册表中注册过，若注册过，则执行步骤所述令牌颁发服务器向所述识别码下发服务器发送所述获取主令牌请求中的识别码。

5.单点登录技术中的主令牌获取系统，其特征在于，包括：

手机端的认证请求模块，用于向识别码下发服务器发出获取识别码请求；

识别码下发服务器，用于对所述获取识别码请求进行验证，若验证通过，则识别码下发服务器，进一步用于向所述认证请求模块返回第一验证通过信息，所述第一验证通过信息中携带有识别码；

所述认证请求模块，还用于向所述手机端的令牌转发模块发送获取主令牌请求，所述获取主令牌请求中携带有识别码；

所述令牌转发模块，用于将所述获取主令牌请求向令牌颁发服务器转发；

令牌颁发服务器，用于向所述识别码下发服务器发送所述获取主令牌请求中的识别码；

识别码下发服务器，还用于验证所述识别码；

若所述识别码下发服务器验证所述获取主令牌请求中的识别码为真，则识别码下发服务器，进一步用于向令牌颁发服务器发出第二验证通过信息；

令牌颁发服务器，还用于在接收到所述第二验证通过信息后，向所述令牌转发模块颁发用于进行单点登录验证的主令牌。

6.单点登录方法，包括如权利要求1-5任一项所述的单点登录技术中的主令牌获取方法，其特征在于，还包括：

手机端的接口调用模块在获取到登录指令后，向所述令牌转发模块发送登录指令所对应的子账户用户名和子应用标识；

令牌转发模块向令牌颁发服务器发送获取子令牌请求，所述获取子令牌请求中携带有所述子账户用户名、所述子应用标识和所述主令牌；

令牌颁发服务器根据子应用标识验证所述手机端是否已经在令牌颁发服务器中注册过；

若是，则令牌颁发服务器根据子应用标识，将所述子账户用户名和所述主令牌发送至相应的验证服务器；

验证服务器验证所述子账户用户名和所述主令牌是否符合预设要求；若是，则验证服务器将所述子账户用户名所对应的子令牌发送至令牌颁发服务器；

令牌颁发服务器将所述子令牌发送至所述令牌转发模块；

所述令牌转发模块将所述子令牌发送至手机端的应用模块；

所述应用模块向所述应用服务器发起登录请求，所述登录请求中携带有所述子令牌；

所述应用服务器验证所述子令牌是否为真，或是，则所述登录请求通过。

7.根据权利要求6所述的方法，其特征在于，所述验证服务器验证所述子账户用户名和所述主令牌是否符合预设要求包括：

所述验证服务器验证所述子账户用户名和所述主令牌所对应的主账户用户名是否已经授权关联。

8.根据权利要求7所述的方法，其特征在于，所述令牌颁发服务器根据子应用标识，将所述子账户用户名和所述主令牌发送至相应的验证服务器包括：

所述令牌颁发服务器查找所述子应用标识查找对应的认证方式；

所述令牌颁发服务器将所述子账户用户名和所述主令牌发送至认证方式所对应的验证服务器。

9.根据权利要求6所述的方法，其特征在于，所述应用服务器验证所述子令牌是否为真包括：

应用服务器将所述子令牌转发至所述验证服务器；

所述验证服务器验证所述子令牌是否已经注册，若是，则向所述应用服务器返回验证通过信息；

若所述应用服务器接收到所述验证通过信息，则验证所述子令牌为真。

10.单点登录系统，包括如权利要求6所述的单点登录技术中的主令牌获取系统，其特征在于，还包括：

手机端的接口调用模块，用于在获取到登录指令后，向所述令牌转发模块发送登录指令所对应的子账户用户名和子应用标识；

令牌转发模块，还用于向令牌颁发服务器发送获取子令牌请求，所述获取子令牌请求中携带有所述子账户用户名、所述子应用标识和所述主令牌；

令牌颁发服务器，还用于根据子应用标识验证所述手机端是否已经在令牌颁发服务器中注册过；

若是，则令牌颁发服务器，还用于根据子应用标识，将所述子账户用户名和所述主令牌发送至相应的验证服务器；

验证服务器验证，用于所述子账户用户名和所述主令牌是否符合预设要求；若是，则验证服务器，进一步用于将所述子账户用户名所对应的子令牌发送至令牌颁发服务器；

令牌颁发服务器，还用于将所述子令牌发送至所述令牌转发模块；

所述令牌转发模块，还用于将所述子令牌发送至手机端的应用模块；

所述应用模块，用于向所述应用服务器发起登录请求，所述登录请求中携带有所述子令牌；

所述应用服务器，用于验证所述子令牌是否为真，或是，则所述登录请求通过。