一种无服务端的授权方法、装置及电子设备与流程

文档序号:31607613发布日期:2022-09-21 11:27阅读:86来源:国知局
一种无服务端的授权方法、装置及电子设备与流程

1.本发明涉及网络安全技术领域,更具体的说,是涉及一种无服务端的授权方法、装置及电子设备。


背景技术:

2.在oauth 2.0方案中,会为每个第三方应用分配一个客户端标识号与客户端密钥作为认证依据,为了安全考虑,客户端密钥是必须要存放在服务端的。
3.而当前,一些小的前端项目,比如一款原生的小游戏app,其所有的代码都在用户的本地设备上运行,这些前端项目可以称为无服务端或原生客户端。按照一般的oauth 2.0方案,让前端存储客户端密钥是不现实的,很容易被破解,从而使得无服务端的客户端无法安全的使用授权功能。


技术实现要素:

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.图1为本发明实施例公开的一种无服务端的授权方法流程图;
38.图2为本发明实施例公开的刷新访问令牌的流程图;
39.图3为本发明实施例公开的无服务端的授权方法的交互时序示意图;
40.图4为本发明实施例公开的一种无服务端的授权装置的结构示意图;
41.图5为本技术实施例公开的一种电子设备的结构示意图。
具体实施方式
42.为了引用和清楚起见,下文中使用的技术名词的说明、简写或缩写总结如下:
43.oauth 2.0:oauth(open authorization)是一个关于授权(authorization)的开放网络标准,允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息,而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容。oauth在全世界得到广泛应用,目前的版本是2.0版。
44.授权码模式:指的是第三方应用先申请一个授权码,然后再用该码获取令牌,授权码通过前端传送,令牌则是储存在后端,而且所有与资源服务器的通信都在后端完成。这样的前后端分离,可以避免令牌泄漏。
45.csrf:cross-site request forgery,跨站请求伪造。
46.下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
47.本技术实施例可以应用于电子设备,本技术对该电子设备的产品形式不做限定,可以包括但并不局限于智能手机、平板电脑、可穿戴设备、个人计算机(personal computer,pc)、上网本等,可以依据应用需求选择。
48.图1为本发明实施例公开的一种无服务端的授权方法流程图。参见图1所示,无服务端的授权方法可以包括:
49.步骤101:无服务端第三方应用向授权服务请求授权码,授权码请求参数中包括加密串和加密算法,所述加密串由随机字符串基于所述加密算法计算得到。
50.本文中所述的无服务端客户端并不是不需要服务器,而是指代没有服务端的客户端,也可以是原生客户端。因此,上述无服务端第三方应用可以是不需要访问服务器的应
用。
51.请求授权码的请求中包括授权码请求参数,授权码请求参数中包括常规的一些参数,如重定向地址redirect_uri、state等,其中的state为应用程序传递的一个随机数,用来防止csrf攻击。此外,本技术所述授权码参数中还包括加密串和加密算法,将加密串和加密算法发送给授权服务,可以在后续申请访问令牌时用以验证。
52.步骤102:获得授权服务在对所述授权码请求参数验证合法后返回的授权码。
53.授权服务在接收到上述授权码请求参数后,可以对其进行客户端标识等内容的相关验证,若验证通过,则同意为无服务端第三方应用授权,并返回授权码。
54.步骤103:无服务端第三方应用向授权服务请求访问令牌,访问令牌请求参数中包括所述授权码、所述随机字符串和所述加密算法。
55.无服务端第三方应用在收到授权码后,可以继续向授权服务请求访问令牌,只有在获得访问令牌后,才能够完成授权流程。
56.客户端密钥在常规方案中均存储于服务端,但本技术方案针对的是无服务端的应用,因此本方案中传送的相关参数(访问令牌请求参数)中并不包括客户端密钥,而是通过前文所述加密串、加密算法和随机字符串进行响应的安全认证。
57.步骤104:获得授权服务在对所述访问令牌请求参数验证合法后返回的访问令牌,其中,所述授权服务对所述访问令牌请求参数的验证包括对所述授权码的验证和对所述加密串的验证,所述加密串的验证基于所述访问令牌请求参数中的所述随机字符串和所述加密算法实现。
58.授权服务在接收到所述随机字符串和所述加密算法后,可以采用所述加密算法对所述随机字符串进行加密,得到加密数据;若该加密数据与之前无服务端第三方应用在请求授权码时发送的加密串相同,则确定加密串验证通过;此外,在授权码也验证通过的情况下,授权服务就会为无服务端第三方应用办法访问令牌。
59.本技术实施例所述的无服务端的授权方法,在授权码模式的基础上追加了一个验证因子组,从而能够提高无服务端客户端的抗供给能力;从而无服务端的客户端不依赖于客户端密钥也能够安全的进行授权流程,进行受保护资源的访问,从而对一些轻量级的没有服务端的客户端提供更好的服务支持;采用该方案,能够有效解决无服务端第三方应用授权过程中授权码可能被截获、cxrf攻击的问题。
60.一个实现中,对于无服务端的客户端或第三方应用,可以将其标识为有限信任客户端,只享受部分受保护资源访问的权限,以尽量减少客户端本身都是仿造的造成的影响。
61.具体的,无服务端客户端第三方软件来开放平台注册时,会被标识为有限信任客户端,并设置访问令牌有效期(1~10分钟)。有限信任客户端仅能访问公开操作类和安全等级较低的普通隐私类数据,而对于一些安全等级稿的核心隐私数据,有限信任客户端仍旧不能访问。
62.一个示例中,无服务端的授权方法实现过程可以包括如下:
63.第一步:第三方软件在获取授权码的流程中,除了授权码模式中要求的参数,额外增加一个验证因子组。该因子由一个code_random_str(随机的43~128位字符串)进行加密后的code_sign(加密串)+对应的code_sign_method(加密算法标识(约定的枚举类型))。
64.第二步:第三方软件在获取访问令牌access_token流程中,授权码模式中要求的
参数中,客户端密钥client_secret不需要传递了,额外增加第一步中的code_random_str+code_sign_method,授权服务返回访问令牌access_token+刷新数据refresh_sign+刷新方法refresh_sign_method(约定的枚举类型)给第三方软件。
65.第三步:拿着第二步获取到的访问令牌access_token+刷新数据refresh_sign+刷新方法refresh_sign_method在访问令牌access_token失效时间之内请求授权服务的令牌刷新接口换取新的访问令牌access_token+刷新数据refresh_sign+刷新方法refresh_sign_method,这是一个access_token的持续交换流程,对用户是无感知的。
66.本实现中,在有限信任客户端的设置下,既可以保证比较好的用户体验,不影响客户端的授权流程,也保证了核心隐私数据的安全性。
67.图2为本发明实施例公开的刷新访问令牌的流程图。由于访问令牌具有有效期,因此,结合图2和前述实施例内容,在所述获得授权服务在对所述访问令牌请求参数验证合法后返回的访问令牌后,还可以包括:
68.步骤201:在所述访问令牌的有效期内,向授权服务请求刷新访问令牌。
69.步骤202:获得授权服务在对刷新访问令牌的请求验证合法后返回的新的访问令牌。
70.其中,授权服务在首次返回的访问令牌的参数中包括重签数据和重签方法,不包括客户端密钥,刷新访问令牌请求参数中包括所述重签数据和所述重签方法,则所述获得授权服务在对刷新访问令牌的请求验证合法后返回的新的访问令牌,可以包括:获得授权服务在对所述重签数据和所述重签方法验证成功后返回的刷新后的访问令牌。
71.其中,授权服务对所述重签数据和所述重签方法的验证可以包括:对本地存储的重签字符串换按照所述重签方法进行加密,得到重签加密数据;在所述重签加密数据和所述重签数据相同时,确认验证通过。
72.而授权服务返回的所述刷新后的访问令牌的参数中,也包括刷新的重签数据和刷新的重签方法,以便于下次请求刷新访问令牌时使用。
73.前述实施例中,在所述获得授权服务在对所述授权码请求参数验证合法后返回的授权码前,还可以包括:接收用户触发的同意授权指令。只有无服务端的客户端的用户在同意为无服务端第三方应用授权时,授权服务才会给无服务端第三方应用返回授权码;而在所述获得授权服务在对所述授权码请求参数验证合法后返回的授权码前,若收到用户触发的拒绝授权指令,则结束授权流程。
74.图3为本发明实施例公开的无服务端的授权方法的交互时序示意图。结合图3所示,一个具体实现中,当第三方应用为无服务端客户端时,需要在开放平台开发者中心注册时指明相关信息:注册应用需要勾选对应无服务端客户端选项;勾选无服务端客户端选项选项后,会出现一个特殊token失效时间选项,该时间可选范围内尽可能的短,提高安全性;access_token默认时间可以设为5分钟失效,refresh_token为2天;开放平台会提示第三方开发者使用正确的模式与使用说明。
75.授权码code获取流程:
76.第1步:客户端准备工作
[0077]-生成一个随机的43~128位字符串:code_random_str
[0078]-注册应用时提供的加密算法枚举中选取一种(都是通用的不同种类算法):code_
sign_method
[0079]-根据code_random_str与code_sign_method生成加密串code_sign,类似伪代码:base64url_encode(code_sign_method(ascii(code_random_str)))
[0080]
第2步:请求获取授权码接口,该接口除了授权码模式要求的参数外,额外增加验证因子组code_sign、code_sign_method作为参数传递。
[0081]
请求参数:
[0082][0083]
返回参数:
[0084]
用户允许授权后,将会重定向到redirect_uri的网址上,并且带上code和state参数,code在授权服务是一次性使用的,并且有失效时间设置。
[0085]
redirect_uri?code={code}&state={state}
[0086]
若用户禁止、取消、非法授权,则重定向后不会带上code参数,仅会带上state参数与错误描述
[0087]
redirect_uri?state={state}&error_code=100001&error_msg=invalid_xxx。
[0088]
访问令牌acess_token获取流程:
[0089]
第1步:请求获取访问令牌接口,授权码模式中要求的参数中,client_secret不需要传递,额外增加第一步生成的code_random_str与code_sign_method参数。
[0090]
第2步:授权服务进行校验,使用获取授权码流程中传入的code_sign值与第二步传入的code_random_str+code_sign_method进行与客户端一样的运算得到的值进行对比,如果相同才颁发令牌。
[0091]
请求参数:
[0092]
[0093][0094]
返回参数:
[0095][0096]
刷新访问令牌acess_token流程:
[0097]
拿着访问令牌获取流程中得到的access_token+refresh_sign+refresh_sign_method在access_token失效时间之内请求授权服务的token刷新接口换取新的access_token+refresh_sign+refresh_sign_method,这是一个access_token的持续交换流程,对用户是无感知的。
[0098][0099]
返回参数:
[0100][0101][0102]
对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本发明并不受所描述的动作顺序的限制,因为依据本发明,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本发明所必须的。
[0103]
上述本发明公开的实施例中详细描述了方法,对于本发明的方法可采用多种形式的装置实现,因此本发明还公开了一种装置,下面给出具体的实施例进行详细说明。
[0104]
图4为本发明实施例公开的一种无服务端的授权装置的结构示意图。参见图4所示,无服务端的授权装置40可以包括:
[0105]
授权码请求模块401,用于向授权服务请求授权码,授权码请求参数中包括加密串和加密算法,所述加密串由随机字符串基于所述加密算法计算得到。
[0106]
授权码接收模块402,用于获得授权服务在对所述授权码请求参数验证合法后返回的授权码。
[0107]
令牌请求模块403,用于向授权服务请求访问令牌,访问令牌请求参数中包括所述授权码、所述随机字符串和所述加密算法,不包括客户端密钥。
[0108]
令牌接收模块404,用于获得授权服务在对所述访问令牌请求参数验证合法后返回的访问令牌,其中,所述授权服务对所述访问令牌请求参数的验证包括对所述授权码的验证和对所述加密串的验证,所述加密串的验证基于所述访问令牌请求参数中的所述随机字符串和所述加密算法实现。
[0109]
本技术实施例所述的无服务端的授权装置,在授权码模式的基础上追加了一个验证因子组,从而能够提高无服务端客户端的抗供给能力;从而无服务端的客户端不依赖于客户端密钥也能够安全的进行授权流程,进行受保护资源的访问,从而对一些轻量级的没有服务端的客户端提供更好的服务支持;采用该方案,能够有效解决无服务端第三方应用授权过程中授权码可能被截获、cxrf攻击的问题。
[0110]
一个实现中,所述访问令牌具有有效期,则还包括:令牌刷新模块,用于在所述访问令牌的有效期内,向授权服务请求刷新访问令牌;所述令牌获得模块还用于:获得授权服务在对刷新访问令牌的请求验证合法后返回的新的访问令牌。
[0111]
上述实施例中的所述的任意一种无服务端的授权装置包括处理器和存储器,上述实施例中的授权码请求模块、授权码接收模块、令牌请求模块、令牌接收模块、令牌刷新模块等均作为程序模块存储在存储器中,由处理器执行存储在所述存储器中的上述程序模块来实现相应的功能。
[0112]
处理器中包含内核,由内核去存储器中调取相应的程序模块。内核可以设置一个或多个,通过调整内核参数来实现回访数据的处理。
[0113]
存储器可能包括计算机可读介质中的非永久性存储器,随机存取存储器(ram)和/或非易失性内存等形式,如只读存储器(rom)或闪存(flash ram),存储器包括至少一个存储芯片。
[0114]
在示例性实施例中,还提供了一种计算机可读存储介质,可直接加载到计算机的内部存储器,其中含有软件代码,该计算机程序经由计算机载入并执行后能够实现上述无服务端的授权方法任一实施例所示步骤。
[0115]
在示例性实施例中,还提供一种计算机程序产品,可直接加载到计算机的内部存储器,其中含有软件代码,该计算机程序经由计算机载入并执行后能够实现上述所述的无服务端的授权方法任一实施例所示步骤。
[0116]
进一步,本发明实施例提供了一种电子设备。图5为本技术实施例公开的一种电子设备的结构示意图。参见图5所示,电子设备包括至少一个处理器501、以及与处理器连接的
至少一个存储器502、总线503;其中,处理器、存储器通过总线完成相互间的通信;处理器用于调用存储器中的程序指令,以执行上述的无服务端的授权方法。
[0117]
本说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言,由于其与实施例公开的方法相对应,所以描述的比较简单,相关之处参见方法部分说明即可。
[0118]
还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个
……”
限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
[0119]
结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块,或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。
[0120]
对所公开的实施例的上述说明,使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下,在其它实施例中实现。因此,本发明将不会被限制于本文所示的这些实施例,而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1