一种用户认证方法、装置及设备与流程

1.本申请涉及计算机技术领域，尤其涉及一种用户认证方法、装置及设备。


背景技术：

2.spring security是为基于spring的企业应用系统提供声明式安全访问控制解决方案的安全框架。它提供了完整的安全性解决方案，可以在web请求级别和方法调用级别处理用户认证和用户授权，且支持自定义，提升了框架的灵活性。在用户认证方面，spring security框架支持主流的认证方式，包括http基本认证、http表单认证、http摘要认证、openid和ldap等。oauth 2.0(open authorization)协议为用户资源提供了一个安全的、开放而又简易的标准。在第三方应用未获取到用户敏感信息(如：用户名密码等)的情况下，申请获得该用户资源的授权。oauth 2.0在“客户端”与“服务提供商”之间，设置了一个授权层。“客户端”不能直接登录“服务提供商”，只能登录授权层，以此将用户与客户端区分开来。“客户端”登录授权层所用的令牌(access token)与用户的密码不同，用户可以在登录的时候指定授权层的令牌的权限范围和有限期。“客户端”登录授权层以后，“服务提供商”根据令牌的权限范围和有限期，向“客户端”开放用户存储的资料。
3.当前spring security提供了对oauth 2.0的完整支持，使得开发人员只需较少代码和配置即可为应用提供基础安全能力，具体的，spring security通过过滤器链实现对web安全的支持，过滤器链包含多个过滤器，不同过滤器有不同的功能，例如用户名密码认证过滤器，就会从请求中提取用户名和密码，封装为令牌，然后进行认证。此过滤器即为用户名密码认证的核心逻辑载体。但这种认证方式为密码认证，oauth 2.0授权过程中，如用户未登录服务方，进行身份认证时只能通过输入账户密码的方式进行认证，认证方式较为单一在认证过程中安全性和可靠性不能保障，具有信息泄露风险。


技术实现要素：

4.本申请实施例的主要目的在于提供一种用户认证方法、装置及设备，能够提高用户认证过程的安全性和可靠性，避免信息泄露风险。
5.第一方面，本申请实施例提供了一种用户认证方法，包括：
6.获取用户认证请求，并从所述认证请求中获取所述用户的待认证信息；
7.根据所述待认证信息生成自定义令牌，并将所述自定义令牌发送至认证管理器，以便所述认证管理器根据所述自定义令牌，调用n种不同类型的认证器对应为n种不同类型的所述待认证信息进行认证，得到n种认证结果并返回；所述n为大于1的正整数；
8.接收所述n种认证结果，并根据所述n种认证结果，确定最终的用户认证结果。
9.可选的，所述待认证信息包括所述用户的用户名、手机号、证件号、密码、短信、指纹和人脸信息。
10.可选的，所述方法还包括：
11.根据oauth 2.0授权码模式，拦截预先指定的url。
12.可选的，所述n种不同类型的认证器是根据用户详情载体对应为n种不同类型的所述待认证信息进行认证的；所述用户详情载体是根据所述用户的n种不同类型的标准认证信息组装得到的；所述n种不同类型的标准认证信息与所述n种不同类型的所述待认证信息包含的类型是一致的。
13.第二方面，本申请实施例还提供了一种用户认证装置，包括：
14.获取单元，用于获取用户认证请求，并从所述认证请求中获取所述用户的待认证信息；
15.发送单元，用于根据所述待认证信息生成自定义令牌，并将所述自定义令牌发送至认证管理器，以便所述认证管理器根据所述自定义令牌，调用n种不同类型的认证器对应为n种不同类型的所述待认证信息进行认证，得到n种认证结果并返回；所述n为大于1的正整数；
16.确定单元，用于接收所述n种认证结果，并根据所述n种认证结果，确定最终的用户认证结果。
17.可选的，所述待认证信息包括所述用户的用户名、手机号、证件号、密码、短信、指纹和人脸信息。
18.可选的，所述装置还包括：
19.拦截单元，用于根据oauth 2.0授权码模式，拦截预先指定的url。
20.可选的，所述n种不同类型的认证器是根据用户详情载体对应为n种不同类型的所述待认证信息进行认证的；所述用户详情载体是根据所述用户的n种不同类型的标准认证信息组装得到的；所述n种不同类型的标准认证信息与所述n种不同类型的所述待认证信息包含的类型是一致的。
21.本申请实施例还提供了一种用户认证设备，包括：处理器、存储器、系统总线；
22.所述处理器以及所述存储器通过所述系统总线相连；
23.所述存储器用于存储一个或多个程序，所述一个或多个程序包括指令，所述指令当被所述处理器执行时使所述处理器执行上述用户认证方法中的任意一种实现方式。
24.本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令在终端设备上运行时，使得所述终端设备执行上述用户认证方法中的任意一种实现方式。
25.本申请实施例提供的一种用户认证方法、装置及设备，首先获取用户认证请求，并从该认证请求中获取用户的待认证信息，然后，根据待认证信息生成自定义令牌，并将该自定义令牌发送至认证管理器，以便认证管理器根据该自定义令牌，调用n种不同类型的认证器对应为n种不同类型的待认证信息进行认证，得到n种认证结果并返回；其中，n为大于1的正整数，接着，在接收到n种认证结果后，可以根据这n种认证结果，确定最终的用户认证结果。从而能够提高用户认证过程的安全性和可靠性，避免信息泄露风险。
附图说明
26.为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据
这些附图获得其他的附图。
27.图1为本申请实施例提供的一种用户认证方法的流程示意图；
28.图2为本申请实施例提供的用户认证的交互图；
29.图3为本申请实施例提供的一种用户认证装置的组成示意图。
具体实施方式
30.当前客户端要求用户授权时，对于未登录的用户，需先进行用户身份认证，而在oauth 2.0授权过程中，基于spring security进行用户身份认证时，框架只能提供单一的密码认证方式，安全性和可靠性有待提高。
31.为解决上述缺陷，本申请实施例提供了一种用户认证方法，首先获取用户认证请求，并从该认证请求中获取用户的待认证信息，然后，根据待认证信息生成自定义令牌，并将该自定义令牌发送至认证管理器，以便认证管理器根据该自定义令牌，调用n种不同类型的认证器对应为n种不同类型的待认证信息进行认证，得到n种认证结果并返回；其中，n为大于1的正整数，接着，在接收到n种认证结果后，可以根据这n种认证结果，确定最终的用户认证结果。从而能够提高用户认证过程的安全性和可靠性，避免信息泄露风险。
32.为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
33.第一实施例
34.参见图1，为本实施例提供的一种用户认证方法的流程示意图，该方法包括以下步骤：
35.s101：获取用户认证请求，并从该认证请求中获取用户的待认证信息。
36.需要说明的是，由于spring security在认证环节默认只支持密码方式，因此，为了提高用户认证过程的安全性和可靠性，避免信息泄露风险，需要扩展spring security设计架构，自定义认证方式组合与设计(如将密码和短信认证相结合)，完成spring security安全框架下基于oauth 2.0协议的自定义认证方式组合与设计，进一步提高户认证过程的安全性和可靠性。
37.在本实施例中，构建了实现自定义组合认证的完整流程链，如图2所示，其中，包括自定义过滤器、自定义令牌、认证管理器、n种认证器、自定义用户加载服务等模块，组成了完整的用户认证流程链。
38.具体来讲，首先，需要通过自定义过滤器获取用户认证请求，并从该认证请求中获取用户的待认证信息，用以执行后续步骤s102。其中，待认证信息可以包括用户的用户名、手机号、证件号、密码、短信、指纹和人脸信息等。
39.此外，一种可选的实现方式是，自定义过滤器还需要根据oauth 2.0授权码模式，拦截预先指定的url，例如对于oauth 2.0授权码模式，所拦截url为“/oauth/authorize”，对于oauth 2.0密码模式，所拦截url为“/oauth/token”。
40.s102：根据待认证信息生成自定义令牌，并将自定义令牌发送至认证管理器，以便认证管理器根据自定义令牌，调用n种不同类型的认证器对应为n种不同类型的待认证信息
进行认证，得到n种认证结果并返回；其中，n为大于1的正整数。
41.在本实施例中，自定义过滤器通过步骤s101获取到用户的待认证信息后，进一步可以根据待认证信息生成自定义令牌，如将多种用户的密码和短信等待认证信息进行组合生成待认证的自定义令牌，并利用预先生成的对称密钥，对待传输数据进行加密，生成密文数据；并利用获取到并将自定义令牌发送至认证管理器，这样，认证器管理器可以先从自定义令牌中提取其包含的所有n种待认证信息，然后调用n种不同类型的认证器对应为n种不同类型的待认证信息进行认证，得到n种认证结果并返回给自定义过滤器，用以执行后续步骤s102，其中，n为大于1的正整数。而自定义令牌还可以说明当前所使用的认证方式，如是哪n种待认证信息的组合认证，可使用标识符或者bit模板等能标志出当前所使用的认证方式的标识即可，具体形式本申请不进行限制。
42.其中，一种可选的实现方式是，n种不同类型的认证器可以包括密码认证器、短信认证器、指纹认证器、人脸认证器、证书认证器等。各认证类型的认证器由开发人员根据需要具体实现。对于密码类型，通常做法为加盐哈希后对比；指纹类型通常依赖于不同的厂商，由厂商提供指纹模板与指纹特征的比对接口；短信类型通常为比对验证码是否一致，也可根据需要校验手机号归属等问题。可对每种认证类型的认证器进行组合认证后，再执行后续步骤s103。
43.此外，另一种可选的实现方式是，n种不同类型的认证器是根据用户详情载体对应为n种不同类型的待认证信息进行认证的。其中，用户详情载体是根据用户的n种不同类型的标准认证信息组装得到的；而n种不同类型的标准认证信息是与之前获取到的n种不同类型的待认证信息包含的类型是一致的。例如，如图2所示，首先可以通过自定义用户加载服务模块负责检索用户并将用户的正确认证信息(密码、指纹、短信等)组装为用户详情载体。并且其包含的认证信息类型与自定义令牌包含的待认证信息的类型是相对应的，通常情况下，表征用户的正确认证信息的数据来源为数据库或缓存。这样，n中不同类型的认证器可以与用户详情载体中的相应标准认证信息(即用户的正确)作比对，完成具体的认证操作，得到各自对应的共n种认证结果。并将这n种认证结果返回至认证管理器，再由认证管理器返回至自定义过滤器。
44.s103：接收n种认证结果，并根据n种认证结果，确定最终的用户认证结果。
45.在本实施例中，自定义过滤器在接收到n中认证结果后，可以根据预先设定的判断规则(如少数服从多数的规则)，对这n中认证结果的统一调度处理，确定出最终的用户认证结果。
46.这样，通过上述基于spring security框架的oauth 2.0自定义的身份组合认证方法，扩展了oauth 2.0授权的认证类型，认证类型可自定义，为密码、指纹、短信、证书、人脸、电子令牌多因素组合，如密码指纹、密码短信、密码人脸或三因素组合等多种类型身份认证，提升；俄第三方授权服务的安全性及可靠性。
47.为便于理解上述用户认证方法，本申请还提供了如图2所述的用户认证的交互图，如图2所示，本申请中用户认证的具体实现过程为：自定义过滤器首先获取用户认证请求，并从该认证请求中获取用户的待认证信息，以及根据该待认证信息生成自定义令牌，并将自定义令牌发送至认证管理器。然后，认证管理器根据自定义令牌，调用n种不同类型的认证器，根据自定义用户加载服务组装的用户详情载体中包含的用户的正确认证信息(密码、
指纹、短信等)，对应为n种不同类型的待认证信息进行认证，得到n种认证结果并返回自定义过滤器，进一步的，自定义过滤器可以根据n种认证结果，确定最终的用户认证结果。从而增加了未登录服务方的用户在oauth 2.0授权中身份认证的认证方式，提升开放授权的安全性。
48.综上，本实施例提供的一种用户认证方法，首先获取用户认证请求，并从该认证请求中获取用户的待认证信息，然后，根据待认证信息生成自定义令牌，并将该自定义令牌发送至认证管理器，以便认证管理器根据该自定义令牌，调用n种不同类型的认证器对应为n种不同类型的待认证信息进行认证，得到n种认证结果并返回；其中，n为大于1的正整数，接着，在接收到n种认证结果后，可以根据这n种认证结果，确定最终的用户认证结果。从而能够提高用户认证过程的安全性和可靠性，避免信息泄露风险。
49.第二实施例
50.本实施例将对一种用户认证装置进行介绍，相关内容请参见上述方法实施例。
51.参见图3，为本实施例提供的一种用户认证装置的组成示意图，该装置包括：
52.获取单元301，用于获取用户认证请求，并从所述认证请求中获取所述用户的待认证信息；
53.发送单元302，用于根据所述待认证信息生成自定义令牌，并将所述自定义令牌发送至认证管理器，以便所述认证管理器根据所述自定义令牌，调用n种不同类型的认证器对应为n种不同类型的所述待认证信息进行认证，得到n种认证结果并返回；所述n为大于1的正整数；
54.确定单元303，用于接收所述n种认证结果，并根据所述n种认证结果，确定最终的用户认证结果。
55.在本实施例的一种实现方式中，所述待认证信息包括所述用户的用户名、手机号、证件号、密码、短信、指纹和人脸信息。
56.在本实施例的一种实现方式中，所述装置还包括：
57.拦截单元，用于根据oauth 2.0授权码模式，拦截预先指定的url。
58.在本实施例的一种实现方式中，所述n种不同类型的认证器是根据用户详情载体对应为n种不同类型的所述待认证信息进行认证的；所述用户详情载体是根据所述用户的n种不同类型的标准认证信息组装得到的；所述n种不同类型的标准认证信息与所述n种不同类型的所述待认证信息包含的类型是一致的。
59.综上，本实施例提供的一种用户认证装置，首先获取用户认证请求，并从该认证请求中获取用户的待认证信息，然后，根据待认证信息生成自定义令牌，并将该自定义令牌发送至认证管理器，以便认证管理器根据该自定义令牌，调用n种不同类型的认证器对应为n种不同类型的待认证信息进行认证，得到n种认证结果并返回；其中，n为大于1的正整数，接着，在接收到n种认证结果后，可以根据这n种认证结果，确定最终的用户认证结果。从而能够提高用户认证过程的安全性和可靠性，避免信息泄露风险。
60.进一步地，本申请实施例还提供了一种用户认证设备，包括：处理器、存储器、系统总线；
61.所述处理器以及所述存储器通过所述系统总线相连；
62.所述存储器用于存储一个或多个程序，所述一个或多个程序包括指令，所述指令
当被所述处理器执行时使所述处理器执行上述用户认证方法的任一种实现方法。
63.进一步地，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令在终端设备上运行时，使得所述终端设备执行上述用户认证方法的任一种实现方法。
64.通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到上述实施例方法中的全部或部分步骤可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者诸如媒体网关等网络通信设备，等等)执行本申请各个实施例或者实施例的某些部分所述的方法。
65.需要说明的是，本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
66.还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
67.对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。