一种认证服务器、卡认证系统、免密认证方法和系统与流程

文档序号:26502418发布日期:2021-09-04 03:14阅读:164来源:国知局
一种认证服务器、卡认证系统、免密认证方法和系统与流程

1.本申请涉及身份认证领域,尤其涉及一种认证服务器、卡认证系统、免密认证方法和系统。


背景技术:

2.随着信息技术的发展,基于运营商的免密认证已经应用在互联网产品(抖音、头条等app)中。
3.免密认证原理是:移动终端通过移动流量访问运营商侧的认证服务器,利用认证服务器对用户信息进行认证。上述的免密认证方法虽然可以取得一定的认证效果,但是存在安全隐患,安全性较差。


技术实现要素:

4.本申请提供了一种认证服务器、卡认证系统、免密认证方法和系统,部分解决了现有技术中的免密认证方法安全性较差的技术问题。
5.有鉴于此,本申请第一方面提供了一种免密认证方法,应用于认证服务器,所述方法包括:
6.响应于客户端的预登录请求,获取所述预登录请求对应的用户信息;
7.发送所述用户信息至卡认证系统,使得所述卡认证系统判断所述用户信息是否支持卡认证,得到对应的判断结果;
8.将所述卡认证系统发送的判断结果发送至所述客户端,使得所述客户端根据所述判断结果确定登录请求数据;
9.当判断到所述登录请求数据为所述卡认证系统对应的格式数据时,将所述登录请求数据发送至所述卡认证系统进行免密认证。
10.可选地,所述方法还包括:
11.当判断到所述登录请求数据为所述认证服务器对应的格式数据时,根据所述登录请求数据进行免密认证。
12.可选地,响应于客户端的预登录请求,获取所述预登录请求对应的用户信息,具体包括:
13.响应于客户端的预登录请求,获取所述客户端对应的网关发送的预认证数据;
14.从所述预认证数据中获取所述预登录请求对应的用户信息。
15.本申请第二方面提供了一种免密认证方法,应用于卡认证系统,所述方法包括:
16.获取认证服务器发送的用户信息,其中,所述用户信息与客户端的预登录请求对应;
17.判断所述用户信息是否支持卡认证,得到对应的判断结果;
18.将所述判断结果通过所述认证服务器发送至所述客户端,使得所述客户端根据所述判断结果确定登录请求数据;
19.当所述认证服务器判断到所述登录请求数据为所述卡认证系统对应的格式数据时,接收所述认证服务器发送的所述登录请求数据,并进行免密认证。
20.可选地,当所述判断结果为支持认证时,接收所述认证服务器发送的所述登录请求数据,并进行免密认证,之前还包括:
21.发送卡认证请求至所述客户端对应的手机卡,使得所述手机卡输出弹窗信息以供用户进行卡认证的确认,得到卡认证结果;
22.接收所述手机卡发送的所述卡认证结果,并保存所述卡认证结果。
23.可选地,接收所述认证服务器发送的所述登录请求数据,并进行免密认证,具体包括:
24.根据所述登录请求数据和所述卡认证结果,对所述登录请求数据进行免密认证。
25.本申请第三方面提供了一种认证服务器,包括:
26.获取单元,用于响应于客户端的预登录请求,获取所述预登录请求对应的用户信息;
27.第一发送单元,用于发送所述用户信息至卡认证系统,使得所述卡认证系统判断所述用户信息是否支持卡认证,得到对应的判断结果;
28.第二发送单元,用于将所述卡认证系统发送的判断结果发送至所述客户端,使得所述客户端根据所述判断结果确定登录请求数据;
29.第三发送单元,用于当判断到所述登录请求数据为所述卡认证系统对应的格式数据时,将所述登录请求数据发送至所述卡认证系统进行免密认证。
30.本申请第四方面提供了一种卡认证系统,包括:
31.获取单元,用于获取认证服务器发送的用户信息,其中,所述用户信息与客户端的预登录请求对应;
32.判断单元,用于判断所述用户信息是否支持卡认证,得到对应的判断结果;
33.发送单元,用于将所述判断结果通过所述认证服务器发送至所述客户端,使得所述客户端根据所述判断结果确定登录请求数据;
34.接收单元,用于当所述认证服务器判断到所述登录请求数据为所述卡认证系统对应的格式数据时,接收所述认证服务器发送的所述登录请求数据,并进行免密认证。
35.本申请第五方面提供了一种免密认证系统,包括:如第三方面所述的认证服务器和如第四方面所述的卡认证系统;
36.所述认证服务器,用于响应于客户端的预登录请求,获取所述预登录请求对应的用户信息,还用于发送所述用户信息至卡认证系统;
37.所述卡认证系统,用于判断所述用户信息是否支持卡认证,得到对应的判断结果,还用于将所述判断结果通过所述认证服务器发送至所述客户端,使得所述客户端根据所述判断结果确定登录请求数据;
38.所述认证服务器,还用于当判断到所述登录请求数据为所述卡认证系统对应的格式数据时,将所述登录请求数据发送至所述卡认证系统进行免密认证。
39.可选地,所述认证服务器,还用于当判断到所述登录请求数据为所述认证服务器对应的格式数据时,根据所述登录请求数据进行免密认证。
40.从以上技术方法可以看出,本申请具有以下优点:
41.现有技术中的免密认证方法,用户信息的传输是通过移动终端的流量接入网关后,发送至认证服务器的。此时如果待免密认证的第一终端连接第二终端的流量热点,当第一终端访问认证服务器时,因为第一终端使用的是第二终端的流量,那么认证服务器会将第一终端认证为第二终端,在实际应用中会造成接入终端识别错误,且存在无需用户授权,可通过无感知调用免密认证能力而获取用户信息的情况(即静默取号)。
42.基于此,本申请中在得到客户端的预登录请求后,获取预登录请求对应的用户信息,接着将用户信息发送至卡认证系统,卡认证系统判断用户信息是否支持卡认证,得到对应的判断结果;接着将卡认证系统发送的判断结果发送至客户端,使得客户端根据判断结果确定登录请求数据;当判断到登录请求数据为卡认证系统对应的格式数据时,将登录请求数据发送至卡认证系统进行免密认证。卡认证是运营商向用户提供卡(手机卡)硬件的安全认证服务,通过卡认证的特殊认证方式,避免了免密认证时的终端识别错误和静默取号,从而部分解决了现有技术中的免密认证方法安全性较差的技术问题。
附图说明
43.为了更清楚地说明本申请实施例中的技术方法,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其它的附图。
44.图1为本申请实施例中一种免密认证方法的实施例一的流程示意图;
45.图2为本申请实施例中卡认证时的认证示意图;
46.图3为本申请实施例中一种免密认证方法的实施例二的流程示意图;
47.图4为本申请实施例中卡认证时的弹窗界面;
48.图5为本申请实施例中一种认证服务器的实施例的结构示意图;
49.图6为本申请实施例中一种卡认证系统的实施例的结构示意图;
50.图7为本申请实施例中一种免密认证系统的实施例的结构示意图;
51.图8为本申请实施例中的免密认证系统在免密认证过程中的信息传输过程示意图。
具体实施方式
52.本申请实施例提供了一种认证服务器、卡认证系统、免密认证方法和系统,部分解决了现有技术中的免密认证方法安全性较差的技术问题。
53.为了使本技术领域的人员更好地理解本申请方法,下面将结合本申请实施例中的附图,对本申请实施例中的技术方法进行清楚、完整地描述,显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
54.以便于理解,请参阅图1,图1为本申请实施例中一种免密认证方法的实施例一的流程示意图。
55.本实施例中的一种免密认证方法,应用于认证服务器,包括:
56.步骤101、响应于客户端的预登录请求,获取预登录请求对应的用户信息。
57.客户端是指与服务器相对应,为用户提供本地服务的程序,例如,抖音、微博、微信等。
58.可以理解的是,响应于客户端的预登录请求,获取预登录请求对应的用户信息,具体包括:
59.响应于客户端的预登录请求,获取客户端对应的网关发送的预认证数据;
60.从预认证数据中获取预登录请求对应的用户信息。
61.免密认证中的预登录请求一般指客户端的加载请求,当用户点击客户端后,客户端进行加载,此时客户端会向网关发送加载请求,网关获取到加载请求后,在加载请求中添加用户信息得到预认证数据,认证服务器对预认证数据进行解析,便可获取该预登录请求对应的用户信息。可以理解的是,上述的用户信息可以是手机号码。
62.步骤102、发送用户信息至卡认证系统,使得卡认证系统判断用户信息是否支持卡认证,得到对应的判断结果。
63.认证服务器得到用户信息后,将用户信息发送至卡认证系统,由卡认证系统判断用户信息是否支持卡认证,得到对应的判断结果。
64.步骤103、将卡认证系统发送的判断结果发送至客户端,使得客户端根据判断结果确定登录请求数据。
65.卡认证系统得到用户信息是否支持卡认证的判断结果后,将判断结果发送至认证服务器,认证服务器发送判断结果至客户端,使得客户端根据判断结果确定登录时的登录请求数据。
66.可以理解的是,在一种实施方式中,客户端确定登录请求数据的方式可以为:认证服务器具体的判断结果和该判断结果具体对应的登录请求数据至客户端,客户端直接从获取到的数据里面获取登录请求数据即可。在另一种实施方式中,客户端中预先设置有判断结果和登录请求数据的对应关系,当认证服务器发送具体的判断结果后,客户端基于该判断结果和上述的对应关系具体确定该判断结果对应的登录请求数据。
67.可以理解的是,当判断结果为支持认证时,对应的登录请求数据为认证请求数据唯一序列号标识(即seqid),当判断结果为不支持认证时,对应的登录请求数据为认证授权码(accesscode)。
68.步骤104、当判断到登录请求数据为卡认证系统对应的格式数据时,将登录请求数据发送至卡认证系统进行免密认证。
69.如图2所示,卡认证为:用户在终端上使用快捷认证应用进行身份认证时,用户先在界面中输入手机号(如已知号码则无需输入),点击登录或支付确认按钮,终端上将收到弹窗,用户点击确认,终端即完成登录或支付。如该快捷认证应用需要密码,则需要用户先输入密码,验证通过后,再确认登录或支付。也就是说,卡认证需要进行基于手机卡和用户的交互,通过交互避免静默取号和终端识别错误。
70.步骤105、当判断到登录请求数据为认证服务器对应的格式数据时,根据登录请求数据进行免密认证。
71.本实施例中在得到客户端的预登录请求后,获取预登录请求对应的用户信息,接着将用户信息发送至卡认证系统,卡认证系统判断用户信息是否支持卡认证,得到对应的判断结果;接着将卡认证系统发送的判断结果发送至客户端,使得客户端根据判断结果确
定登录请求数据;当判断到登录请求数据为卡认证系统对应的格式数据时,将登录请求数据发送至卡认证系统进行免密认证。卡认证是运营商向用户提供卡(手机卡)硬件的安全认证服务,通过卡认证的特殊认证方式,避免了免密认证时的终端识别错误和静默取号,从而部分解决了现有技术中的免密认证方法安全性较差的技术问题。
72.以上为本申请实施例提供的一种免密认证方法的实施例一,以下为本申请实施例提供的一种免密认证方法的实施例二。
73.请参阅图3,图3为本申请实施例中一种免密认证方法的实施例二的流程示意图。
74.本实施例中的一种免密认证方法,应用于卡认证系统,包括:
75.步骤301、获取认证服务器发送的用户信息,其中,用户信息与客户端的预登录请求对应。
76.需要说明的是,步骤301与实施例一中步骤101的描述相似,具体可以参见上述步骤101的描述,在此不再赘述。
77.步骤302、判断用户信息是否支持卡认证,得到对应的判断结果。
78.需要说明的是,步骤302与实施例一中步骤102的描述相似,具体可以参见上述步骤102的描述,在此不再赘述。
79.步骤303、将判断结果通过认证服务器发送至客户端,使得客户端根据判断结果确定登录请求数据。
80.需要说明的是,步骤303的描述和第一实施例中步骤103的描述相同,具体可以参见上述步骤103的描述,在此不再详述。
81.步骤304、发送卡认证请求至客户端对应的手机卡,使得手机卡输出弹窗信息以供用户进行卡认证的确认,得到卡认证结果。
82.可以理解的是,卡认证系统在进行免密认证时的卡认证弹窗界面具体可以如图4所示。
83.步骤305、接收手机卡发送的卡认证结果,并保存卡认证结果。
84.步骤306、当认证服务器判断到登录请求数据为卡认证系统对应的格式数据时,根据登录请求数据和卡认证结果,对登录请求数据进行免密认证。
85.本实施例中在得到客户端的预登录请求后,获取预登录请求对应的用户信息,接着将用户信息发送至卡认证系统,卡认证系统判断用户信息是否支持卡认证,得到对应的判断结果;接着将卡认证系统发送的判断结果发送至客户端,使得客户端根据判断结果确定登录请求数据;当判断到登录请求数据为卡认证系统对应的格式数据时,将登录请求数据发送至卡认证系统进行免密认证。卡认证是运营商向用户提供卡(手机卡)硬件的安全认证服务,通过卡认证的特殊认证方式,避免了免密认证时的终端识别错误和静默取号,从而部分解决了现有技术中的免密认证方法安全性较差的技术问题。
86.以上为本申请实施例提供的一种免密认证方法的实施例二,以下为本申请实施例提供的一种认证服务器的实施例。
87.请参阅图5,图5为本申请实施例中一种认证服务器的实施例的结构示意图。
88.本实施例中的认证服务器,包括:
89.获取单元501,用于响应于客户端的预登录请求,获取预登录请求对应的用户信息;
90.第一发送单元502,用于发送用户信息至卡认证系统,使得卡认证系统判断用户信息是否支持卡认证,得到对应的判断结果;
91.第二发送单元503,用于将卡认证系统发送的判断结果发送至客户端,使得客户端根据判断结果确定登录请求数据;
92.第三发送单元504,用于当判断到登录请求数据为卡认证系统对应的格式数据时,将登录请求数据发送至卡认证系统进行免密认证。
93.进一步地,本实施例中的认证服务器还包括认证单元,该认证单元用于当判断到登录请求数据为认证服务器对应的格式数据时,根据登录请求数据进行免密认证。
94.获取单元501具体包括:
95.第一获取子单元,用于响应于客户端的预登录请求,获取客户端对应的网关发送的预认证数据;
96.第二获取子单元,用于从预认证数据中获取预登录请求对应的用户信息。
97.本实施例中在得到客户端的预登录请求后,获取预登录请求对应的用户信息,接着将用户信息发送至卡认证系统,卡认证系统判断用户信息是否支持卡认证,得到对应的判断结果;接着将卡认证系统发送的判断结果发送至客户端,使得客户端根据判断结果确定登录请求数据;当判断到登录请求数据为卡认证系统对应的格式数据时,将登录请求数据发送至卡认证系统进行免密认证。卡认证是运营商向用户提供卡(手机卡)硬件的安全认证服务,通过卡认证的特殊认证方式,避免了免密认证时的终端识别错误和静默取号,从而部分解决了现有技术中的免密认证方法安全性较差的技术问题。
98.以上为本申请实施例提供的一种认证服务器的实施例,以下为本申请实施例提供的一种卡认证系统的实施例。
99.请参阅图6,图6为本申请实施例中一种卡认证系统的实施例的结构示意图。
100.本实施例中的卡认证系统,包括:
101.获取单元601,用于获取认证服务器发送的用户信息,其中,用户信息与客户端的预登录请求对应;
102.判断单元602,用于判断用户信息是否支持卡认证,得到对应的判断结果;
103.发送单元603,用于将判断结果通过认证服务器发送至客户端,使得客户端根据判断结果确定登录请求数据;
104.接收单元604,用于当认证服务器判断到登录请求数据为卡认证系统对应的格式数据时,接收认证服务器发送的登录请求数据,并进行免密认证。
105.进一步地,本实施例中的卡认证系统还包括:
106.传输单元,用于发送卡认证请求至客户端对应的手机卡,使得手机卡输出弹窗信息以供用户进行卡认证的确认,得到卡认证结果;
107.接收单元,用于接收手机卡发送的卡认证结果,并保存卡认证结果。
108.接收认证服务器发送的登录请求数据,并进行免密认证,具体包括:
109.根据登录请求数据和卡认证结果,对登录请求数据进行免密认证。
110.本实施例中在得到客户端的预登录请求后,获取预登录请求对应的用户信息,接着将用户信息发送至卡认证系统,卡认证系统判断用户信息是否支持卡认证,得到对应的判断结果;接着将卡认证系统发送的判断结果发送至客户端,使得客户端根据判断结果确
定登录请求数据;当判断到登录请求数据为卡认证系统对应的格式数据时,将登录请求数据发送至卡认证系统进行免密认证。卡认证是运营商向用户提供卡(手机卡)硬件的安全认证服务,通过卡认证的特殊认证方式,避免了免密认证时的终端识别错误和静默取号,从而部分解决了现有技术中的免密认证方法安全性较差的技术问题。
111.以上为本申请实施例提供的一种卡认证系统的实施例,以下为本申请实施例提供的一种免密认证系统的实施例。
112.请参阅图7,图7为本申请实施例中一种免密认证系统的实施例的结构示意图。
113.本实施例中的免密认证系统,包括:上述实施例中的认证服务器701和卡认证系统702;
114.认证服务器701,用于响应于客户端的预登录请求,获取预登录请求对应的用户信息,还用于发送用户信息至卡认证系统702;
115.卡认证系统702,用于判断用户信息是否支持卡认证,得到对应的判断结果,还用于将判断结果通过认证服务器701发送至客户端,使得客户端根据判断结果确定登录请求数据;
116.认证服务器701,还用于当判断到登录请求数据为卡认证系统702对应的格式数据时,将登录请求数据发送至卡认证系统702进行免密认证。
117.进一步地,认证服务器701,还用于当判断到登录请求数据为认证服务器701对应的格式数据时,根据登录请求数据进行免密认证。
118.可以理解的是,以电信运营商为例,说明本实施例中的免密认证系统在免密认证过程中的信息传输,具体如图8所示:
119.1.客户端(如抖音)加载预认证逻辑,发送预登录请求到电信认证服务器认证。
120.2.预登录请求经过运营商侧的网关,网关在预登录请求中添加用户手机号码,得到预认证数据。
121.3.电信认证服务器解析预认证数据获取用户手机号码。
122.4.电信认证服务器发送用户手机号码至认证卡系统,请求卡认证系统查询用户手机号码是否支持卡认证。
123.5.卡认证系统判断用户手机号码是否支持卡认证,并得到对应的判断结果,且将判断结果发送至认证服务器,支持时发送的判断结果为10001,不支持时发送的判断结果为10000。
124.5a.用户手机号码支持卡认证,卡认证系统给手机卡发送卡认证消息,手机卡收到消息后弹窗让用户确认。
125.5b.用户确认后手机卡返回卡认证结果至卡认证系统,卡认证系统保存卡认证结果。
126.6.电信认证服务器根据判断结果执行认证逻辑,如果用户手机号码支持卡认证,则返回10001和seqid至客户端,如果用户手机号码不支持卡认证则返回10000和accesscode至客户端。
127.7.客户端收到认证码为10001,则通过seqid进行7a流程的免密认证;客户端收到认证码为10000,则通过accesscode进行7b流程的免密认证。
128.可以理解的是,上述用于发送的判断结果的具体数据形式和登录请求数据的数据
形式仅仅是一种示意性的举例说明,本领域技术人员可以参照此描述进行其他的设置,在此不再一一赘述和限定。
129.所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
130.本申请的说明书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
131.应当理解,在本申请中,“至少一个(项)”是指一个或者多个,“多个”是指两个或两个以上。“和/或”,用于描述关联对象的关联关系,表示可以存在三种关系,例如,“a和/或b”可以表示:只存在a,只存在b以及同时存在a和b三种情况,其中a,b可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达,是指这些项中的任意组合,包括单项(个)或复数项(个)的任意组合。例如,a,b或c中的至少一项(个),可以表示:a,b,c,“a和b”,“a和c”,“b和c”,或“a和b和c”,其中a,b,c可以是单个,也可以是多个。
132.在本申请所提供的几个实施例中,应该理解到,所揭露的系统,商品加载服务器和方法,可以通过其它的方式实现。例如,以上所描述的商品加载服务器实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,商品加载服务器或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
133.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
134.另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
135.所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:u盘、移动硬盘、只读存储器(英文全称:read

only memory,英文缩写:rom)、随机存取存储器(英文全称:random access memory,英文缩写:ram)、磁碟或者光盘等各种可以存储程序代码的介质。
136.以上所述,以上实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1