CN115809455A - 应用登录控制方法及装置、电子设备、存储介质 - Google Patents

Abstract

本申请的实施例揭示了一种应用登录控制方法及装置、电子设备、存储介质。该方法包括：获取登录通用凭证，登录通用凭证中含有多个应用系统使用自身私钥分别针对凭证内容进行签名处理所得到的签名，凭证内容用于表征多个应用系统中的一个应用系统已成功进行用户身份认证；向隶属于多个应用系统中的任一应用系统的应用发送访问请求，访问请求中携带登录通用凭证，以使应用根据所隶属应用系统对应的公钥对登录通用凭证中含有的相应签名进行验证；在应用对登录通用凭证中含有的相应签名验证通过之后，登录至应用。本申请实施例的技术方案能够适用于云技术、人工智能、智慧交通、区块链等场景，以进行场景中应用的访问，提升应用访问的安全性能。

Description

应用登录控制方法及装置、电子设备、存储介质

技术领域

本申请涉及互联网技术领域，具体而言，涉及一种应用登录控制方法及装置、电子设备、计算机可读存储介质。

背景技术

在具有两级中心建设需求的应用开发项目中，比如某集团公司需建设隶属于集团的父中心应用和分别隶属于集团下各公司的子中心应用，通常两级中心均可以独立运行，子中心不严格依赖于父中心的运行状况，因此需要两级中心均具备身份认证机制，同时还需要两级中心可以相互验证对方身份认证机制颁发的凭证。

在现有的技术实现中，客户端上需要同时存储父中心和子中心颁发的登录凭证才可以正常访问父中心应用或子中心应用，并且登录凭证是随机数形态，访问应用时登录凭证的验证需通过颁发凭证的身份认证机构才能验证有效性，使得父中心和子中心之间需进行较为繁杂的凭证验证，从而导致进行应用访问的性能较差。

发明内容

为解决上述技术问题，本申请的实施例分别提供了一种应用登录控制方法及装置、电子设备、计算机可读存储介质。

根据本申请实施例的一个方面，提供了一种应用登录控制方法，包括：获取登录通用凭证，所述登录通用凭证中含有所述多个应用系统使用自身私钥分别针对凭证内容进行签名处理所得到的签名，所述凭证内容用于表征所述多个应用系统中的一个应用系统已成功进行用户身份认证；向隶属于所述多个应用系统中的任一应用系统的应用发送访问请求，所述访问请求中携带所述登录通用凭证，以使所述应用根据所隶属应用系统对应的公钥对所述登录通用凭证中含有的相应签名进行验证；在所述应用对所述登录通用凭证中含有的相应签名验证通过之后，登录至所述应用。

根据本申请实施例的另一个方面，提供了一种应用登录控制方法，包括：接收隶属于第一应用系统的应用发送的认证请求；根据所述认证请求对客户端进行用户身份认证，并在用户身份认证成功之后生成登录初始凭证，所述登录初始凭证中含有凭证内容和第一签名，所述第一签名是所述第一应用系统使用自身私钥对所述凭证内容进行签名处理得到的；根据第二应用系统对应的认证密钥和所述登录初始凭证，请求所述第二应用系统对所述第一认证系统进行身份认证，并在身份认证成功之后使用自身私钥对所述登录初始凭证中含有的凭证内容进行签名处理得到第二签名，基于所述登录初始凭证中含有的凭证内容和第一签名、以及所述第二签名得到登录通用凭证；将所述第二应用系统发送的登录通用凭证转发至所述客户端，以使所述客户端携带所述登录通用凭证访问隶属于所述第一应用系统或者所述第二应用系统的应用。

根据本申请实施例的另一个方面，提供了一种应用登录控制方法，包括：接收隶属于第一应用系统的应用发送的认证请求；根据所述第一认证请求对客户端进行用户身份认证，并在用户身份认证成功之后生成登录初始凭证，所述登录初始凭证中含有凭证内容和第一签名，所述第一签名是所述第一应用系统使用自身私钥对所述凭证内容进行签名处理得到的；将所述登录初始凭证返回所述客户端，以使所述客户端携带所述登录初始凭证向隶属于第二应用系统的应用发送访问请求，所述第二应用系统基于所述访问请求对所述第一应用系统进行身份认证成功之后，对所述登录初始凭证中含有的凭证内容进行签名处理得到第二签名，并根据所述登录初始凭证中含有的凭证内容和第一签名、以及所述第二签名得到登录通用凭证。

根据本申请实施例的一个方面，提供了一种应用登录控制装置，包括：登录通用凭证获取模块，配置为获取登录通用凭证，所述登录通用凭证中含有所述多个应用系统使用自身私钥分别针对凭证内容进行签名处理所得到的签名，所述凭证内容用于表征所述多个应用系统中的一个应用系统已成功进行用户身份认证；应用访问请求模块，配置为向隶属于所述多个应用系统中的任一应用系统的应用发送访问请求，所述访问请求中携带所述登录通用凭证，以使所述应用根据所隶属应用系统对应的公钥对所述登录通用凭证中含有的相应签名进行验证；应用登录模块，配置为在所述应用对所述登录通用凭证中含有的相应签名验证通过之后，登录至所述应用。

根据本申请实施例的另一个方面，提供了一种应用登录控制装置，包括：认证请求接收模块，配置为接收隶属于第一应用系统的应用发送的认证请求；用户身份认证模块，配置为根据所述认证请求对客户端进行用户身份认证，并在用户身份认证成功之后生成登录初始凭证，所述登录初始凭证中含有凭证内容和第一签名，所述第一签名是所述第一应用系统使用自身私钥对所述凭证内容进行签名处理得到的；身份认证请求模块，配置为根据第二应用系统对应的认证密钥和所述登录初始凭证，请求所述第二应用系统对所述第一认证系统进行身份认证，并在身份认证成功之后使用自身私钥对所述登录初始凭证中含有的凭证内容进行签名处理得到第二签名，基于所述登录初始凭证中含有的凭证内容和第一签名、以及所述第二签名得到登录通用凭证；登录通用凭证转发模块，配置为将所述第二应用系统发送的登录通用凭证转发至所述客户端，以使所述客户端携带所述登录通用凭证访问隶属于所述第一应用系统或者所述第二应用系统的应用。

根据本申请实施例的另一个方面，提供了一种应用登录控制装置，包括：认证请求接收模块，配置为接收隶属于第一应用系统的应用发送的认证请求；用户身份认证模块，配置为根据所述第一认证请求对客户端进行用户身份认证，并在用户身份认证成功之后生成登录初始凭证，所述登录初始凭证中含有凭证内容和第一签名，所述第一签名是所述第一应用系统使用自身私钥对所述凭证内容进行签名处理得到的；登录初始凭证返回模块，配置为将所述登录初始凭证返回所述客户端，以使所述客户端携带所述登录初始凭证向隶属于第二应用系统的应用发送访问请求，所述第二应用系统基于所述访问请求对所述第一应用系统进行身份认证成功之后，对所述登录初始凭证中含有的凭证内容进行签名处理得到第二签名，并根据所述登录初始凭证中含有的凭证内容和第一签名、以及所述第二签名得到登录通用凭证。

根据本申请实施例的一个方面，提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述电子设备实现如前所述的应用登录控制方法。

根据本申请实施例的一个方面，提供了一种计算机可读存储介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行如上所述的应用登录控制方法。

根据本申请实施例的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各种可选实施例中提供的应用登录控制方法。

在本申请的实施例提供的技术方案中，多个应用系统相当于多个中心，通过设置登录通用凭证在多个应用系统之间流通，使得客户端中只需存储一份登录通用凭证即可实现隶属于不同应用系统的应用的登录访问，并且是通过签名的方式来生成登录通过凭证，以及通过验签的方式来进行登录通用凭证的验证，无需不同的应用系统之间频繁地进行凭证验证，从而能够提升应用访问的性能。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术者来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1是现有技术实现中用户基于客户端先登录子中心应用，再登录父中心应用的流程示意图；

图2是现有技术实现中用户基于客户端先登录父中心应用，再登录子中心应用的流程示意图；

图3是本申请的一示例性实施例示出的应用登录控制方法的流程图；

图4是图3所示实施例中的步骤S110在一示例性实施例的流程图；

图5是图3所示实施例中的步骤S110在另一示例性实施例的流程图；

图6是本申请的另一示例性实施例示出的应用登录控制方法的流程图；

图7是本申请的一个示例性应用场景下的应用访问交互流程示意图；

图8是本申请的另一示例性实施例示出的应用登录控制方法的流程图；

图9是本申请的另一个示例性应用场景下的应用访问交互流程示意图；

图10是本申请的一示例性实施例示出的一种应用登录控制装置的框图；

图11是本申请另一示例性实施例示出的一种应用登录控制装置的框图；

图12是本申请另一示例性实施例示出的一种应用登录控制装置的框图；

图13示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

具体实施方式

这里将详细地对示例性实施例执行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

在本申请中提及的“多个”是指两个或者两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

如前所述的，在具有两级中心建设需求的应用开发项目中，通常两级中心均可以独立运行，子中心不严格依赖于父中心的运行状况，因此需要两级中心均具备身份认证机制，同时还需要两级中心可以相互验证对方身份认证机制颁发的凭证。

请参阅图1和图2，图1是现有技术实现中用户基于客户端先登录子中心应用，再登录父中心应用的流程示意图，图2是现有技术实现中用户基于客户端先登录父中心应用，再登录子中心应用的流程示意图。

其中，客户端用于向用户提供子中心应用或者父中心应用的访问入口，例如客户端具体为浏览器，子中心应用和父中心应用相应为网页应用。子中心应用和父中心应用隶属于不同的中心层级，即子中心和父中心，并且父中心对应的层级高于子中心对应的层级，通常而言，层级越高的中心应具有范围更大或者等级越高的数据权限，例如父中心对应于某集团公司，子中心对应于该集团公司下属的子公司，集团公司通常能够获得子公司的多数业务数据，子公司则无法获得集团公司的某些数据。同一中心层级下隶属的应用的数量为一个或多个，例如某集团公司下属的子公司为多个，每个子公司需对应建设独立的应用，子中心下的子中心应用的数量则为多个，本处不对此进行限制。子身份认证中心是子中心对应部署的身份认证机构，用户对访问子中心应用的客户端用户进行身份认证，同理父身份认证中心是父中心对应部署的身份认证机构，例如在实际的应用场景中，子身份认证中心和父身份认证中心是相应部署的认证服务器。

在图1所示的用户通过客户端先登录子中心应用，再登录父中心应用的流程中，客户端先在子身份认证中心进行用户身份认证，并请求获取子中心登录凭证，其中子中心登录凭证是子身份认证中心成功进行用户身份验证之后颁发的登录凭证。子身份认证中心验证还向父身份认证中心获取父中心登录凭证，若父身份认证中心也成功进行用户身份验证，相应颁发父中心登录凭证，并将父中心登录凭证发送给子身份认证中心，使得子身份认证中心向客户端返回父中心登录凭证和子中心登录凭证。随后客户端携带父中心登录凭证和子中心登录凭证登录子中心应用A，子中心应用A根据客户端携带的父中心登录凭证和子中心登录凭证，请求子身份认证中心验证父中心登录凭证和子中心登录凭证的有效性，由于子身份认证中心无法验证父中心登录凭证，则会请求父身份认证中心验证客户端携带的父中心登录凭证的有效性。在父中心登录凭证和子中心登录凭证分别通过有效性验证之后，则允许客户端登录至子中心应用A。用户登录至子中心应用A之后，还携带父中心登录凭证和子中心登录凭证登录父中心应用B，父中心应用B根据客户端携带的父中心登录凭证和子中心登录凭证，请求父身份认证中心验证父中心登录凭证和子中心登录凭证的有效性，由于父身份认证中心无法验证子中心登录凭证，则会请求子身份认证中心验证客户端携带的子中心登录凭证。在父中心登录凭证和子中心登录凭证分别通过有效性验证之后，则允许客户端登录至父中心应用B。

在图2所示的用户通过客户端先登录父中心应用，再登录子中心应用的流程中，客户端先在父身份认证中心进行用户身份认证，并请求获取父中心登录凭证。父身份认证中心验证还向子身份认证中心获取子中心登录凭证，若子身份认证中心也成功进行用户身份验证，相应颁发子中心登录凭证，并将子中心登录凭证发送给父身份认证中心，使得父身份认证中心向客户端返回父中心登录凭证和子中心登录凭证。随后客户端携带父中心登录凭证和子中心登录凭证登录父中心应用B，父中心应用B根据客户端携带的父中心登录凭证和子中心登录凭证，请求父身份认证中心验证父中心登录凭证和子中心登录凭证的有效性，由于父身份认证中心无法验证子中心登录凭证，则会请求子身份认证中心验证客户端所携带的子中心登录凭证。若父中心登录凭证和子中心登录凭证分别通过有效性验证，则允许客户端登录至父中心应用B。用户登录至父中心应用B之后，还携带父中心登录凭证和子中心登录凭证登录子中心应用A，子中心应用A根据客户端携带的父中心登录凭证和子中心登录凭证，请求子身份认证中心验证父中心登录凭证和子中心登录凭证的有效性，由于子身份认证中心无法验证父中心登录凭证，则会请求父身份认证中心验证客户端携带的父中心登录凭证。若父中心登录凭证和子中心登录凭证分别通过有效性验证，则允许客户端登录至子中心应用A。

根据图1和图2所示的流程可以看出，在现有技术中，应用登录流程至少具有如下缺点：

第一、登录凭证是随机数形态，每次登录凭证的验证都要通过颁发凭证的身份认证中心才可以验证凭证的有效性；

第二、父中心和子中心之间的互相认证只能凭证颁发时谁颁发谁验证的方式，导致父中心和子中心之间需要进行较为繁杂的凭证验证过程，流程较为复杂，应用访问性能较差；

第三、客户端上需要同时存储父中心和子中心的登录凭证，存储的数据量相对较大。

本申请的实施例为了解决现有技术中存在的以上至少一个问题，分别提出多种应用登录控制方法，以及提出相应的应用登录控制设备，还提出一种电子设备和一种计算机可读存储介质，以下将针对这些实施例的内容进行详细描述。

请参阅图3，图3是本申请的一示例性实施例示出的一种应用登录控制方法的流程图。该方法可以由用于向用户提供应用访问入口的客户端执行，也即用户基于此客户端可以访问不同的应用，例如客户端具体可以是浏览器等形式，在此不进行限制。

如图3所示，该示例性的应用登录方法至少包括步骤S110至步骤S150，详细介绍如下：

步骤S110，获取登录通用凭证，登录通用凭证中含有多个应用系统使用自身私钥分别针对凭证内容进行签名处理所得到的签名，凭证内容用于表征多个应用系统中的一个应用系统已成功进行用户身份认证。

首先说明的是，本实施例中的多个应用系统对应于应用开发项目中具有多个中心的情况，不同的中心对应不同的应用系统，并且不同的中心均可以独立运行，而不严格依赖于其它中心的运行状况，不同的应用系统中各自设置身份认证机制，例如各自部署有认证服务器用于进行身份认证。示例性的，在前述的某集团公司需建设隶属于集团的父中心应用和分别隶属于集团下各公司的子中心应用的场景下，多个应用系统相应包括父中心和子中心。每个应用系统下隶属有至少一个应用，该隶属关系可理解为应用与对应中心之间的关联性，例如前述集团公司下属的各子公司需要分别建设各自的应用，这些应用均与“集团公司下属”这一中心具有关联，因此可将这些应用称为隶属于“集团公司下属”这一中心对应的应用系统的应用。

还需要说明的是，多个应用系统之间能够进行实时的数据同步，例如在用户注册阶段，用户注册的信息需要在各应用系统进行实时的数据同步，使得用户只需要在其中一个应用系统中进行注册，而不需要分别在每个应用系统中进行注册，以简化用户注册的流程。同时，基于多个应用系统之间所实时同步的数据，使得每个应用系统能够针对已注册的用户进行用户身份认证。

另外还需说明的是，每个应用系统中还需提前预置好一些信息，例如包括自身的公私钥对、其它应用系统对应的公钥、其它应用系统对应的认证密钥、所隶属应用的回调地址等信息。隶属于每个应用系统的应用中也需提前预置好一些信息，例如包括自身隶属的应用系统对应的认证密钥和公钥。应理解的是，某个应用系统对应的密钥用于进行应用系统之间的身份验证，认证密钥通常包括密钥标识和密钥体。回调地址具体是一个URL(Uniform Resource Locator，统一资源定位器)地址，通常对应于应用中含有的特定页面(例如主页)，客户端通过访问回调地址即可实现对于此特定页面的访问。

本实施例设置登录通用凭证作为客户端在不同的应用系统之间进行登录访问的凭证，其目的在于，使得客户端在不同的应用系统之间进行登录访问的过程中减少向认证服器请求验证凭证有效性的次数，也即不同的应用系统之间无需进行频繁的凭证验证，以提高应用访问的效率和性能。

具体来说，登录通用凭证中含有登录凭证，登录凭证是多个应用系统中的其中一个应用系统针对客户端用户成功进行用户身份认证之后，由该应用系统颁发的凭证，因此凭证内容能够表征该应用系统已成功进行用户身份认证。示例性的，凭证内容包括头部信息(可表示为header)和主体(可表示为body)信息，头部信息包括算法标识，该算法是指用于进行签名处理的算法，通常包括消息摘要算法和非对称加密算法，主体信息包括凭证签发者、凭证时效、凭证接收者等至少一种信息，凭证时效是指凭证有效的时限，例如为凭证过期的日期。其中，消息摘要算法是一种密码学算法，它通过对所有数据提供指纹信息以实现数据签名、数据完整性校验等功能；非对称加密算法是一种密钥的保密方法，非对称加密算法需要使用成对的公钥(publickey，公开密钥)和私钥(privatekey，私有密钥)，若使用公钥对数据进行加密，只有使用对应的私钥才能解密，若使用私钥对数据进行签名，则需使用对应的公钥来进行验签。

登录通用凭证中还含有多个应用系统使用自身私钥分别针对凭证内容进行签名处理所得到的签名，其中每个应用系统使用自身私钥对凭证内容进行签名处理的过程是指利用加密算法对凭证内容进行计算的过程。示例性的，若加密算法采用消息摘要算法SM3(由国家密码管理局发布的密码散列函数标准算法)和非对称加密算法SM2(由国家密码管理局发布的椭圆曲线公钥密码算法)，对凭证内容进行签名处理的过程则可表示为如下公式对应的计算过程：

sign＝SM2(header+body,privatekey)+SM3(SM2(header+body,privatekey))

在如上公式中，sign表示签名处理得到的签名结果。由此可以看出，对凭证内容进行签名处理的过程包括先利用应用系统的私钥、并使用SM2算法对凭证内容进行加密计算，以得到第一加密序列，再使用SM3算法对第一加密序列进行加密运算，以得到第二加密序列，将第一加密序列和第二加密序列合并得到的序列来作为最终的签名结果。

需理解的是，不同应用系统具有各自不同的公私钥对，因此不同的应用系统针对凭证内容进行签名处理得到的签名结果应是互不相同的。另外，在实例的应用场景中，用于进行签名处理的加密算法并不限于以上的SM2和SM3算法，可以根据实际需求选择，本实施例不进行限制。

还需理解的是，对于登录通用凭证中含有的多个签名，其中成功进行用户身份认证的应用系统对应的签名能够用于表征该应用程序认可或接受这份凭证，客户端用户在此应用系统下则具有通过性。其它应用系统对应的签名由于是对凭证内容进行签名处理得到的，表示其它应用也认可或接受这份凭证，因此客户端用户在这些应用系统下也应具有通过性。基于此，本实施例仅通过设置一份登录通用凭证，则可使得客户端获得在多个应用系统下的通过性能，无需分别存储不同应用系统颁发的登录凭证，使得客户端存储的数据量以及传输的数据量都较小。

步骤S130，向隶属于多个应用系统中的任一应用系统的应用发送访问请求，访问请求中携带登录通用凭证，以使应用根据所隶属应用系统对应的公钥对登录通用凭证中含有的相应签名进行验证。

客户端在获取到登录通用凭证之后，则可携带登录通用凭证，向隶属于多个应用系统中的任一应用系统的应用发送访问请求。应用接收到客户端发送的访问请求之后，使用自身所隶属应用系统对应的公钥对登录通用凭证中含有的相应签名进行验证。由于签名是应用系统对凭证内容进行签名处理得到的，这表示应用系统认可或接受已成功对客户端用户进行身份认证的应应用系统所颁发的凭证，若应用使用自身所隶属应用系统对应的公钥对登录通用凭证中含有的相应签名进行验证通过，应用则可确定客户端用户已在某个应用系统中成功进行身份认证，并且自身所隶属的应用系统认可或接受相应的认证结果，允许客户端进行登录能够保证安全性。

步骤S150，在该应用对登录通用凭证中含有的相应签名验证通过之后，登录至该应用。

如上所述，应用对登录通用凭证中含有的相应签名验证通过之后允许客户端进行登录，由此使得客户端能够登录至该应用。

还需提及的是，考虑到凭证通常具有时效性，因此在一些示例性的实施例中，应用对登录通用凭证中含有的相应签名验证通过之后，还验证登录通用凭证是否有效，若有效才允许客户端用户登录至应用。其中，通过验证当前时间是否处于登录通用凭证中含有的凭证时效对应的期限内可以得到登录通用凭证是否有效，容易理解的，若当前时间是否处于登录通用凭证中含有的凭证时效对应的期限内，能够表示登录通用凭证是有效的，反之则表示登录通用凭证无效。

由此，本实施例提供的方法提出一种用于在不同应用系统之间流通的登录通用凭证，使得客户端进行应用登录的过程中，仅需要在应用使用自身所隶属的应用系统对应的公钥对登录通用凭证中含有的相应签名进行验证通过后，客户端则可登录至应用，无需在不同的应用系统之间频繁地进行凭证验证，从而有效地提升客户端访问应用的性能和效率。并且，登录通用凭证的组成部分是经由特殊设置的，保证了本实施例提出的应用登录方式是安全可靠的。

在另一些示例性的实施例中，基于具有两级中心建设需求的应用开发项目的应用场景，可设置图3所示实施例中的多个应用系统包括第一应用系统以及第二应用系统。第一应用系统以及第二应用系统中的一个应用系统对应子中心，另一个应用系统则相应对应父中心，本实施例不对此进行限制。

第一应用系统在针对客户端用户成功进行用户身份验证之后生成凭证内容，并使用自身私钥对凭证内容进行签名处理得到第一签名，从而由第一签名和凭证内容形成登录初始凭证。可以看出，登录初始凭证中含有的第一签名只能被隶属于第一应用系统的应用成功验签，因此客户端携带登录初始凭证只能成功登录至隶属于第一应用系统的应用，而无法登录至隶属于第二应用系统的应用。

第二应用系统在对第一应用系统成功进行身份认证之后，使用自身私钥对登录初始凭证中含有的凭证内容进行签名处理得到第二签名，并由登录初始凭证中含有的凭证内容和第一签名，以及所得到的第二签名形成登录通用凭证。示例性的，第二应用系统对第一应用系统进行身份认证的过程可以包括：接收到第一应用系统发送的登录初始凭证之后，使用第一应用系统的公钥对登录初始凭证中含有的第一签名进行验证，若验证通过，则表示第二应用系统对第一应用系统进行身份认证成功。或者，第二应用系统对第一应用系统进行身份认证的过程还可以包括：第一应用系统将登录初始凭证和第二应用系统对应的认证密钥发送至第二应用系统，若第二应用系统验证该认证密钥正确，则表示第二应用系统对第一应用系统进行身份认证成功。例如，第一应用系统将第二应用系统对应的认证密钥作为加密密钥对登录初始凭证进行加密，并将得到的加密数据传输至第二应用系统，使得第二应用系统使用自身对应的认证密钥对加密数据进行解密，以得到登录初始凭证，若能够成功进行解密，则表示第二应用系统对第一应用系统进行身份认证成功。

由上可以看出，本实施例在图3所示实施例的基础上，至少新增了第二应用系统是在对第一应用系统成功进行身份认证之后，使用自身私钥对录初始凭证中含有的凭证内容进行签名处理得到的第二签名，由此加重了第二签名对于登录凭证的凭证属性，换句话说，由第二应用系统在得到第二签名之前对第一应用系统执行的身份验证，使得第二签名具有第一层面的可靠性，并且由于第二签名是第二应用系统针对第一应用系统所颁发的登录初始凭证中含有的凭证内容进行签名处理得到的，表明第二应用系统认可该凭证，使得第二签名具有第二层面的可靠性。由此，在客户端携带登录通用凭证访问第二应用系统下隶属的应用时，该应用使用第二应用系统对应的公钥对第二签名进行验证，所得到的验证通过的结果能够更强烈地表明第二应用系统认可该凭证，该应用允许客户端进行登录则是更加安全和可靠的。

如图4所示，在一示例性的实施例中，在第一应用系统对应的中心层级低于第二应用系统对应的中心层级的情况下，例如第一应用系统对应于子中心，第二应用系统对应于父中心，图3所示的步骤S110中获取的登录通用凭证的过程可以包括步骤S111至步骤S113，详细介绍如下：

步骤S111，向隶属于第一应用系统的应用发送访问请求，以使隶属于第一应用系统的应用在确定用户登录状态为未登录状态之后，请求第一应用系统进行用户身份认证，在用户身份认证成功之后得到登录初始凭证。

本实施例描述的是客户端通过第一应用系统(即子中心)来获取登录通用凭证的情况，首先，客户端向隶属于第一应用系统的应用发送访问请求。该应用接收到访问请求之后，检查客户端对应的用户登录状态为未登录状态或者为已登录状态，若为前者，则需要请求自身隶属的第一应用系统针对客户端用户进行用户身份认证，若成功进行用户身份认证，第一应用系统则相应得到登录初始凭证。

通常而言，若客户端处于“登出”状态，则会判定客户端对应于未登录状态，其中“登出”一般指注销，表示客户端已清除登录的用户账户，清除后该客户端可使用其它的用户账户来登录。

第一应用系统得到登录初始凭证的过程可以包括：向客户端展示登录页面，并获取登录页面中输入的用户认证信息；若确定用户认证信息为合法信息，则确定用户身份认证成功，并生成对应的凭证内容；通过自身私钥对凭证内容进行签名处理得到第一签名，并基于第一签名和凭证内容生成登录初始凭证。用户认证信息是指与用户注册阶段有关的信息，例如包括用户账户和密码，若验证登录页面中输入的用户账户和密码是已存储在的注册用户信息，则确定其为合法信息。

示例性的，若使用ssign表示第一签名，使用header和sbody表示凭证内容的组成内容，其中header表示头部信息，sbody表示主体信息、且凭证颁发者为子应用，使用scertX表示登录初始凭证，所得到的登录通用凭证则可表示如下：

scertX＝(base64(header+sbody+ssign))

需理解的是，“header+sbody+ssign”是登录初始凭证中包含的数据，“base64”表示base64的字节码编码方式，也即登录初始凭证是通过base64的字节码编码方式对“header+sbody+ssign”数据进行字节码编码得到的结果，以便于在网络中进行传输。

若第一应用系统进行签名处理所采用的加密算法采用消息摘要算法SM3和非对称加密算法SM2，第一签名ssign则通过如下公式得到：

ssign＝SM2(header+sbody，sprivkey)+SM3(SM2(header+sbody，sprivkey))

其中，sprivkey表示第一应用系统自身的私钥。

步骤S113，接收第一应用系统针对登录请求返回的登录通用凭证，登录通用凭证是第二应用系统在对第一应用系统成功进行身份认证之后，根据登录初始凭证所得到的。

由于客户端访问子中心应用通常需要获得父中心的允许，因此本实施例中的第一应用系统在得到登录初始凭证之后，还根据所得到的登录初始凭证以及第二应用系统对应的认证密钥，请求第二应用系统生成在第一应用系统和第二应用系统之间流通的登录通用凭证。第二应用系统通过验证认证密钥的正确性来对第一应用系统进行身份认证，在对第一应用系统成功进行身份认证之后，针对登录初始凭证中含有的凭证内容进行签名处理，得到第二签名，从而根据凭证内容、第一签名和第二签名生成登录通用凭证。第二应用系统还将得到的登录通用凭证发送至第一应用系统，第一应用系统将登录通用凭证返回给客户端，以使客户端获取到登录通用凭证。

示例性的，若使用ssign和fsign分别表示第一签名和第二签名，使用header和body表示凭证内容的组成内容，其中header表示头部信息，sbody表示主体信息且凭证颁发者为第一应用系统，以及使用sfcertX表示登录通用凭证，最终得到的登录通用凭证可表示如下：

sfcertX＝(base64(header+sbody+fsign+ssign))

若第一应用系统进行签名处理所采用的加密算法采用消息摘要算法SM3和非对称加密算法SM2，第二应用系统自身的私钥表示为fprivkey，第二签名fsign则通过如下公式得到：

fsign＝SM2(header+sbody,fprivkey)+SM3(SM2(header+sbody,fprivkey))

由此可知，在客户端通过子中心来获取得到登录通用凭证的过程中，子中心和父中心之间只需进行一次凭证验证，而在后续客户端根据登录凭证访问不同中心下的应用时，也不需要子中心和父中心之间进行凭证验证的交互，由此简化客户端访问不同中心下的应用的流程。并且，子中心和父中心之间基于密钥来实现身份认证，使得认证过程简单且可靠。

如图5所示，在另一示例性的实施例中，在第一应用系统对应的中心层级高于第二应用系统对应的中心层级的情况下，例如第一应用系统对应于父中心，第二应用系统对应于子中心，图3所示的步骤S110中获取的登录通用凭证的过程可以包括步骤S112至步骤S118，详细介绍如下：

步骤S112，向隶属于第一应用系统的应用发送访问请求，以使隶属于第一应用系统的应用在确定用户登录状态为未登录状态之后，请求第一应用系统进行用户身份认证，在用户身份认证成功之后得到登录初始凭证。

本实施例描述的是客户端通过先登录隶属于第一应用系统(即父中心)的应用，再登录隶属于第二应用系统(即子中心)来获取得到登录通用凭证的情况。第一应用系统得到登录初始凭证的过程与前述实施例相似，本实施例不进行赘述。

为便于理解本实施例的技术方案，本实施例的下述描述直接将第一应用系统和第二应用系统描述为父中心和子中心，并且将隶属于第一应用系统的应用表示为父中心应用，将隶属于第二应用系统的应用表示为子中心应用。

需要说明的是，由于本实施例是父中心针对客户端用户进行用户身份验证并相应颁发凭证，因此将初始登录凭证表示为fcertX，第一签名表示为fsign，凭证内容的组成内容表示为header和fbody，其中header表示头部信息，fbody表示主体信息且凭证颁发者为父中心，初始登录凭证则表示如下：

fcertX＝(base64(header+fbody+fsign))

若第一应用系统进行签名处理所采用的加密算法采用消息摘要算法SM3和非对称加密算法SM2，第一签名fsign通过如下公式得到：

fsign＝SM2(header+fbody,fprivkey)+SM3(SM2(header+fbody,fprivkey))

其中，fprivkey表示父中心自身的私钥。

步骤S114，接收并存储第一应用系统返回的登录初始凭证。

由于客户端访问父中心应用通常不需要获得子中心的允许，使得本实施例中，父中心在获得登录初始凭证之后，将登录初始凭证返回给客户端，而并非请求子中心针对该凭证进行验证。父中心得到登录初始凭证之后，客户端即可成功登录所请求访问的父中心应用。

步骤S116，基于登录初始凭证向隶属于第二应用系统的应用发送访问请求，以使隶属于第二应用系统的应用在确定登录初始凭证并非由自身所隶属的应用系统生成之后，请求第二应用系统对第一应用系统进行身份认证，并在认证成功之后根据登录初始凭证得到登录通用凭证。

若要获得登录通用凭证，客户端还需根据父中心返回的登录初始凭证，向子中心应用发送访问请求，也即是将登录初始凭证携带在访问请求中。子中心应用接收到该访问请求之后，通过登录初始凭证中含有的凭证颁发者的信息确定登录初始凭证是否由子中心生成，本实施例应确认为登录初始凭证并非由子中心生成。基于此，子中心应用请求子中心对父中心进行身份认证，并在认证成功之后根据登录初始凭证得到登录通用凭证。

子中心应用请求子中心对父中心进行身份认证的过程包括：使用子中心对应的公钥对登录初始凭证中含有的第一签名进行验证，若验证通过，进一步验证凭证的有效性，若验证凭证有效，则针对登录初始凭证中含有的凭证内容进行签名处理，得到第二签名，并根据登录初始凭证中含有的凭证内容和第一签名、以及所得到的第二签名生成登录通用凭证。

示例性的，若使用fsign和ssign分别表示第一签名和第二签名，使用header和fbody表示凭证内容的组成内容，其中header表示头部信息，fbody表示主体信息且凭证颁发者为父中心，以及使用fscertX表示登录通用凭证，本实施例得到的登录通用凭证可表示如下：

fscertX＝(base64(header+fbody+fsign+ssign))

若父中心进行签名处理所采用的加密算法采用消息摘要算法SM3和非对称加密算法SM2，子中心自身的私钥表示为sprivkey，第二签名ssign则通过如下公式得到：

ssign＝SM2(header+fbody,sprivkey)+SM3(SM2(header+fbody,sprivkey))

步骤S118，接收第二应用系统返回的登录通用凭证，并根据登录通用凭证对存储的登录初始凭证进行更新。

客户端接收到子中心返回的登录通用凭证之后，根据登录通用凭证对存储的登录初始凭证进行更新，使得客户端中始终只存储一份凭证，存储的数据量和传输的数据量较小。

本实施例在客户端通过先访问父中心应用，再访问子中心应用来获取得到登录通用凭证的过程中，子中心和父中心之间无需进行凭证验证，在后续客户端根据登录凭证访问不同中心下的应用时，也不需要子中心和父中心之间进行凭证验证的交互，由此简化客户端访问不同中心下的应用的流程。并且，子中心通过父中心对应的公钥来实现父中心的身份认证，此认证过程仍是简单且可靠的。

由上述实施例可以看出，本申请实施例提出的应用登录控制方法通过签名验签的方式来生成凭证和验证凭证，减少应用向应用系统请求验证的凭证，同时采用公私钥技术实现了两级应用系统之间无需进行频繁的验证凭证，并且客户端无需存储两份凭证，只存储一份凭证即可，存储的数据量和传输的数据量都较小。总结来说，本申请的实施例即解决了技术问题，同时又尽量地保证性能和效率足够高。

还需要提及的是，若上述实施例同时来采用国家密码管理局颁发的SM2和SM3算法来进行签名处理，再算法层面保证了安全性，也保证了技术的自主可控。

以下将详细介绍在第一应用系统对应的中心层级低于第二应用系统对应的中心层级的应用场景下，或者在第一应用系统对应的中心层级高于第二应用系统对应的中心层级的应用场景下，第一应用系统进行应用登录控制的流程。

请参阅图6，图6是本申请的另一示例性实施例示出的一种应用登录控制方法的流程图，该方法应用于第一应用系统对应的中心层级低于第二应用系统对应的中心层级的应用场景，并且由第一应用系统具体执行，举例来说，第一应用层级对应于子中心，第二应用系统则相应对应于父中心。如图6所示，该方法至少包括步骤S210至步骤S270，如下：

步骤S210，接收隶属于第一应用系统的应用发送的认证请求，认证请求是隶属于第一应用系统的应用根据客户端发起的应用登录请求，确定客户端对应的用户登录状态为未登录状态之后生成的；

步骤S230，根据认证请求对客户端进行用户身份认证，并在用户身份认证成功之后生成登录初始凭证，登录初始凭证中含有凭证内容和第一签名，第一签名是第一应用系统使用自身私钥对凭证内容进行签名处理得到的；

步骤S250，根据第二应用系统对应的认证密钥和登录初始凭证，请求第二应用系统对第一认证系统进行身份认证，并在身份认证成功之后使用自身私钥对登录初始凭证中含有的凭证内容进行签名处理得到第二签名，基于登录初始凭证中含有的凭证内容和第一签名、以及第二签名得到登录通用凭证；

步骤S270，将第二应用系统发送的登录通用凭证转发至所述客户端，以使客户端携带登录通用凭证访问隶属于第一应用系统或第二应用系统的应用。

可理解的，对应于步骤S210描述的内容，隶属于第一应用系统的应用只有在确定客户端对应的用户登录状态为已登录状态的条件下，才允许客户端访问应用，以确保应用访问的可靠性，也保证了应用数据的安全性，因此应用在确定客户端对应的用户登录状态为未登录状态之后，需请求第一应用系统针对客户端用户进行身份认证，从而向第一应用系统发送认证请求。

对应于步骤S230描述的内容，第一应用系统根据接收到的认证请求，针对客户端进行用户身份认证包括向客户端展示登录页面，并获取登录页面中输入的用户认证信息。如前述实施例中描述的，用户认证信息通常包括用户账户和密码，若第一应用系统确定登录页面中输入的用户认证信息是已注册用户对应的用户账户和密码，则表示客户端用户为合法用户，所输入的用户认证信息为合法信息，由此确定客户端进行用户身份认证成功。第一应用系统在用户身份认证成功之后，先生成凭证内容，然后使用自身私钥对凭证内容进行签名处理，以得到第一签名，然后基于凭证内容和第一签名生成登录初始凭证。

对应于步骤S250描述的内容，由于第一应用系统对应的中心层级低于第二应用系统对应的中心层级，用户访问第一应用系统下隶属的应用通常需得到第二应用系统的允许，因此第一应用系统还根据第二应用系统对应的认证密钥，并携带登录初始凭证请求第二应用系统对第一应用系统进行身份认证。若验证第一应用系统携带的认证密钥是第二应用系统所预置的认证密钥，第一应用系统则通过身份认证。若第二应用系统确定第一应用系统通过身份认证，则表示第二应用系统将信任第一应用系统颁发的凭证，因此使用自身私钥对登录初始凭证中含有的凭证内容进行签名处理，以得到第二签名，并基于登录初始凭证中含有的凭证内容和第一签名、以及得到的第二签名形成登录通用凭证，并将得到的登录通用凭证发送给第一应用系统。

对应于步骤S270描述的内容，第一应用系统将第二应用系统发送的登录通用凭证转发至客户端，使得客户端可以携带登录通用凭证访问隶属于第一应用系统或第二应用系统的任意应用，由此实现登录通用凭证在第一应用系统和第二应用系统之间的流通，在此过程中涉及的凭证验证过程请参见前述实施例中记载的内容，本实施例不进行赘述。

另外考虑到客户端当前请求访问第一应用系统下隶属的应用，因此第一应用系统还可获取本地存储的回调地址，该回调地址用户指示客户端当前请求访问的隶属于第一应用系统的应用中含有的特定页面，然后将获取到的回调地址发送给客户端，以使客户端基于该回调地址访问相应的应用。由此，客户端将会得到回调地址对应的应用页面，而不是得到一个空页面，由此符合客户端进行应用访问的用户需求。

以下通过图7所示的一个示例性应用场景下的交互流程示例图来详细介绍图6所示实施例揭示的应用登录控制方法。在图7所示的应用场景下，子中心应用A对应于图6所示实施例中隶属于第一应用系统的应用，子身份认证中心是第一应用系统部署的身份认证机构；父中心应用B对应于图6所示实施例中隶属于第二应用系统的应用，父身份认证中心是第二应用系统部署的身份认证机构。

如图7所示，用户userX打开客户端并尝试登录子中心应用A，子中心应用A相应检查用户登录状态，若检测为已登录状态，则允许用户登录至应用，若检测为未登录状态，跳转至子身份认证中心。子身份认证中心向客户端展示登录页面，以获取用户再登录页面中输入的身份认证信息，根据身份认证信息对用户进行身份认证，认证成功后为用户生成登录初始凭证scertX＝base64(header+sbody+ssign))，登录初始凭证中含有凭证内容和使用子中心私钥sprivkey对凭证内容进行签名处理得到的第一签名ssign。子身份认证中心还向父身份认证中心为用户申请登录通用凭证，申请时携带登录初始凭证和父中心对应的认证密钥fauthkey和fauthsecret，其中fauthkey表示密钥的标识，fauthsecret表示密钥体。父身份认证中心相应验证认证密钥的正确性，若验证正确，则表示父身份认证中心认可子身份认证中心的身份合法，进而认可子身份认证中为用户颁发的登录凭证，因此使用父中心私钥fprivkey对登录初始凭证中含有的凭证内容进行签名处理，得到第二签名fsign，进而根据登录初始凭证中含有的凭证内容和第一签名、以及得到的签名生成登录通用凭证sfcertX＝(base64(header+sbody+fsign+ssign))。父身份认证中心将得到的登录通用凭证发送给子身份认证中心，子身份认证中心将接收到的登录通用凭证、以及提前预置的子中心应用A对应的回调地址返回给客户端。客户端则存储接收到的登录通用凭证，并携带登录通用凭证向接收到的回调地址发起访问，子中心应用A使用子中心公钥spubkry验证客户端携带的登录通用凭证中含有的第一签名是否正确，若正确则进一步验证登录通用凭证的时效性，若确定凭证有效则允许用户登录至子中心应用A。

另外，客户端在获取到登录通用凭证之后，若用户在同一客户端环境下发起对于父应用B的访问，客户端则携带登录通用凭证向父中心应用B发起应用访问请求。父中心应用B使用父中心公钥fpubkry验证登录通用凭证中含有的第二签名是否正确，若正确则进一步验证登录通用凭证的时效性，若凭证有效则允许该用户登录父中心应用B。

还需要说明的，客户端在获取到登录通用凭证之后，用户可以在同一客户端环境下发起对于隶属于子中心或父中心的任一应用，客户端相应携带登录通用凭证请求访问相应应用，相应应用使用自身所隶属的中心对应的公钥针对登录通用凭证中含有的相应签名进行验签即可，在此不再对此过程进行赘述。

由上可以看出，在获取登录通用凭证的过程中，子身份认证中心与父身份认证中心之间仅进行一次交互验证，在客户端后续访问应用的过程中，对于登录通用凭证的验证不再需要子身份认证中心或父身份认证中心参与凭证验证，简化了客户端进行应用访问的流程，由此能够提升应用访问的性能和效率。

请参阅图8，图8是本申请的另一示例性实施例示出的一种应用登录控制方法的流程图，该方法应用于第一应用系统对应的中心层级高于第二应用系统对应的中心层级的应用场景，并且由第一应用系统具体执行，举例来说，第一应用层级对应于父中心，第二应用系统则相应对应于子中心。如图8所示，该方法至少包括步骤S310至步骤S350，如下：

步骤S310，接收隶属于第一应用系统的应用发送的认证请求，认证请求是隶属于第一应用系统的应用根据客户端发起的应用登录请求，确定客户端对应的用户登录状态为未登录状态之后生成的；

步骤S330，根据第一认证请求对所述客户端进行用户身份认证，并在用户身份认证成功之后生成登录初始凭证，登录初始凭证中含有凭证内容和第一签名，第一签名是所述第一应用系统使用自身私钥对凭证内容进行签名处理得到的；

步骤S350，将登录初始凭证返回客户端，以使客户端携带登录初始凭证向隶属于第二应用系统的应用发送访问请求，第二应用系统基于访问请求对第一应用系统进行身份认证成功之后，对登录初始凭证中含有的凭证内容进行签名处理得到第二签名，并根据登录初始凭证中含有的凭证内容和第一签名、以及第二签名得到登录通用凭证。

上述对应于步骤S310和步骤S330描述的内容与图6所示实施例中步骤S210和步骤S230所描述的内容相似，本实施例不再进行赘述。

对应于步骤S350描述的内容，本实施例由于第一应用系统对应的中心层级高于第二应用系统对应的中心层级，用户访问第一应用系统下隶属的应用通常不需要得到第二应用系统的允许，因此第一应用系统直接将登录初始凭证返回给客户端，以使客户端携带登录初始凭证请求访问隶属于第二应用系统的应用，以在此过程中获取登录通用凭证。具体来说，隶属于第二应用系统的应用根据登录初始凭证中含有的凭证颁发者的信息判断这是否为第二应用系统颁发的登录凭证，并判断为否，然后请求第二应用系统对此凭证进行验证，也相当于是对第一应用系统进行身份认证，认证成功之后考虑到凭证时效性，还进一步根据登录通用凭证中含有的凭证时限确定凭证是否有效，在确定为是的条件下通过自身私钥对登录初始凭证中含有的凭证内容进行签名处理得到第二签名，并根据登录初始凭证中含有的凭证内容和第一签名、以及第二签名得到登录通用凭证。

以下通过图9所示的一个示例性应用场景下的交互流程示例图来详细介绍图8所示实施例揭示的应用登录控制方法。在图9所示的应用场景下，父中心应用B对应于图8所示实施例中隶属于第一应用系统的应用，父身份认证中心是第一应用系统部署的身份认证机构；子中心应用A对应于图8所示实施例中隶属于第二应用系统的应用，子身份认证中心是第二应用系统部署的身份认证机构。

如图9所示，用户userX打开客户端并尝试登录父中心应用B，父中心应用B相应检查用户登录状态，若检测为已登录状态，则允许用户登录至应用，若检测为未登录状态，跳转至父身份认证中心。父身份认证中心向客户端展示登录页面，以获取用户在登录页面中输入的身份认证信息，根据身份认证信息对用户进行身份认证，认证成功后为用户生成登录初始凭证fcertX＝(base64(header+fbody+fsign))，登录初始凭证中含有凭证内容和使用父中心私钥fprivkey对凭证内容进行签名处理得到的第一签名fsign。父身份认证中心得到的登录初始凭证、以及提前预置的父中心应用B对应的回调地址返回给客户端。客户端相应存储接收到的登录初始凭证，并携带登录初始凭证向接收到的回调地址发起访问，父中心应用B使用父中心公钥fpubkry验证客户端携带的登录初始凭证中含有的第一签名是否正确，若正确则进一步验证登录初始凭证的时效性，若确定凭证有效则允许用户登录至父中心应用B。

客户端在获取到登录初始凭证之后，若用户在同一客户端环境下发起对于子中心应用A的访问，客户端则携带登录初始凭证向子中心应用A发起应用访问请求。子中心应用A根据登录初始凭证中含有的标记，例如凭证内容中含有的凭证颁发者的信息，判断登录初始凭证并不是子中心颁发的凭证，从而请求子身份认证中心验证凭证。子身份认证中心使用父中心公钥fpubkry验证登录初始凭证中含有的第一签名是否正确，若正确则进一步验证登录初始凭证的时效性，若凭证有效则使用子中心私钥sprivkey针对登录初始凭证中含有的凭证内容进行签名处理得到第二签名ssign，并根据登录初始凭证中含有的凭证内容和第一签名，以及所得到的第二签名生成登录通用凭证fscertX＝(base64(header+fbody+fsign+ssign))，并向登录通用凭证和子中心应用A对应的回调地址返回给客户端。客户端根据接收到的登录通用凭证更新之前存储的登录初始凭证，然后携带登录通用凭证访问子中心应用A。子中心应用A使用子中心公钥spubkry验证客户端携带的登录通用凭证中含有的第二签名是否正确，若正确则进一步验证登录通用凭证的时效性，若确定凭证有效则允许用户登录至子中心应用A。

仍需要说明的，客户端在获取到登录通用凭证之后，用户可以在同一客户端环境下发起对于隶属于子中心或父中心的任一应用，客户端相应携带登录通用凭证请求访问相应应用，相应应用使用自身所隶属的中心对应的公钥针对登录通用凭证中含有的相应签名进行验签即可，在此也不进行赘述。

由上可以看出，在获取登录通用凭证的过程中，子身份认证中心与父身份认证中心之间无需进行交互验证，仅需子中心使用父中心公钥对登录初始凭证中含有的签名进行验证即可，在客户端后续访问应用的过程中，对于登录通用凭证的验证也不再需要子身份认证中心或父身份认证中心参与凭证验证，简化了客户端进行应用访问的流程，由此也能够提升应用访问的性能和效率。

另外还需提及的是，以上实施例所提供的技术方案能够适用于云技术、人工智能、智慧交通、区块链等场景，以进行这些场景中部署的应用的访问，能够提升应用访问的安全性能。这些场景对应于应用开发项目中具有多个中心的情况，不同的中心对应不同的应用系统，并且不同的中心均可以独立运行，而不严格依赖于其它中心的运行状况，不同的应用系统中各自设置身份认证机制。

例如在云技术场景下，第一应用系统所部署的身份认证中心以及第二应用系统所部署的身份认证中心可以部署在云端，例如具体是部署在云端的云认证服务器。

或者在区块链场景下，上述实施例中提及的公钥、认证密钥等非私有的信息可以存储在区块链上，应用或身份认证中心可以按需从区块链中相应获取，如果一方修改了自身设置的密钥信息，多方可以及时获知，由此保证了数据更新的及时性。应理解的是，区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。

或者在智慧交通场景下，第一应用系统和第二应用系统可以对应于具有交通管辖权的一级部门和二级部门，例如省级交管部门与市级交管部门，第一应用系统和第二应用系统下隶属的应用可以部署相应的功能，例如辖区内地图数据的查询，又或者管辖区域内所部署物联网下车辆、行人、道路设施所上报信息的查询等，在此不进行限定。

图10是本申请的一示例性实施例示出的一种应用登录控制装置的框图。如图10所示，该示例性的应用登录控制装置400包括：

登录通用凭证获取模块410，配置为获取登录通用凭证，登录通用凭证中含有多个应用系统使用自身私钥分别针对凭证内容进行签名处理所得到的签名，凭证内容用于表征多个应用系统中的一个应用系统已成功进行用户身份认证；应用访问请求模块430，配置为向隶属于多个应用系统中的任一应用系统的应用发送访问请求，访问请求中携带登录通用凭证，以使应用根据所隶属应用系统对应的公钥对登录通用凭证中含有的相应签名进行验证；应用登录模块450，配置为在应用对登录通用凭证中含有的相应签名验证通过之后，登录至应用。

在另一示例性的实施例中，多个应用系统包括第一应用系统和第二应用系统；第一应用系统在成功进行用户身份认证之后生成凭证内容，并使用自身私钥对凭证内容进行签名处理得到第一签名，由第一签名和凭证内容形成登录初始凭证；第二应用系统在对第一应用系统成功进行身份认证之后，使用自身私钥对登录初始凭证中含有的凭证内容进行签名处理得到第二签名，由登录初始凭证中含有的凭证内容和第一签名、以及第二签名形成登录通用凭证。

在另一示例性的实施例中，第一应用系统对应的中心层级低于第二应用系统对应的中心层级；登录通用凭证获取模块410包括：

第一访问请求发送单元，配置为向隶属于第一应用系统的应用发送访问请求，以使隶属于第一应用系统的应用在确定用户登录状态为未登录状态之后，请求第一应用系统进行用户身份认证，在用户身份认证成功之后得到登录初始凭证；第一登录通用凭证接收模块，配置为接收第一应用系统针对登录请求返回的登录通用凭证，登录通用凭证是第二应用系统在对第一应用系统成功进行身份认证之后，根据登录初始凭证所得到的。

在另一示例性的实施例中，第一应用系统对应的中心层级高于第二系统对应的中心层级；登录通用凭证获取模块410包括：

第二访问请求发送模块，配置为向隶属于第一应用系统的应用发送访问请求，以使隶属于第一应用系统的应用在确定用户登录状态为未登录状态之后，请求第一应用系统进行用户身份认证，在用户身份认证成功之后得到登录初始凭证；登录初始凭证接收单元，配置为接收并存储第一应用系统返回的登录初始凭证；第三访问请求发送模块，配置为基于登录初始凭证向隶属于第二应用系统的应用发送访问请求，以使隶属于第二应用系统的应用在确定登录初始凭证并非由自身所隶属的应用系统生成之后，请求第二应用系统对第一应用系统进行身份认证，并在认证成功之后根据登录初始凭证得到登录通用凭证；第二登录通用凭证接收模块，配置为接收第二应用系统返回的登录通用凭证，并根据登录通用凭证对存储的登录初始凭证进行更新。

在另一示例性的实施例中，登录通用凭证中还含有凭证时限；应用登录模块450配置为在应用对登录通用凭证中含有的相应签名验证通过之后，若根据登录通用凭证中含有的凭证时限确定凭证有效，则登录至应用。

图11是本申请另一示例性实施例示出的一种应用登录控制装置的框图。如图11所示，该示例性的应用登录控制装置500包括：

认证请求接收模块510，配置为接收隶属于第一应用系统的应用发送的认证请求，认证请求是隶属于第一应用系统的应用根据客户端发起的应用登录请求，确定客户端对应的用户登录状态为未登录状态之后生成的；用户身份认证模块530，配置为根据认证请求对客户端进行用户身份认证，并在用户身份认证成功之后生成登录初始凭证，登录初始凭证中含有凭证内容和第一签名，第一签名是第一应用系统使用自身私钥对凭证内容进行签名处理得到的；身份认证请求模块550，配置为根据第二应用系统对应的认证密钥和登录初始凭证，请求第二应用系统对第一认证系统进行身份认证，并在身份认证成功之后使用自身私钥对登录初始凭证中含有的凭证内容进行签名处理得到第二签名，基于登录初始凭证中含有的凭证内容和第一签名、以及第二签名得到登录通用凭证；登录通用凭证转发模块570，配置为将第二应用系统发送的登录通用凭证转发至客户端，以使客户端携带登录通用凭证访问隶属于第一应用系统或者第二应用系统的应用。

在另一示例性的实施例中，用户身份认证模块530包括：

用户认证信息获取单元，配置为向客户端展示登录页面，获取登录页面中输入的用户认证信息；凭证内容生成单元，配置为若确定用户认证信息为合法信息，则确定用户身份认证成功，并生成对应的凭证内容；

登录初始凭证生成单元，配置为通过自身私钥对凭证内容进行签名处理得到第一签名，并基于第一签名和凭证内容生成登录初始凭证。

在另一示例性的实施例中，该装置还包括：

回调地址获取模块，配置为获取本地存储的回调地址，回调地址用于指示隶属于第一应用系统的应用所含有的特定页面；回调地址发送模块，配置为将回调地址发送至客户端，以使客户端基于回调地址访问隶属于第一应用系统的应用。

图12是本申请另一示例性实施例示出的一种应用登录控制装置的框图。如图12所示，该示例性的应用登录控制装置600包括：

认证请求接收模块610，配置为接收隶属于第一应用系统的应用发送的认证请求，认证请求是隶属于第一应用系统的应用根据客户端发起的应用登录请求，确定客户端对应的用户登录状态为未登录状态之后生成的；用户身份认证模块630，配置为根据第一认证请求对客户端进行用户身份认证，并在用户身份认证成功之后生成登录初始凭证，登录初始凭证中含有凭证内容和第一签名，第一签名是第一应用系统使用自身私钥对凭证内容进行签名处理得到的；登录初始凭证返回模块650，配置为将登录初始凭证返回客户端，以使客户端携带登录初始凭证向隶属于第二应用系统的应用发送访问请求，第二应用系统基于访问请求对第一应用系统进行身份认证成功之后，对登录初始凭证中含有的凭证内容进行签名处理得到第二签名，并根据登录初始凭证中含有的凭证内容和第一签名、以及第二签名得到登录通用凭证。

在另一示例性的实施例中，第二应用系统根据本地存储的第一应用系统对应的公钥对登录初始凭证中含有的第一签名进行验证，在验证通过之后，若根据登录通用凭证中含有的凭证时限确定凭证有效，则确定第一应用系统的身份认证成功。

需要说明的是，上述实施例所提供的装置与上述实施例所提供的应用登录控制方法属于同一构思，其中各个模块和单元执行操作的具体方式已经在方法实施例中进行了详细描述，此处不再赘述。

本申请的实施例还提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述电子设备实现上述各个实施例中提供的应用登录控制方法。

图13示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

需要说明的是，图13示出的电子设备的计算机系统800仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图13所示，计算机系统800包括中央处理单元(Central Processing Unit，CPU)801，其可以根据存储在只读存储器(Read-Only Memory，ROM)802中的程序或者从储存部分808加载到随机访问存储器(Random Access Memory，RAM)803中的程序而执行各种适当的动作和处理，例如执行上述实施例中所述的方法。在RAM 803中，还存储有系统操作所需的各种程序和数据。CPU 801、ROM 802以及RAM 803通过总线804彼此相连。输入/输出(Input/Output，I/O)接口805也连接至总线804。

以下部件连接至I/O接口805：包括键盘、鼠标等的输入部分806；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分807；包括硬盘等的储存部分808；以及包括诸如LAN(Local Area Network，局域网)卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至I/O接口805。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入储存部分808。

特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的计算机程序。在这样的实施例中，该计算机程序可以通过通信部分809从网络上被下载和安装，和/或从可拆卸介质811被安装。在该计算机程序被中央处理单元(CPU)801执行时，执行本申请的系统中限定的各种功能。

需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的计算机程序。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

本申请的另一方面还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如前所述的应用登录控制方法。该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的，也可以是单独存在，而未装配入该电子设备中。

本申请的另一方面还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各个实施例中提供的应用登录控制方法。

上述内容，仅为本申请的较佳示例性实施例，并非用于限制本申请的实施方案，本领域普通技术人员根据本申请的主要构思和精神，可以十分方便地进行相应的变通或修改，故本申请的保护范围应以权利要求书所要求的保护范围为准。

Claims (17)

1.一种应用登录控制方法，其特征在于，所述方法包括：

获取登录通用凭证，所述登录通用凭证中含有所述多个应用系统使用自身私钥分别针对凭证内容进行签名处理所得到的签名，所述凭证内容用于表征所述多个应用系统中的一个应用系统已成功进行用户身份认证；

向隶属于所述多个应用系统中的任一应用系统的应用发送访问请求，所述访问请求中携带所述登录通用凭证，以使所述应用根据所隶属应用系统对应的公钥对所述登录通用凭证中含有的相应签名进行验证；

在所述应用对所述登录通用凭证中含有的相应签名验证通过之后，登录至所述应用。

2.根据权利要求1所述的方法，其特征在于，所述多个应用系统包括第一应用系统和第二应用系统；

所述第一应用系统在成功进行用户身份认证之后生成凭证内容，并使用自身私钥对所述凭证内容进行签名处理得到第一签名，由所述第一签名和所述凭证内容形成登录初始凭证；

所述第二应用系统在对所述第一应用系统成功进行身份认证之后，使用自身私钥对所述登录初始凭证中含有的凭证内容进行签名处理得到第二签名，由所述登录初始凭证中含有的凭证内容和第一签名、以及所述第二签名形成所述登录通用凭证。

3.根据权利要求1或2所述的方法，其特征在于，所述第一应用系统对应的中心层级低于所述第二应用系统对应的中心层级；所述获取登录通用凭证，包括：

向隶属于所述第一应用系统的应用发送访问请求，以使隶属于所述第一应用系统的应用在确定用户登录状态为未登录状态之后，请求所述第一应用系统进行用户身份认证，在用户身份认证成功之后得到登录初始凭证；

接收第一应用系统针对所述登录请求返回的登录通用凭证，所述登录通用凭证是所述第二应用系统在对所述第一应用系统成功进行身份认证之后，根据所述登录初始凭证所得到的。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

隶属于所述第一应用系统的应用在确定用户登录状态为未登录状态之后，向所述第一应用系统部署的身份认证中心发送认证请求；

所述第一应用系统部署的身份认证中心根据所述认证请求对客户端进行用户身份认证，并在用户身份认证成功之后生成登录初始凭证，且根据第二应用系统部署的身份认证中心的认证密钥和所述登录初始凭证，请求所述第二应用系统部署的身份认证中心对所述第一认证系统部署的身份认证中心进行身份认证；

所述第二应用系统部署的身份认证中心在对所述第一认证系统部署的身份认证中心进行身份认证成功之后，使用自身私钥对所述登录初始凭证中含有的凭证内容进行签名处理得到第二签名，基于所述登录初始凭证中含有的凭证内容和第一签名、以及所述第二签名得到登录通用凭证，并将得到的登录通用凭证发送至所述第一应用系统部署的身份认证中心；

所述第一应用系统部署的身份认证中心将接收到的登录通用凭证转发至所述客户端。

5.根据权利要求4所述的方法，其特征在于，所述第一应用系统部署的身份认证中心根据所述认证请求对客户端进行用户身份认证，并在用户身份认证成功之后生成登录初始凭证，包括：

所述第一应用系统部署的身份认证中心向所述客户端展示登录页面，并获取所述登录页面中输入的用户认证信息，若确定所述用户认证信息为合法信息，则确定用户身份认证成功，生成对应的凭证内容；

通过自身私钥对所述凭证内容进行签名处理得到第一签名，并基于所述第一签名和所述凭证内容生成登录初始凭证。

6.根据权利要求4所述的方法，其特征在于，所述方法还包括：

所述第一应用系统部署的身份认证中心还获取本地存储的回调地址，所述回调地址用于指示所述隶属于第一应用系统的应用所含有的特定页面；

将所述回调地址和所述登录通用凭证共同发送至所述客户端，以使所述客户端基于所述回调地址访问所述隶属于第一应用系统的应用。

7.根据权利要求1或2所述的方法，其特征在于，所述第一应用系统对应的中心层级高于所述第二系统对应的中心层级；所述获取登录通用凭证，包括：

向隶属于所述第一应用系统的应用发送访问请求，以使隶属于所述第一应用系统的应用在确定用户登录状态为未登录状态之后，请求所述第一应用系统进行用户身份认证，在用户身份认证成功之后得到登录初始凭证；

接收并存储所述第一应用系统返回的登录初始凭证；

基于所述登录初始凭证向隶属于所述第二应用系统的应用发送访问请求，以使隶属于所述第二应用系统的应用在确定所述登录初始凭证并非由自身所隶属的应用系统生成之后，请求所述第二应用系统对所述第一应用系统进行身份认证，并在认证成功之后根据所述登录初始凭证得到登录通用凭证；

接收所述第二应用系统返回的登录通用凭证，并根据所述登录通用凭证对存储的登录初始凭证进行更新。

8.根据权利要求7所述的方法，其特征在于，隶属于所述第一应用系统的应用在确定用户登录状态为未登录状态之后，请求所述第一应用系统进行用户身份认证，在用户身份认证成功之后得到登录初始凭证，包括：

隶属于所述第一应用系统的应用在确定用户登录状态为未登录状态之后，向所述第一应用系统部署的身份认证中心发送认证请求；

所述第一应用系统部署的身份认证中心根据所述认证请求对客户端进行用户身份认证，并在用户身份认证成功之后生成登录初始凭证，且将所述登录初始凭证以及所述第一应用系统所隶属的应用对应的回调地址返回至所述客户端。

9.根据权利要求7所述的方法，其特征在于，使隶属于所述第二应用系统的应用在确定所述登录初始凭证并非由自身所隶属的应用系统生成之后，请求所述第二应用系统对所述第一应用系统进行身份认证，并在认证成功之后根据所述登录初始凭证得到登录通用凭证，包括：

隶属于所述第二应用系统的应用在确定所述登录初始凭证并非由自身所隶属的应用系统生成之后，向所述第二应用系统部署的身份认证中心发送携带所述登录初始凭证的认证请求；

所述第二应用系统部署的身份认证中心响应于所述认证请求，根据本地存储的所述第一应用系统部署的身份认证中心的公钥对所述登录初始凭证中含有的第一签名进行验证，在验证通过之后根据所述登录初始凭证得到登录通用凭证。

10.根据权利要求9所述的方法，其特征在于，所述方法还包括：

在所述登录初始凭证中含有的第一签名进行验证通过之后，若所述第二应用系统部署的身份认证中心根据所述登录通用凭证中含有的凭证时限确定凭证有效，则根据所述登录初始凭证得到登录通用凭证。

11.根据权利要求1或2所述的方法，其特征在于，所述登录通用凭证中还含有凭证时限；所述在所述应用对所述登录通用凭证中含有的相应签名验证通过之后，登录至所述应用，包括：

在所述应用对所述登录通用凭证中含有的相应签名验证通过之后，若根据所述登录通用凭证中含有的凭证时限确定凭证有效，则登录至所述应用。

12.一种应用登录控制方法，其特征在于，所述方法包括：

接收隶属于第一应用系统的应用发送的认证请求；

根据所述认证请求对客户端进行用户身份认证，并在用户身份认证成功之后生成登录初始凭证，所述登录初始凭证中含有凭证内容和第一签名，所述第一签名是所述第一应用系统使用自身私钥对所述凭证内容进行签名处理得到的；

根据第二应用系统对应的认证密钥和所述登录初始凭证，请求所述第二应用系统对所述第一认证系统进行身份认证，并在身份认证成功之后使用自身私钥对所述登录初始凭证中含有的凭证内容进行签名处理得到第二签名，基于所述登录初始凭证中含有的凭证内容和第一签名、以及所述第二签名得到登录通用凭证；

将所述第二应用系统发送的登录通用凭证转发至所述客户端，以使所述客户端携带所述登录通用凭证访问隶属于所述第一应用系统或者所述第二应用系统的应用。

13.一种应用登录控制方法，其特征在于，所述方法包括：

接收隶属于第一应用系统的应用发送的认证请求；

根据所述认证请求对客户端进行用户身份认证，并在用户身份认证成功之后生成登录初始凭证，所述登录初始凭证中含有凭证内容和第一签名，所述第一签名是所述第一应用系统使用自身私钥对所述凭证内容进行签名处理得到的；

将所述登录初始凭证返回所述客户端，以使所述客户端携带所述登录初始凭证向隶属于第二应用系统的应用发送访问请求，所述第二应用系统基于所述访问请求对所述第一应用系统进行身份认证成功之后，对所述登录初始凭证中含有的凭证内容进行签名处理得到第二签名，并根据所述登录初始凭证中含有的凭证内容和第一签名、以及所述第二签名得到登录通用凭证。

14.一种应用登录控制装置，其特征在于，所述装置包括：

登录通用凭证获取模块，配置为获取登录通用凭证，所述登录通用凭证中含有所述多个应用系统使用自身私钥分别针对凭证内容进行签名处理所得到的签名，所述凭证内容用于表征所述多个应用系统中的一个应用系统已成功进行用户身份认证；

应用访问请求模块，配置为向隶属于所述多个应用系统中的任一应用系统的应用发送访问请求，所述访问请求中携带所述登录通用凭证，以使所述应用根据所隶属应用系统对应的公钥对所述登录通用凭证中含有的相应签名进行验证；

应用登录模块，配置为在所述应用对所述登录通用凭证中含有的相应签名验证通过之后，登录至所述应用。

15.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述电子设备实现如权利要求1至13中任一项所述的应用登录控制方法。

16.一种计算机可读存储介质，其特征在于，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行权利要求1至13中任一项所述的应用登录控制方法。

17.一种计算机程序产品，包括计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至13中任一项所述的应用登录控制方法中的步骤。

Images