CN114499977B - 一种认证方法及装置 - Google Patents

Abstract

本申请应用于IT认证授权技术领域，提供了一种认证方法及装置，用于提高认证可靠性和认证效率。该方法包括：第一设备接收认证请求，所述认证请求包括待认证的客户端的信息和请求的第一范围，其中，所述客户端与第二范围相关联；所述第一设备根据所述客户端的信息获取所述客户端关联的租户的信息，所述租户与第三范围相关联；所述第一设备确定所述第三范围包括所述第二范围，且所述第一范围属于所述第二范围；所述第一设备输出认证结果，所述认证结果指示所述客户端通过认证。

Description

一种认证方法及装置

技术领域

本申请涉及信息技术(Information Technology，IT)认证授权技术领域，尤其涉及一种认证方法及装置。

背景技术

公开标识连接核心(OpenID Connect Core，OIDC)协议1.0和公开认证(OpenAuthorization，OAuth)协议2.0(RFC6749)是现在流行的标准工业认证授权协议。其中，OIDC在OAuth2.0的标准流程上增加了用户身份的识别层，明确了或客户端(client)标识(client id)、范围(scope)、密钥(secret/client secret)、流程类型(grant type)和用户(user/subject)等概念模型(或称为资源)，以及利用这些资源实现的几种标准的认证授权流程。

然而，协议中并没有提到这些资源之间的隔离机制，可能会导致认证混乱。以客户端为例，如果不同客户端对应的其他资源之间没有适当的隔离机制，可能导致不同客户允许接入的资源不清晰，导致对于客户端的资源的认证过程需要在过大的资源范围内进行，造成认证效率降低和可靠性降低。

发明内容

本申请提供了一种认证方法及装置，用以提高服务端对于客户端的认证效率和可靠性。

第一方面，本申请提供了一种认证方法，该方法包括：第一设备接收认证请求，所述认证请求包括待认证的客户端的信息和请求的第一范围，其中，所述客户端与第二范围相关联；所述第一设备根据所述客户端的信息获取所述客户端关联的租户的信息，所述租户与第三范围相关联；所述第一设备确定所述第三范围包括所述第二范围，且所述第一范围属于所述第二范围；所述第一设备输出认证结果，所述认证结果指示所述客户端通过认证。

基于以上方法，可以通过设置关联的租户对客户端进行隔离，因此可以仅在租户对应的资源范围内进行认证，避免在全部可用资源内对客户端进行认证以提高认证可靠性和认证效率。

在一种可能的设计中，所述方法还包括：所述第一设备获取所述客户端输入的用户凭据；所述第一设备根据所述租户的信息获取所述租户对应的用户凭据；所述第一设备确定所述客户端的用户凭据与所述租户对应的用户凭据匹配。因此可通过以租户为单位设置的用户凭据对用户进行隔离，进一步提高安全性。

在一种可能的设计中，所述客户端为面向客户的客户端，所述租户为面向客户的客户端对应的租户；或者，所述客户端为面向企业的客户端，所述租户为面向企业的客户端对应的租户。因此可通过针对toB用户和toC用户分别设置不同的租户，进一步提高安全性，并能够提高管理效率。

在一种可能的设计中，所述客户端为面向客户的客户端，所述客户端允许访问的资源包括第一资源，所述客户端为面向客户的客户端，所述客户端允许访问的资源包括第二资源，所述第一资源与所述第二资源不同；所述方法还包括：所述第一设备判断所述客户端允许访问的资源包括所述第一范围。因此可通过针对toB用户和toC用户分别设置资源，避免不同类型的用户之间的资源混用，提高管理效率和安全性。

第二方面，本申请提供了一种认证方法，该方法包括：第二设备发送认证请求，所述认证请求包括待认证的客户端的信息和请求的第一范围，其中，所述客户端与第二范围相关联，所述客户端的信息用于获取所述客户关联的租户的信息，所述租户与第三范围相关联，所述第三范围包括所述第二范围，且所述第一范围属于所述第二范围；所述第二设备接收认证结果，所述认证结果指示所述客户端通过认证。

在一种可能的设计中，所述客户端为面向企业的客户端，所述方法还包括：所述第二设备获得所述客户端的注册信息，所述注册信息是所述客户端在租户管理员的授权下获得的。

在一种可能的设计中，所述方法还包括：所述第二设备向所述第一设备发送所述客户端输入的用户凭据，所述客户端的用户凭据与所述租户对应的用户凭据匹配。

在一种可能的设计中，所述客户端为面向客户的客户端，所述客户端允许访问的资源包括第一资源，所述客户端为面向客户的客户端，所述客户端允许访问的资源包括第二资源，所述第一资源与所述第二资源不同。

在一种可能的设计中，所述客户端为面向客户的客户端，所述租户为面向客户的客户端对应的租户；或者，所述客户端为面向企业的客户端，所述租户为面向企业的客户端对应的租户。

第三方面，本申请还提供了一种认证装置，该装置包括处理模块和收发模块，用于实现第一方面及其任一可能的设计所示方法。

第四方面，本申请还提供了一种认证装置，该装置包括处理模块和收发模块，用于实现第二方面及其任一可能的设计所示方法。

第五方面，本申请还提供了一种电子设备，所述电子设备包括处理器，所述处理器用于执行存储器中存储的计算机程序时实现如上述第一方面及其任一可能的设计所述业务受理控制方法的步骤。

第六方面，本申请还提供了一种电子设备，所述电子设备包括处理器，所述处理器用于执行存储器中存储的计算机程序时实现如上述第二方面及其任一可能的设计所述业务受理控制方法的步骤。

第七方面，本申请还提供了一种计算机可读存储介质，其存储有计算机程序，所述计算机程序被处理器执行时实现如上述第一方面及其任一可能的设计所述业务受理控制方法的步骤。

第八方面，本申请还提供了一种计算机可读存储介质，其存储有计算机程序，所述计算机程序被处理器执行时实现如上述第二方面及其任一可能的设计所述业务受理控制方法的步骤。

第九方面，本申请还提供了一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现如第一方面及其任一可能的设计所述业务受理控制方法的步骤。

第十方面，本申请还提供了一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现如第二方面及其任一可能的设计所述业务受理控制方法的步骤。

另外，第二方面至第十方面所带来的技术效果可参见上述第一方面的描述，此处不再赘述。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为一种客户端认证过程的流程示意图；

图2为一种服务发现协议的返回结果示意图；

图3为本申请实施例提供的一种认证方法的流程示意图；

图4为本申请实施例提供的另一种认证方法的流程示意图；

图5为本申请实施例提供的一种code过程的流程示意图；

图6为一种资源分配关系示意图；

图7为本申请实施例提供的一种资源分配关系示意图；

图8为本申请实施例提供的一种认证装置的结构示意图；

图9为本申请实施例提供的另一种认证装置的结构示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，显然，所描述的实施例仅仅是本申请的一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。本申请技术方案中对数据的获取、存储、使用、处理等均符合国家法律法规的相关规定。

目前在OIDC和OAuth2.0的标准流程中没有涉及对于客户端的隔离设计，可能导致不同客户端的准入判定可能互相有影响，造成一次请求的准入范围的扩大。同时，在公有云的场景下，在系统开放出去给第三方设备接入时，第三方设备没法针对这些资源进行自主管理(针对企业场景)，如要做到这一点，完全依赖各个协议实现方的自定义实现，实现方式千变万化，有的可能破坏了现有的标准协议，导致OIDC和OAuth2.0等标准不再使用。

目前，OIDC和OAuth2.0要求的基本流程包括：客户认证(client credential)、授权码(code)、隐式(implict)和密码(password)流程，此外，还有现在针对移动端本地程序的设备流(device flow)流程(引入了PKCE来避免client secret的泄露造成的安全问题)，这些标准流程都需要接入端设备传递一个客户端标识到认证授权服务器去，再由服务器根据客户端标识找到对应的客户端，然后进行后续的处理。

identityServer4(以下简称为ids4)是基于OIDC的有一种认证框架，在ids4框架下，客户认证流程的示意图如图1所示。

可见，图1所示流程中没有用户的参与，此流程client涉及到对两种重要资源的引用，一个是scope，另一个是secret。其中，scope校验和secret校验依据这个关联关系来进行校验。一个client可以关联任意的scope和secret。目前的协议架构的一个问题是OIDC和OAuth2.0是支持标准的服务发现协议的，如果对于资源不加隔离，服务发现协议会把所有client支持的scope和grant type的并集作为查询结果返回回来，这无疑扩大了接入端设备的对接难度(因为没法区分某个client允许哪些scope和哪些grant type，除了注册者知道)和返回了没必要的数据。如图2所示，服务发现协议所返回的结果中的支持的范围(scopes_supported)描述系统现在支持的所有scope，支持的流程类型(grant_types_supported)描述系统当前支持的所有grant type，但它并不表明某个client支持所有这些scope和grant type，而是所有client支持的scope和grant type的并集。因此服务描述协议返回了模糊不清或者多余的数据的问题，导致对于客户端的资源的认证过程需要在过大的资源范围内进行，造成认证效率降低，这也是标准OIDC和OAuth2.0协议未涉及的议题，需要通过资源隔离予以解决。

此外，在目前的协议架构下，另一个问题是，这些scope一般都是认证授权系统预先定义的，接入端设备没法修改。接入端设备在进行客户端应用注册时，勾选系统预定义的scope作为这个客户端的允许的scope集合，这就导致在一些特殊场景下接入端设备无法自定义scope。因此，grant type和scope是全局暴露和引用的，无法让第三方开发者自主维护scope资源。

为了实现资源隔离以克服上述缺陷，本申请实施例提供一种认证方法。通过引入租户，将client和scope隔离开来，以解决上面遇到的问题。

具体的，针对面向客户(to customer，toC)场景的client，开通一个大租户，由toC场景下的client共享租户的资源。针对资源的增删改查也不对外开放，toC场景下的client仅需要在开发者门户上进行一个客户端的注册即可使用。开发者门户例如微信的公众号登录授权，面向全网用户。

针对面向企业(to business，toB)场景的client，可以在认证授权系统的开发者门户上先开通一个租户，以支持在这个租户内对client关联的资源进行增删改查。其中，ToB场景下租户的资源与toC场景下租户的资源、不同租户之间的资源进行隔离。其中，对于资源的管理权放开给租户管理员设备，租户管理员设备典型的如某个政企系统的访问。可以限定租户管理员设备的用户类型和来源。本申请中，租户管理员设备可以是租户管理员登录的设备。

最终，该系统可支持toC、toB两种应用场景的客户端接入，同时遵循标准的OIDC/OAuth2.0协议。

有了租户的概念，进一步可以引入一个租户管理员的概念，由开发人员在认证授权系统的开发者门户开通企业版本的注册。可选的，系统可自动生成一个租户和一个租户管理员，开发人员可通过租户管理员(账户)登录开发者门户进行资源的管理，以实现开发人员对于scope等资源的方便管理。

可选的，本申请实施例应用的方法可由服务端设备(可称为第一设备)、接入端设备(可称为第二设备)和应用管理员实现。

其中，服务端设备(也可称为认证授权系统或设备)至少可用于实现以下功能：

(1)建立租户模型，包含一个租户标识(ID)。服务端系统可内置一个toC租户。

(2)申请一个系统全局的证书，用来提供所有租户共同签发的标识令牌(id_token)和接入令牌(access_token)。这一步之所以系统所有租户共用，主要是考虑到，客户端库从认证授权系统获取公钥来对id_token和access_token进行校验时，这个请求是不体现租户信息的，为了不破坏标准协议和安全起见，所有租户共用同样的证书。

(3)针对client、scope、user、secret和grant type分别建立模型，每个模型都关联一个租户ID。租户和模型之间的关系可以是一对多。另外，这里可有其他实现，比如一个scope和client可被多个租户共享，这里为简化，就假设他们是一对多的关系。

(4)按OIDC/OAUTH2.0的协议实现各个流程，其中在校验scope,user时限定在所属的租户内进行资源的检验(这里租户可以从请求的client id中定位到client，然后根据client关联的租户ID得到)。

(5)提供一个开发者门户，可让应用管理员申请接入应用。可选普通版(对应于toC场景的客户端)和企业版(对应于toB场景的客户端)两种应用模式。其中，如果选择普通版，应用能够使用关联到toC场景下客户端关联的资源(如scope、user等等)；如果选择企业版，则系统可新开通一个租户，由应用管理员自己维护各种资源，比如，应用管理员可维护针对该租户导入哪些用户，限制这些用户才能登录该应用等等。

(6)提供服务描述文件时，应用管理员可登录开发者门户，根据所属租户类型，返回该租户的服务描述文件。

接入端设备可按照标准的OIDC/OAUTH2.0对接即可。目前市面上有面向多种编程语言的客户端库提供，可进一步降低接入难度。

应用管理员设备可针对toB场景的客户端，登录开发者门户进行scope、secret、client、user或grant type等的管理，以及支持下载服务描述文件等等功能。

下面结合附图，对本申请实施例提供的认证方法进行说明。

如图3所示，以该方法由第一设备和第二设备实施为例，该方法可包括以下步骤：

S101：第二设备向第一设备发送认证请求，认证请求包括待认证的客户端的信息和请求的第一范围。

其中，待认证的客户端的信息例如包括以下中的至少一项：

grant type，例如取值为客户端认证(client_credential)。

client id，例如取值为client。

client secret，例如取值为secret。

scope，例如取值为api1。

相应的，第一设备接收来自于第二设备的认证请求。

S102：第一设备根据客户端的信息获取客户端关联的租户的信息，其中，租户与第三范围相关联，其中，所述客户端与第二范围相关联。

一种可能的实现方式中，应用管理员可给每个client关联一个租户，每个租户可包含多个client，每个client限制只属于一个租户，因此可通过租户实现client的隔离。此外，应用管理员还可给每个scope关联一个租户，每个租户可包含多个scope，因此可通过租户实现scope的隔离。每个scope也可属于多个租户(具体在实现时，可通过选择一个或几个scope进行分享或公开的方式实现)，不同租户间的scope可重名，以实现更为灵活的配置。则在S101和S102中，客户端可关联于租户，该租户关联的scope即第三范围。此外，已有协议架构下客户端所关联的scope为第二范围，且第二设备请求的scope为第一范围。

可选的，第一设备可存储client与租户之间的关联关系。

可选的，如果第一设备无法获得租户的信息，可按照租户是toC用户关联的租户进行处理。

S103：第一设备确定第三范围包括第二范围，且第一范围属于第二范围。

也就是说，如果该租户关联的scope包括客户端所关联的scope，且客户端所关联的scope包括第二设备所请求的scope，则第一设备可确认客户端通过scope认证。

S104：第一设备向第二设备发送认证结果，认证结果指示客户端通过认证。

因此，在满足S103所示条件的情况下，客户端可通过认证。

或者，S104也可替换为，第一设备输出认证结果。例如，第一设备可向第二设备发送认证结果，或者可以通过显示文字或图像，或者通过播放语音等方式输出认证结果。

相应的，第二设备可接收认证结果。

根据以上方法，对第二设备的请求的scope认证过程是根据请求认证的客户端关联的租户的scope的范围进行，而不再是根据所有client可能支持的全部scope的范围进行认证，避免在全部资源范围内确定允许客户端访问的资源，提高认证安全性和认证效率。

并且，以上针对第二设备的请求，协议未作任何更改即可支持scope按隔离后的模型做安全认证。

此外，在获取服务描述文件时可做到默认只返回非企业用户的资源，当使用租户管理员登录开发者门户后，选择一个client来单独获取这个client对应的服务描述文件，返回的grant type和scope也是属于所选的client的，极大的方便开发者的沟通和接入。

示例性的，在通过租户对client和scope进行隔离的情况下，本申请实施例提供的client认证过程可包括如图4所示流程：第二设备通过应用程序(application，APP)向第一设备发送请求token(即认证请求)，其中携带待认证的客户端的信息。第一设备收到请求token后，解析出client和secret。第一设备进一步根据解析的client自查配置，如果确定配置通过检查，则进一步可验证secret，如果确定未通过配置检查，则第一设备可以报错并结束对于请求token的处理。如果第一设备确定secret通过认证，则进一步可验证scope，如果确定secret验证未通过，则第一设备可以报错并结束对于请求token的处理。在scope认证阶段，第一设备可根据client确定其对应的租户，以及从请求token中获得请求的scope(即第一范围)，并获得该租户关联的scope集合A(即第三范围)，以及获得该client关联的scope集合B(即第二范围)，如果确定scope集合A包含scope集合B，且scope集合B包含scope，则第一设备可确认通过scope认证，后续第一设备可向第二设备发送标识通过认证的token，并结束对于请求token的处理；否则，第一设备可确认未通过scope认证，则第一设备可以报错并结束对于请求token的处理。

示例性的，第一设备还可验证客户端的用户凭据(或接入端设备的用户凭据)是否正确，其中，用户凭据可用于验证客户端的身份。如果用户凭据正确，则表示该客户端有相应权限，第一设备可以允许客户端通过认证请求；反之，如果用户凭据不正确，第一设备将不允许客户端通过认证。

在一种可能的实现方式中，除了认证用户凭据是否准确，第一设备还可获取客户端输入的用户凭据，并根据租户的信息获取租户对应的用户凭据，之后确认用户凭据与租户对于的用户凭据是否匹配，如果匹配则确定客户端的用户凭据正确，后续可以进一步进行可获得的认证，如果不匹配，则即便客户端的用户凭据正确，第一设备也不允许客户端通过认证。据此可避免恶意设备冒用租户关联的客户端身份，从而提高接入安全，也可以通过租户限定一部分用户访问相应的资源(例如，通过租户限定某些客户端能够访问租户关联的资源，而其他客户端不被允许访问这些资源)。

客户端或接入端设备的用户凭据可由认证中心(Certificate Authority，CA)颁发。其中，用户凭据例如是密码。又如，用户凭据可以是根据认证私钥生成的签名，第一设备可获得认证公钥，用于验证认证私钥生成的签名。

可选的，可由租户管理员向CA申请租户的用户凭据，租户的用户凭据适用于租户关联的客户端。如果用户凭据是密码，则第二设备发起客户端的认证请求时，可携带客户端关联的租户的密码，第一设备可确定客户端关联的租户的密码是否与认证请求中携带的密码匹配。如果用户凭据是认证证书，认证证书可包括认证公钥和认证私钥，认证证书可对应于租户，也就是说，可针对每个租户申请认证证书，当第二设备发起客户端的认证请求时，认证请求中可携带根据客户端关联的租户的认证私钥生成的签名，第一设备可从CA获得认证公钥，用于解签名，如果解签名成功则说明用户凭据匹配。

在一种可能的实现方式中，本申请可针对用户资源引入租户的概念，每个租户包含多个用户，每个用户可以属于多个租户。认证授权系统可提供一个公众注册的页面，通过这个页面注册的用户属于toC用户。而使用租户管理员登陆后，注册或者添加的用户属于toB用户，也可以导入其他租户的用户。也就是说，toB用是租户管理员授权(即登录状态)下注册的用户，此时可获得toB用户的注册信息，包括登录ID和密码等。例如，第二设备可以在租户管理员登录的状态下注册toB用户。

这样就能将toC、toB不同租户间的用户隔离开，同时toC用户的管理不放开，toB用户由租户管理员自己管理，让不同的企业在一套系统自己管理自己的用户资源。

目前，对于标准的OIDC和OAuth2.0协议，客户端认证过程是没有用户参与的，而code、implict和password这三个流程，还有实践中这几个流程的组合也都是有用户参与的。标准协议流程没对用户能否进行登录进行说明，当然这是实现方要考虑的。如果要满足toB场景下某些用户才能进行这些认证授权流程，从而访问受限的资源，而不是像微信公众号一样面向所有人，那就需要做用户的隔离了。下面从最复杂的code流程来分析这个问题(假定用户需要同意(consent))。

如图5所示，第一设备可以在用户登录(login)阶段，判断用户登录使用的用户凭据是否与该租户的用户凭据匹配，如果匹配，进一步可判断用户凭据是否符合规则，则进入consent流程，如询问用户是否同意。可以看到，如果不对客户端的用户凭据是否属于租户的用户凭据进行判断的话，仅判断客户端的用户凭据正确，就进入consent流程了，这样就没法限定某些用户才能访问这个客户端应用的资源，同时这些用户的注册是通过认证授权系统提供的某种公共注册路径实现的，而用户的统一管理则没法开放出来给用户自己管理。采用这种技术方案后，应用接入端同样透明接入，只是在login环节，判断登录的用户是否属于当前client所属的租户而已。可以看到对标准要求的主流程改动不大，在实现用户的隔离的基础上以提高系统的安全性的前提下，可以较好兼容现有标准。当然这里client也可能不属于任何租户，这种client就是面向toC的client，这意味着它的有效用户范围其实是toC用户。如果一个toB用户需要访问toC client，可加到toC这个大租户内或者通过一定的技巧，比如如果是toC的client，则不考虑这个限制，允许所有用户访问资源，只需要用户凭据正确即可。

可选的，第一设备可针对不同类型的用户将系统资源进行划分，例如，将系统资源划分为包括第一资源和第二资源，其中，第一资源对应于toC场景的用户，第二资源对应于toB场景的用户。第一资源和第二资源可分别包括允许用户访问的client、scope或user等资源，且第一资源和第二资源不同。

例如，toC场景的接入端请求访问scope1资源，则第一设备可确定scope1是否属于第一资源包含的scope的范围，如果是，则允许访问该资源。

下面从引入租户前、租户后，系统资源的组织架构进行举例说明。

引入租户前，接入端允许使用的资源示意如图6所示，可见，对于一个接入端来说，其允许访问的资源是包括在全部资源内的。图7所示为引入租户概念后的允许使用的资源示意图。在引入租户概念后，支持toC、toB两种场景的应用认证授权。针对toB场景的资源完全可以由租户管理员自己管理控制。其中，可针对toB场景的用户允许访问的资源和toC场景的用户允许访问的资源进行隔离，还可对属于不同租户的用户允许访问的资源进行隔离。如图7所示，支持对toB场景的用户和toC场景的用户分别允许使用的资源进行隔离，还可支持对关联到不同租户的用户分别允许使用的资源进行隔离。

基于与上述认证方法的同一构，思本申请实施例还提供一种认证设备，用于实现上述由第一设备和/或第二设备执行的方法。

图8所示为本申请实施例提供的一种认证设备的模块化结构示意图。其中，处理模块801可用于执行S102和S103和本申请描述的第一设备和第二设备的其他处理动作，收发模块802可用于执行S101和S104或实现本申请描述的第一设备和第二设备的其他通信动作。例如，在通过该结构实现以上方法实施例介绍的交换机时，收发模块802可用于执行本申请所示通信动作。具体执行的动作和功能这里不再具体展开，可参照前述方法实施例部分的说明。

图9示出了本申请实施例提供的一种认证设备的结构示意图。

本申请实施例中的电子设备可包括处理器901。处理器901是该认证设备的控制中心，可以利用各种接口和线路连接该认证设备的各个部分，通过运行或执行存储在存储器902内的指令以及调用存储在存储器902内的数据。可选的，处理器901可包括一个或多个处理单元，处理器901可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器901中。在一些实施例中，处理器901和存储器902可以在同一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。

处理器901可以是通用处理器，例如中央处理器(CPU)、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的交换机所执行的步骤可以直接由硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

在本申请实施例中，存储器902存储有可被至少一个处理器901执行的指令，至少一个处理器901通过执行存储器902存储的指令，可以用于执行前述由交换机执行的通信过程。

存储器902作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器902可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(Random AccessMemory，RAM)、静态随机访问存储器(Static Random Access Memory，SRAM)、可编程只读存储器(Programmable Read Only Memory，PROM)、只读存储器(Read Only Memory，ROM)、带电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、磁性存储器、磁盘、光盘等等。存储器902是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器902还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

本申请实施例中，该网络设备还可以包括通信接口903，认证设备可以通过该通信接口903传输数据。例如认证设备为服务器，通信接口903可用于接收认证请求和/或输出认证结果。

可选的，可由图9所示处理器901(或处理器901和存储器902)实现图8所示的处理模块801，和/或，由通信接口903实现图8所示的收发模块802。

基于相同的发明构思，本申请实施例还提供一种计算机可读存储介质，其中可存储有指令，当该指令在计算机上运行时，使得计算机执行上述方法实施例提供的操作步骤。该计算机可读存储介质可以是图9所示的存储器902。

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

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

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

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

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

Claims (10)

1.一种认证方法，其特征在于，所述方法包括：

第一设备接收认证请求，所述认证请求包括待认证的客户端的信息和请求的第一范围，其中，所述客户端与第二范围相关联；

所述第一设备根据所述客户端的信息获取所述客户端关联的租户的信息，所述租户与第三范围相关联；

所述第一设备确定所述第三范围包括所述第二范围，且所述第一范围属于所述第二范围；

所述第一设备输出认证结果，所述认证结果指示所述客户端通过认证。

2.如权利要求1所述的方法，其特征在于，所述方法还包括：

所述第一设备获取所述客户端输入的用户凭据；

所述第一设备根据所述租户的信息获取所述租户对应的用户凭据；

所述第一设备确定所述客户端的用户凭据与所述租户对应的用户凭据匹配。

3.如权利要求1所述的方法，其特征在于，所述客户端为面向客户的客户端，所述租户为面向客户的客户端对应的租户；或者，

所述客户端为面向企业的客户端，所述租户为面向企业的客户端对应的租户。

4.如权利要求1所述的方法，其特征在于，所述客户端为面向客户的客户端，所述客户端允许访问的资源包括第一资源，所述客户端为面向企业的客户端，所述客户端允许访问的资源包括第二资源，所述第一资源与所述第二资源不同；

所述方法还包括：

所述第一设备判断所述客户端允许访问的资源包括所述第一范围。

5.一种认证方法，其特征在于，所述方法包括：

第二设备发送认证请求，所述认证请求包括待认证的客户端的信息和请求的第一范围，其中，所述客户端与第二范围相关联，所述客户端的信息用于获取所述客户关联的租户的信息，所述租户与第三范围相关联，所述第三范围包括所述第二范围，且所述第一范围属于所述第二范围；

所述第二设备接收认证结果，所述认证结果指示所述客户端通过认证。

6.如权利要求5所述的方法，其特征在于，所述客户端为面向企业的客户端，所述方法还包括：

所述第二设备获得所述客户端的注册信息，所述注册信息是所述客户端在租户管理员的授权下获得的。

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

所述第二设备向第一设备发送所述客户端输入的用户凭据，所述客户端的用户凭据与所述租户对应的用户凭据匹配。

8.如权利要求5所述的方法，其特征在于，所述客户端为面向客户的客户端，所述客户端允许访问的资源包括第一资源，所述客户端为面向企业的客户端，所述客户端允许访问的资源包括第二资源，所述第一资源与所述第二资源不同。

9.如权利要求5所述的方法，其特征在于，所述客户端为面向客户的客户端，所述租户为面向客户的客户端对应的租户；或者，

所述客户端为面向企业的客户端，所述租户为面向企业的客户端对应的租户。

10.一种认证装置，其特征在于，包括：

通信接口，用于所述认证装置进行通信；

处理器，用于所述认证装置执行应用程序，实现如权利要求1-4或5-9中任一所述的方法。