CN113645247A - 一种基于http协议的权限认证控制方法及存储介质 - Google Patents
一种基于http协议的权限认证控制方法及存储介质 Download PDFInfo
- Publication number
- CN113645247A CN113645247A CN202110941493.9A CN202110941493A CN113645247A CN 113645247 A CN113645247 A CN 113645247A CN 202110941493 A CN202110941493 A CN 202110941493A CN 113645247 A CN113645247 A CN 113645247A
- Authority
- CN
- China
- Prior art keywords
- client
- authorization
- token
- server
- authorization server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Information Transfer Between Computers (AREA)
Abstract
本发明涉及信息技术领域,提供了一种基于HTTP协议的权限认证控制方法及存储介质。目的在于解决传统身份验证流程中,需要存储访问凭证、要求进行密码校验、无法对相同凭证做不同的权限控制、存在泄露账号和密码的漏洞等问题。主要方案包括客户端向授权服务器发起授权请求,获取通过用户代理重定向获的资源所有者的授权;客户端收到授权码授予;客户端通过获得的授权码向授权服务器请求权限身份认证来获得访问令牌;授权服务器对客户端进行认证并验证授权码,如果有效,则颁发访问令牌;客户端向资源服务器请求受保护的资源,服务器通过访问令牌进行身份验证;资源服务器验证访问令牌,如果有效,则接受请求并返回资源。
Description
技术领域
本发明涉及信息技术领域,提供了一种基于HTTP协议的权限认证控制方法及存储介质。
技术背景
在传统的客户端-服务器身份验证模型中,客户端向服务器请求访问受保护的资源时,通过使用资源所有者的身份与服务器进行身份认证,从而获得访问凭证。为了提供给第三方应用程序访问受限资源,资源所有者需要向第三方分享访问凭证,而这会带来几个问题和局限性:
1、第三方应用程序需要存储资源所有者的访问凭证以防未来需要使用,而这种凭证通常是用户名和密码。
2、一般服务器都会要求客户端进行密码校验,但是密码存在弱密码、重复密码等安全缺陷。
3、第三方应用程序可以获得受限资源全部的访问权限,而资源所有者无法对资源的访问时间和范围做任何限制。
4、资源所有者无法撤销单个第三方访问者的访问权限,如果要撤销的话,就必须修改密码,但是这样会撤销所有使用相同账户密码的第三方访问者的访问权限。
5、任何一个第三方泄露了账号和密码,都会损害使用相同账号的第三方访问者,而且也会损害受该账号密码保护的数据安全。
此基于HTTP协议的权限认证控制方案,通过引入授权层并且将客户端的角色与资源所有者进行分离,解决了这些问题。在此方案中,客户端请求访问资源时,可被资源所有者所在的资源服务器所控制,并且资源所有者可以向客户端分发不通的访问凭证,而不是使用资源所有者的凭据来访问受保护的资源,客户端获得访问令牌(一串加密字符串,包含令牌的生存周期、特定范围和其他访问属性)。访问令牌是由授权服务器向第三方客户端颁发资源所有者的批准,客户端使用访问令牌来访问资源服务器托管的受保护的资源。
发明内容
本发明的目的在于解决传统身份验证流程中,需要存储访问凭证、要求进行密码校验、无法对相同凭证做不同的权限控制、无法撤销单个访问者的访问权限、存在泄露账号和密码的漏洞等问题。
为解决上述技术问题,本发明采用以下技术手段:
一种基于HTTP协议的权限认证控制方法,包括以下步骤:
步骤1、客户端向授权服务器发起授权请求,获取通过用户代理重定向获的资源所有者的授权;
步骤2、客户端收到授权码授予;
步骤S3:客户端通过获得的授权码向授权服务器请求权限身份认证来获得访问令牌;
步骤S4:授权服务器对客户端进行认证并验证授权码,如果有效,则颁发访问令牌;
步骤S5:客户端向资源服务器请求受保护的资源,服务器通过访问令牌进行身份验证;
步骤S6:资源服务器验证访问令牌,如果有效,则接受请求并返回资源。
上述技术方案中,授权码授予包含以下步骤:
步骤2.1、客户端通过向资源服务表明客户端的请求身份来启动流程授权服务器的用户代理,客户端包含它的客户标识符,请求的范围,本地状态和一个授权服务器将重定向的URI;
步骤2.2、授权服务器对资源所有者进行身份验证,并确定资源所有者是否授予或拒绝客户端的访问请求;
步骤2.3、如资源所有者授予访问权限,则授权服务器将用户代理重定向回客户端先前提供的重定向URI,重定向URI包含一个授权代码和客户端提供的本地状态。
上述技术方案中,步骤3包括:
步骤3.1、客户端通过在上一步收到的授权码向授权服务器的令牌端点请求访问令牌,发送请求时,客户端通过授权服务器进行身份验证;
步骤3.2、授权服务器对客户端提供的授权码进行身份验证,并确保收到的重定向URI与用于重定向客户端的URI匹配,如果授权码有效,授权服务器则回复访问令牌和刷新令牌。
上述技术方案中,步骤3包括:
客户端通过添加参数并通过“application/x-www-form-urlencoded”格式的内容来构造请求URI:
response_type必需参数,值必须设置为“token”;
client_id必须参数,客户标识符;
redirect_uri可选参数,重定向URI;
scope可选参数,表示授权请求的范围;
state推荐的参数,客户端用来维护请求和回调之间的状态,授权服务器将用户重定向返回时会将此值返回给客户端,用于防止跨站点伪请求攻击;
客户端通过HTTP重定向直接访问资源所有者的URI,或者通过可接收的用户代理来访问;
授权服务器验证请求以确保所有必需的参数存在且有效,授权服务器必须验证将其重定向到的重定向URI与客户端请求时的重定向URI匹配;
如果请求有效,则授权服务器对资源所有者的授权进行决策;
建立决策后,授权服务器将指导使用HTTP的用户代理到提供的客户端重定向URI进行重定向响应。
上述技术方案中,步骤4中,
如果资源所有者批准了访问请求,则授权服务器发布访问令牌,并通过添加以下参数将其传递给客户端和重定向的URI,使用“application/x-www-form-urlencoded”格式;
access_token必需的,授权服务器发布的访问令牌;
token_type必需的,发布的令牌类型;
expires_in推荐的,表示访问令牌的生存时间;
scope可选的,如果与客户端请求的范围相同则可选,否则必填;
state如果客户端请求参数中有此值,则响应令牌时此参数是必填的;
客户端需要忽略无法识别的响应参数,应避免对值的大小做出限制,需要接收授权服务器返回的访问令牌的任何大小。
上述技术方案中,步骤5中,
如果访问令牌请求有效且已授权,则授权服务器发出访问令牌和可选的刷新令牌;如果请求失败,客户端验证无效,授权服务器返回一个错误响应;
S5.1成功响应:
授权服务器发出访问令牌和可选的刷新令牌,并通过添加以下参数来构建响应状态为200的HTTP响应实体正文;
access_token必需的,授权服务器发布的访问令牌;
token_type必需的,发布的令牌类型;
expires_in推荐的,表示访问令牌的生存时间;
refresh_token可选的,刷新令牌,可用于获取新令牌;
scope可选的,如果与客户端请求的范围相同则可选,否则必填;
参数包含在HTTP响应的实体主体中,使用“application/json”媒体类型,这些参数被序列化为JavaScript的对象表达,通过在顶层级别中添加每个参数来构建结构,参数名称和字符串值作为JSON字符串包含在内,参数值在JSON串内的编号顺序无关紧要,并且每次请求都有可能不同;
授权服务器必须包含HTTP的“Cache-Control”返回头,值为“no-sotre”,其他敏感信息的响应,需要添加“Pragma”的响应头,值为“no-cache”;
S5.2错误响应:
授权服务器以HTTP 400来响应状态码,包括以下参数来构建响应:
error必需的,具体错误代码如下:
invalid_request无效的请求,该请求缺少必需的参数,或者参数格式不正确;
invalid_client客户端身份验证失败,授权服务器可以返回HTTP 401(未经授权)状态码,如果客户端尝试通过“Authorization”放在请求头进行身份验证,授权服务器必须使用HTTP 401状态码进行响应,并且包含“WWW-Authenticate”的响应头部字段来匹配客户端的身份验证;
invalid_grant提供的授权码或刷新令牌为无效、已过期、已吊销,授权请求中使用的URI与重定向不匹配,或已发布的URI是其他客户;
unauthorized_client未经授权的客户,经身份验证的客户端无权使用此客户端授权的类型;
unsupported_grant_type授权服务器不支持的授权授予类型;
invalid_scope请求的范围无效、未知、格式错误或超出了资源所有者授予的范围;
error_description可选的,错误描述;
error_url可选的,一个URI,用于标识具有错误描述的可读内容的网页。
上述技术方案中,步骤6中,
S6.1客户端认证:
授权服务器通过与Web应用客户端建立凭证来对客户端进行身份验证,授权服务器鼓励客户端使用比传统密码等验证方式强大的身份验证手段,Web应用客户端必须确保客户端密码和其他客户端机密性的证书;
授权服务器不得发布客户端密码或其他客户端凭据到本机应用程序或基于用户代理的应用程序客户端;
如果无法进行客户端身份验证,则授权服务器采用其他方式来验证客户的身份,通过要求注册客户端重定向URI或邀请资源所有者确认身份,一个有效的重定向URI不足以验证客户端的身份在请求资源所有者授权时,但可以用来防止在以后向假冒客户提供凭据获得资源所有者的授权;
S6.2访问令牌
访问令牌凭证在运输和存放时必须保密,并且仅在授权服务器,资源服务器之间共享访问令牌对其有效,并且访问令牌所针对的客户端发布,访问令牌凭证只能使用TLS传输,
使用隐式授予类型时,将传输访问令牌URI片段中的内容,可以将其暴露给未经授权的各方;
授权服务器必须确保访问令牌不能为生成,修改或猜测以通过以下方式产生有效的访问令牌未经授权的各方;
客户端应该以最小范围请求访问令牌必要的,授权服务器应采用客户端身份选择如何遵守要求的范围时应考虑在内,并且可以发行权限少于请求权限的访问令牌;
S6.3刷新令牌
授权服务器可以向Web应用程序发布刷新令牌客户端和本机应用程序客户端;
刷新令牌在运输和存储时必须保持机密,并且仅在授权服务器和客户端之间共享刷新令牌已发行,授权服务器必须维护刷新令牌与该客户端所绑定的客户端之间的绑定发布,刷新令牌必须仅使用TLS进行传输;
授权服务器必须验证刷新之间的绑定只要客户端身份可以是令牌和客户端身份已验证,如果无法进行客户端身份验证,则授权服务器应该部署其他手段来检测刷新令牌滥用,
先前的刷新令牌无效但由授权服务器保留,如果刷新令牌是遭到攻击者攻击,随后被攻击者和合法客户端,其中之一将显示无效的刷新令牌,它将通知违规的授权服务器;
S6.4授权码
授权代码的传输应通过安全的方式进行频道,并且客户端应要求将TLS及其重定向URI,自从授权代码是通过用户代理重定向传输的,它们可能会通过用户代理历史记录和HTTP进行披露引荐来源标头;
授权代码用作纯文本承载凭据,用于验证在授予了授权的资源所有者授权服务器与返回到服务器的资源所有者相同客户来完成该过程,因此,如果客户依靠自己的资源所有者身份验证的授权代码,客户端重定向端点必须要求使用TLS;
授权码必须是短期的且只能使用一次,如果授权服务器观察到多次尝试交换访问令牌的授权码,授权服务器应该尝试根据以下条件撤销所有已授予的访问令牌泄露的授权码,
如果客户端可以通过身份验证,则授权服务器必须对客户端进行身份验证,并确保授权码为发行给相同的客户。
本发明还提供了一种存储介质,所述存储介质中存储有一种基于HTTP协议的权限认证控制的程序,CPU在执行所述程序时实现上述的一种基于HTTP协议的权限认证控制方法。
上述技术方案中,权限授予有三个类型:
1、授权码:通过使用授权服务器获得授权码,作为客户端和资源所有者之间的中介。作为替代直接向资源所有者请求的方式,客户端向资源服务器的请求会被定向到授权服务器中定义的用户代理,该代理会指导资源所有者将授权码返回给客户端。
2、密码式:资源所有者的密码凭据可以直接用作授权授予来获取访问权限令牌,凭证仅在有较高权限的情况下使用,资源所有者和客户端之间需要信任。
3、凭证式:客户端事先获取授权服务器下发的授权凭证,当需要访问受保护的资源服务器时,上送授权凭证到授权服务器,服务器校验有效期并下发访问令牌。
上述技术方案中,所述访问令牌的具体规则如下:
访问令牌是用于访问受保护资源的凭据。一个访问令牌是一个字符串,该字符串通常对客户端而言是不透明的,通常代表被资源所有者授予访问者的特定访问范围和持续时间。
令牌可以表示用于检索授权的标识符信息,也可以将可验证的授权信息包含在其中。访问令牌提供了一个抽象层,用来替换现有的授权结构(例如用户名和密码)。这种抽象使得令牌比一般的授权形式具有更多的获取上的限制性,这样资源服务器就不需要理解各种授权的方法。访问令牌可以具有不同的格式、结构和基于服务器安全要求的方法。
上述技术方案中,所述刷新令牌的具体规则如下:
刷新令牌是用于获取访问令牌的凭据,刷新令牌的指令由授权服务器发布给客户端,当当前访问令牌无效或过期时下发。包括以下步骤:
步骤1、客户端通过向授权服务器进行身份验证来请求访问令牌并获得授权授予;
步骤2、授权服务器对客户端进行身份验证并验证授权授予,如果有效,则颁发访问令牌和刷新令牌;
步骤3、客户端通过出示访问令牌向资源服务器发出受保护资源的访问请求;
步骤4、资源服务器验证访问令牌,如果有效,则接受访问请求;
步骤5、重复步骤3和步骤4,直到访问令牌过期,如果客户端知道访问令牌已过期,则跳至步骤7,否则,客户端将发出另一个受保护的资源请求;
步骤6、由于访问令牌无效,因此资源服务器返回无效的令牌错误;
步骤7、客户端通过向授权服务器进行身份验证来请求新的访问令牌并刷新令牌;
步骤8、授权服务器对客户端进行身份验证并验证刷新令牌,如果有效,则发出新的访问令牌。
因为本发明采用以上技术方案,因此具备以下有益效果:
此基于HTTP协议的权限认证控制方案,通过引入授权层并且将客户端的角色与资源所有者进行分离,解决了传统身份验证流程中,需要存储访问凭证、要求进行密码校验、无法对相同凭证做不同的权限控制、无法撤销单个访问者的访问权限、存在泄露账号和密码的漏洞等问题。在此方案中,客户端请求访问资源时,可被资源所有者所在的资源服务器所控制,并且资源所有者可以向客户端分发不通的访问凭证,而不是使用资源所有者的凭据来访问受保护的资源,客户端获得访问令牌(一串加密字符串,包含令牌的生存周期、特定范围和其他访问属性)。访问令牌是由授权服务器向第三方客户端颁发资源所有者的批准,客户端使用访问令牌来访问资源服务器托管的受保护的资源。
具体实施方式:
本发明提供了一种基于HTTP协议的权限认证控制方案,包括以下步骤:
步骤S1:客户端向资源所有者请求授权;
步骤S2:客户端收到授权码授予;
步骤S3:客户端通过获得的授权码向授权服务器请求权限身份认证来获得访问令牌;
步骤S4:授权服务器对客户端进行认证并验证授权码,如果有效,则颁发访问令牌;
步骤S5:客户端向资源服务器请求受保护的资源,服务器通过访问令牌进行身份验证;
步骤S6:资源服务器验证访问令牌,如果有效,则接受请求并返回资源。
步骤S1具体说明:
S1.1协议端点:
授权过程利用两个授权服务器端点(HTTP资源):
·授权端点-客户端用于获取通过用户代理重定向获得资源所有者的授权;
·令牌端点-客户端用于交换授权,授予访问令牌,通常使用客户端身份来验证。
以及一个客户端端点:
·重定向端点-授权服务器用于返回包含授权凭证的响应,通过客户端发送给资源所有者用户代理。
S1.2授权端点:
授权端点用于与资源拥有者进行交互并获得授权码授予。授权服务器必须首先验证资源所有者的身份,端点URI可以包含“application/x-www-form-urlencoded”,由于对授权端点的请求导致用户身份验证和明文凭证的传输,授权服务器必须要求使用TLS协议,将请求发送到授权端点。授权服务器必须支持HTTP“GET”方法来进行授权端点的交互,也可以支持使用“POST”方法。
步骤S2具体说明:
授权码授予用于同时获得访问令牌和刷新令牌,并针对客户端的加密做了优化,因为包含基于重定向的流程,因此客户端必须能够与资源所有者的用户代理进行交互并能够从授权服务器接收传入的请求。
授权码授予包含以下步骤:
i.客户端通过指示资源所有者的身份来启动流程授权端点的用户代理。客户端包含它的客户标识符,请求的范围,本地状态和一个授权服务器将重定向的URI,一旦授予访问权限,用户代理就会返回。
ii.授权服务器对资源所有者进行身份验证,并确定资源所有者是否授予或拒绝客户端的访问请求。
iii.假设资源所有者授予访问权限,则授权服务器将用户代理重定向回客户端先前提供的重定向URI,重定向URI包含一个授权代码和客户端提供的本地状态。
步骤S3具体说明:
客户端通过添加参数并通过“application/x-www-form-urlencoded”格式的内容来构造请求URI:
response_type必需参数,值必须设置为“token”。
client_id必须参数,客户标识符。
redirect_uri可选参数,重定向URI。
scope可选参数,表示授权请求的范围。
state推荐的参数,客户端用来维护请求和回调之间的状态,授权服务器将用户重定向返回时会将此值返回给客户端,用于防止跨站点伪请求攻击。
客户端通过HTTP重定向直接访问资源所有者的URI,或者通过可接收的用户代理来访问。
例如,客户端通过下面的HTTP请求使用TLS协议来访问用户代理:
GET/authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1Host:server.example.com
授权服务器验证请求以确保所有必需的参数存在且有效。授权服务器必须验证将其重定向到的重定向URI与客户端请求时的重定向URI匹配。
如果请求有效,则授权服务器对资源所有者的授权进行决策(通过询问资源所有者或通过其他方式获得批准)。
建立决策后,授权服务器将指导使用HTTP的用户代理到提供的客户端重定向URI进行重定向响应。
步骤S4具体说明:
如果资源所有者批准了访问请求,则授权服务器发布访问令牌,并通过添加以下参数将其传递给客户端和重定向的URI,使用“application/x-www-form-urlencoded”格式。
access_token必需的,授权服务器发布的访问令牌。
token_type必需的,发布的令牌类型。
expires_in推荐的,表示访问令牌的生存时间(以秒为单位)。例如,值“3600”表示访问令牌将在生成响应后的一小时内过期。
scope可选的,如果与客户端请求的范围相同则可选,否则必填。
state如果客户端请求参数中有此值,则响应令牌时此参数是必填的。
例如,授权服务器通过以下参数和重定向用户代理发送HTTP响应:
客户端需要忽略无法识别的响应参数,应避免对值的大小做出限制,需要接收授权服务器返回的访问令牌的任何大小。
步骤S5具体说明:
如果访问令牌请求有效且已授权,则授权服务器发出访问令牌和可选的刷新令牌。如果请求失败,客户端验证无效,授权服务器返回一个错误响应。
S5.1成功响应:
授权服务器发出访问令牌和可选的刷新令牌,并通过添加以下参数来构建响应状态为200的HTTP响应实体正文。
access_token必需的,授权服务器发布的访问令牌。
token_type必需的,发布的令牌类型。
expires_in推荐的,表示访问令牌的生存时间(以秒为单位)。例如,值“3600”表示访问令牌将在生成响应后的一小时内过期。
refresh_token可选的,刷新令牌,可用于获取新令牌。
scope可选的,如果与客户端请求的范围相同则可选,否则必填。
参数包含在HTTP响应的实体主体中,使用“application/json”媒体类型,这些参数被序列化为JavaScript的对象表达,通过在顶层级别中添加每个参数来构建结构。参数名称和字符串值作为JSON字符串包含在内,参数值在JSON串内的编号顺序无关紧要,并且每次请求都有可能不同。
授权服务器必须包含HTTP的“Cache-Control”返回头,值为“no-sotre”,其他敏感信息的响应,需要添加“Pragma”的响应头,值为“no-cache”。
例如:
S5.2错误响应:
授权服务器以HTTP 400(错误请求)来响应状态码,包括以下参数来构建响应:
error必需的,具体错误代码如下:
invalid_request无效的请求,该请求缺少必需的参数,或者参数格式不正确。
invalid_client客户端身份验证失败,授权服务器可以返回HTTP 401(未经授权)状态码,如果客户端尝试通过“Authorization”放在请求头进行身份验证,授权服务器必须使用HTTP 401状态码进行响应,并且包含“WWW-Authenticate”的响应头部字段来匹配客户端的身份验证。
invalid_grant提供的授权码或刷新令牌为无效、已过期、已吊销,授权请求中使用的URI与重定向不匹配,或已发布的URI是其他客户。
unauthorized_client未经授权的客户,经身份验证的客户端无权使用此客户端授权的类型。
unsupported_grant_type授权服务器不支持的授权授予类型。
invalid_scope请求的范围无效、未知、格式错误或超出了资源所有者授予的范围。
error_description可选的,错误描述。
error_url可选的,一个URI,用于标识具有错误描述的可读内容的网页。
例如:
步骤S6具体说明:
S6.1客户端认证:
授权服务器通过与Web应用客户端建立凭证来对客户端进行身份验证。授权服务器鼓励客户端使用比传统密码等验证方式强大的身份验证手段。Web应用客户端必须确保客户端密码和其他客户端机密性的证书。
授权服务器不得发布客户端密码或其他客户端凭据到本机应用程序或基于用户代理的应用程序客户端。
如果无法进行客户端身份验证,则授权服务器
应该采用其他方式来验证客户的身份-例如,通过要求注册客户端重定向URI或邀请资源所有者确认身份。一个有效的重定向URI不足以验证客户端的身份在请求资源所有者授权时,但可以用来防止在以后向假冒客户提供凭据获得资源所有者的授权。
S6.2访问令牌
访问令牌凭证(以及任何机密访问令牌)在运输和存放时必须保密,并且仅在授权服务器,资源服务器之间共享访问令牌对其有效,并且访问令牌所针对的客户端发布。访问令牌凭证只能使用TLS传输。
使用隐式授予类型时,将传输访问令牌URI片段中的内容,可以将其暴露给未经授权的各方。
授权服务器必须确保访问令牌不能为生成,修改或猜测以通过以下方式产生有效的访问令牌未经授权的各方。
客户端应该以最小范围请求访问令牌必要的。授权服务器应采用客户端身份选择如何遵守要求的范围时应考虑在内,并且可以发行权限少于请求权限的访问令牌。
S6.3刷新令牌
授权服务器可以向Web应用程序发布刷新令牌客户端和本机应用程序客户端。
刷新令牌在运输和存储时必须保持机密,并且仅在授权服务器和客户端之间共享刷新令牌已发行。授权服务器必须维护刷新令牌与该客户端所绑定的客户端之间的绑定发布。刷新令牌必须仅使用TLS进行传输。
授权服务器必须验证刷新之间的绑定只要客户端身份可以是令牌和客户端身份已验证。如果无法进行客户端身份验证,则授权服务器应该部署其他手段来检测刷新令牌滥用。
例如,授权服务器可以使用刷新令牌每次访问都会发出新的刷新令牌的循环令牌刷新响应。先前的刷新令牌无效
但由授权服务器保留。如果刷新令牌是遭到攻击者攻击,随后被攻击者和合法客户端,其中之一将显示无效的刷新令牌,它将通知违规的授权服务器。
S6.4授权码
授权代码的传输应通过安全的方式进行频道,并且客户端应要求将TLS及其重定向URI(如果URI标识了网络资源)。自从授权代码是通过用户代理重定向传输的,它们可能会通过用户代理历史记录和HTTP进行披露引荐来源标头。
授权代码用作纯文本承载凭据,用于验证在授予了授权的资源所有者授权服务器与返回到服务器的资源所有者相同客户来完成该过程。因此,如果客户依靠自己的资源所有者身份验证的授权代码,客户端重定向端点必须要求使用TLS。
授权码必须是短期的且只能使用一次。如果授权服务器观察到多次尝试交换访问令牌的授权码,授权服务器应该尝试根据以下条件撤销所有已授予的访问令牌泄露的授权码。
如果客户端可以通过身份验证,则授权服务器必须对客户端进行身份验证,并确保授权码为发行给相同的客户。
Claims (8)
1.一种基于HTTP协议的权限认证控制方法,其特征在于,包括以下步骤:
步骤1、客户端向授权服务器发起授权请求,获取通过用户代理重定向获得资源所有者的授权;
步骤2、客户端收到授权码授予;
步骤S3:客户端通过获得的授权码向授权服务器请求权限身份认证来获得访问令牌;
步骤S4:授权服务器对客户端进行认证并验证授权码,如果有效,则颁发访问令牌;
步骤S5:客户端向资源服务器请求受保护的资源,服务器通过访问令牌进行身份验证;
步骤S6:资源服务器验证访问令牌,如果有效,则接受请求并返回资源。
2.根据权利要求1所述的一种基于HTTP协议的权限认证控制方法,其特征在于,授权码授予包含以下步骤:
步骤2.1、客户端通过向资源服务表明客户端的请求身份来启动流程授权服务器的用户代理,客户端包含它的客户标识符,请求的范围,本地状态和一个授权服务器将重定向的URI;
步骤2.2、授权服务器对资源所有者进行身份验证,并确定资源所有者是否授予或拒绝客户端的访问请求;
步骤2.3、如资源所有者授予访问权限,则授权服务器将用户代理重定向回客户端先前提供的重定向URI,重定向URI包含一个授权代码和客户端提供的本地状态。
3.根据权利要求1所述的一种基于HTTP协议的权限认证控制方法,其特征在于,步骤3包括:
步骤3.1、客户端通过在上一步收到的授权码向授权服务器的令牌端点请求访问令牌,发送请求时,客户端通过授权服务器进行身份验证;
步骤3.2、授权服务器对客户端提供的授权码进行身份验证,并确保收到的重定向URI与用于重定向客户端的URI匹配,如果授权码有效,授权服务器则回复访问令牌和刷新令牌。
4.根据权利要求3所述的一种基于HTTP协议的权限认证控制方法,其特征在于,步骤3包括:
客户端通过添加参数并通过“application/x-www-form-urlencoded”格式的内容来构造请求URI:
response_type必需参数,值必须设置为“token”;
client_id必须参数,客户标识符;
redirect_uri可选参数,重定向URI;
scope可选参数,表示授权请求的范围;
state推荐的参数,客户端用来维护请求和回调之间的状态,授权服务器将用户重定向返回时会将此值返回给客户端,用于防止跨站点伪请求攻击;
客户端通过HTTP重定向直接访问资源所有者的URI,或者通过可接受的用户代理来访问;
授权服务器验证请求以确保所有必需的参数存在且有效,授权服务器必须验证将其重定向到的重定向URI与客户端请求时的重定向URI匹配;
如果请求有效,则授权服务器对资源所有者的授权进行决策;
建立决策后,授权服务器将指导使用HTTP的用户代理到提供的客户端重定向URI进行重定向响应。
5.根据权利要求1所述的一种基于HTTP协议的权限认证控制方法,其特征在于,步骤4中,
如果资源所有者批准了访问请求,则授权服务器发布访问令牌,并通过添加以下参数将其传递给客户端和重定向的URI,使用“application/x-www-form-urlencoded”格式;
access_token必需的,授权服务器发布的访问令牌;
token_type必需的,发布的令牌类型;
expires_in推荐的,表示访问令牌的生存时间;
scope可选的,如果与客户端请求的范围相同则可选,否则必填;
state如果客户端请求参数中有此值,则响应令牌时此参数是必填的;
客户端需要忽略无法识别的响应参数,应避免对值的大小做出限制,需要接收授权服务器返回的访问令牌的任何大小。
6.根据权利要求1所述的一种基于HTTP协议的权限认证控制方法,其特征在于,步骤5中,
如果访问令牌请求有效且已授权,则授权服务器发出访问令牌和可选的刷新令牌;如果请求失败,客户端验证无效,授权服务器返回一个错误响应;
S5.1成功响应:
授权服务器发出访问令牌和可选的刷新令牌,并通过添加以下参数来构建响应状态为200的HTTP响应实体正文;
access_token必需的,授权服务器发布的访问令牌;
token_type必需的,发布的令牌类型;
expires_in推荐的,表示访问令牌的生存时间;
refresh_token可选的,刷新令牌,可用于获取新令牌;
scope可选的,如果与客户端请求的范围相同则可选,否则必填;
参数包含在HTTP响应的实体主体中,使用“application/json”媒体类型,这些参数被序列化为JavaScript的对象表达,通过在顶层级别中添加每个参数来构建结构,参数名称和字符串值作为JSON字符串包含在内,参数值在JSON串内的编号顺序无关紧要,并且每次请求都有可能不同;
授权服务器必须包含HTTP的“Cache-Control”返回头,值为“no-sotre”,其他敏感信息的响应,需要添加“Pragma”的响应头,值为“no-cache”;
S5.2错误响应:
授权服务器以HTTP 400来响应状态码,包括以下参数来构建响应:
error必需的,具体错误代码如下:
invalid_request无效的请求,该请求缺少必需的参数,或者参数格式不正确;
invalid_client客户端身份验证失败,授权服务器可以返回HTTP 401(未经授权)状态码,如果客户端尝试通过“Authorization”放在请求头进行身份验证,授权服务器必须使用HTTP 401状态码进行响应,并且包含“WWW-Authenticate”的响应头部字段来匹配客户端的身份验证;
invalid_grant提供的授权码或刷新令牌为无效、已过期、已吊销,授权请求中使用的URI与重定向不匹配,或已发布的URI是其他客户;
unauthorized_client未经授权的客户,经身份验证的客户端无权使用此客户端授权的类型;
unsupported_grant_type授权服务器不支持的授权授予类型;
invalid_scope请求的范围无效、未知、格式错误或超出了资源所有者授予的范围;
error_description可选的,错误描述;
error_url可选的,一个URI,用于标识具有错误描述的可读内容的网页。
7.据权利要求1所述的一种基于HTTP协议的权限认证控制方法,其特征在于,步骤6中,
S6.1客户端认证:
授权服务器通过与Web应用客户端建立凭证来对客户端进行身份验证,授权服务器鼓励客户端使用比传统密码等验证方式强大的身份验证手段,Web应用客户端必须确保客户端密码和其他客户端机密性的证书;
授权服务器不得发布客户端密码或其他客户端凭据到本机应用程序或基于用户代理的应用程序客户端;
如果无法进行客户端身份验证,则授权服务器采用其他方式来验证客户的身份,通过要求注册客户端重定向URI或邀请资源所有者确认身份,一个有效的重定向URI不足以验证客户端的身份在请求资源所有者授权时,但可以用来防止在以后向假冒客户提供凭据获得资源所有者的授权;
S6.2访问令牌
访问令牌凭证在运输和存放时必须保密,并且仅在授权服务器,资源服务器之间共享访问令牌对其有效,并且访问令牌所针对的客户端发布,访问令牌凭证只能使用TLS传输,
使用隐式授予类型时,将传输访问令牌URI片段中的内容,可以将其暴露给未经授权的各方;
授权服务器必须确保访问令牌不能为生成,修改或猜测以通过以下方式产生有效的访问令牌未经授权的各方;
客户端应该以最小范围请求访问令牌必要的,授权服务器应采用客户端身份选择如何遵守要求的范围时应考虑在内,并且可以发行权限少于请求权限的访问令牌;
S6.3刷新令牌
授权服务器可以向Web应用程序发布刷新令牌客户端和本机应用程序客户端;
刷新令牌在运输和存储时必须保持机密,并且仅在授权服务器和客户端之间共享刷新令牌已发行,授权服务器必须维护刷新令牌与该客户端所绑定的客户端之间的绑定发布,刷新令牌必须仅使用TLS进行传输;
授权服务器必须验证刷新之间的绑定只要客户端身份可以是令牌和客户端身份已验证,如果无法进行客户端身份验证,则授权服务器应该部署其他手段来检测刷新令牌滥用,
先前的刷新令牌无效但由授权服务器保留,如果刷新令牌是遭到攻击者攻击,随后被攻击者和合法客户端,其中之一将显示无效的刷新令牌,它将通知违规的授权服务器;
S6.4授权码
授权代码的传输应通过安全的方式进行频道,并且客户端应要求将TLS及其重定向URI,自从授权代码是通过用户代理重定向传输的,它们可能会通过用户代理历史记录和HTTP进行披露引荐来源标头;
授权代码用作纯文本承载凭据,用于验证在授予了授权的资源所有者授权服务器与返回到服务器的资源所有者相同客户来完成该过程,因此,如果客户依靠自己的资源所有者身份验证的授权代码,客户端重定向端点必须要求使用TLS;
授权码必须是短期的且只能使用一次,如果授权服务器观察到多次尝试交换访问令牌的授权码,授权服务器应该尝试根据以下条件撤销所有已授予的访问令牌泄露的授权码,
如果客户端可以通过身份验证,则授权服务器必须对客户端进行身份验证,并确保授权码为发行给相同的客户。
8.一种存储介质,其特征在于,所述存储介质中存储有一种基于HTTP协议的权限认证控制的程序,CPU在执行所述程序时实现如权利要求1-7任一所述的一种基于HTTP协议的权限认证控制方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110941493.9A CN113645247A (zh) | 2021-08-17 | 2021-08-17 | 一种基于http协议的权限认证控制方法及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110941493.9A CN113645247A (zh) | 2021-08-17 | 2021-08-17 | 一种基于http协议的权限认证控制方法及存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN113645247A true CN113645247A (zh) | 2021-11-12 |
Family
ID=78422261
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110941493.9A Pending CN113645247A (zh) | 2021-08-17 | 2021-08-17 | 一种基于http协议的权限认证控制方法及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN113645247A (zh) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114650183A (zh) * | 2022-04-11 | 2022-06-21 | 远景智能国际私人投资有限公司 | 资源管理方法、装置、服务器及存储介质 |
CN114710295A (zh) * | 2022-05-05 | 2022-07-05 | 阿波罗智联(北京)科技有限公司 | 令牌更新方法、装置、电子设备和介质 |
CN114978675A (zh) * | 2022-05-20 | 2022-08-30 | 辽宁华盾安全技术有限责任公司 | 一种访问认证方法、装置、电子设备及存储介质 |
CN116257827A (zh) * | 2023-02-28 | 2023-06-13 | 国家工业信息安全发展研究中心 | 一种句柄系统与信息系统间用户身份认证共用方法及系统 |
CN117456646A (zh) * | 2023-11-23 | 2024-01-26 | 江苏南北木屋文化科技有限公司 | 一种基于物联网的智能木屋门禁验证方法及系统 |
CN117544378A (zh) * | 2023-11-21 | 2024-02-09 | 广州方舟信息科技有限公司 | 一种授权管理方法、装置、设备及存储介质 |
WO2024065453A1 (zh) * | 2022-09-29 | 2024-04-04 | 北京小米移动软件有限公司 | 资源调用方法及装置 |
CN116257827B (zh) * | 2023-02-28 | 2024-07-09 | 国家工业信息安全发展研究中心 | 一种句柄系统与信息系统间用户身份认证共用方法及系统 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130007846A1 (en) * | 2011-07-01 | 2013-01-03 | Telefonaktiebolaget L M Ericsson (Publ) | Methods and Arrangements for Authorizing and Authentication Interworking |
US20180337784A1 (en) * | 2017-05-19 | 2018-11-22 | Intuit Inc. | Coordinating access authorization across multiple systems at different mutual trust levels |
CN111327582A (zh) * | 2019-08-22 | 2020-06-23 | 刘高峰 | 一种基于OAuth协议的授权方法、装置及系统 |
CN113259357A (zh) * | 2021-05-21 | 2021-08-13 | 浪潮卓数大数据产业发展有限公司 | 一种基于OAuth2的单点登录方法 |
-
2021
- 2021-08-17 CN CN202110941493.9A patent/CN113645247A/zh active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130007846A1 (en) * | 2011-07-01 | 2013-01-03 | Telefonaktiebolaget L M Ericsson (Publ) | Methods and Arrangements for Authorizing and Authentication Interworking |
US20180337784A1 (en) * | 2017-05-19 | 2018-11-22 | Intuit Inc. | Coordinating access authorization across multiple systems at different mutual trust levels |
CN111327582A (zh) * | 2019-08-22 | 2020-06-23 | 刘高峰 | 一种基于OAuth协议的授权方法、装置及系统 |
CN113259357A (zh) * | 2021-05-21 | 2021-08-13 | 浪潮卓数大数据产业发展有限公司 | 一种基于OAuth2的单点登录方法 |
Non-Patent Citations (1)
Title |
---|
D.HARDT: "The OAuth 2.0 Authorization Framework", 《THE OAUTH WORKING GROUP》 * |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114650183A (zh) * | 2022-04-11 | 2022-06-21 | 远景智能国际私人投资有限公司 | 资源管理方法、装置、服务器及存储介质 |
CN114710295A (zh) * | 2022-05-05 | 2022-07-05 | 阿波罗智联(北京)科技有限公司 | 令牌更新方法、装置、电子设备和介质 |
CN114978675A (zh) * | 2022-05-20 | 2022-08-30 | 辽宁华盾安全技术有限责任公司 | 一种访问认证方法、装置、电子设备及存储介质 |
CN114978675B (zh) * | 2022-05-20 | 2023-06-20 | 辽宁华盾安全技术有限责任公司 | 一种访问认证方法、装置、电子设备及存储介质 |
WO2024065453A1 (zh) * | 2022-09-29 | 2024-04-04 | 北京小米移动软件有限公司 | 资源调用方法及装置 |
CN116257827A (zh) * | 2023-02-28 | 2023-06-13 | 国家工业信息安全发展研究中心 | 一种句柄系统与信息系统间用户身份认证共用方法及系统 |
CN116257827B (zh) * | 2023-02-28 | 2024-07-09 | 国家工业信息安全发展研究中心 | 一种句柄系统与信息系统间用户身份认证共用方法及系统 |
CN117544378A (zh) * | 2023-11-21 | 2024-02-09 | 广州方舟信息科技有限公司 | 一种授权管理方法、装置、设备及存储介质 |
CN117456646A (zh) * | 2023-11-23 | 2024-01-26 | 江苏南北木屋文化科技有限公司 | 一种基于物联网的智能木屋门禁验证方法及系统 |
CN117456646B (zh) * | 2023-11-23 | 2024-05-07 | 江苏南北木屋文化科技有限公司 | 一种基于物联网的智能木屋门禁验证方法及系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN113645247A (zh) | 一种基于http协议的权限认证控制方法及存储介质 | |
Hardt | The OAuth 2.0 authorization framework | |
Hardt | Rfc 6749: The oauth 2.0 authorization framework | |
US9961072B2 (en) | Delegating authorizations | |
EP1427160B1 (en) | Methods and systems for authentication of a user for sub-locations of a network location | |
JP5926441B2 (ja) | マルチパーティシステムにおける安全な認証 | |
KR101459802B1 (ko) | 암호화 증명의 재검증에 기반을 둔 인증 위임 | |
CN102655494B (zh) | 一种基于saml的单点登录模式设计的认证平台 | |
CN111901346B (zh) | 一种身份认证系统 | |
CN109672675B (zh) | 一种基于OAuth2.0的密码服务中间件的WEB认证方法 | |
CN106209749A (zh) | 单点登录方法及装置、相关设备和应用的处理方法及装置 | |
US20080086634A1 (en) | Techniques for using AAA services for certificate validation and authorization | |
CN106295394A (zh) | 资源授权方法及系统和授权服务器及工作方法 | |
US20110030043A1 (en) | Devolved authentication | |
CN108964885A (zh) | 鉴权方法、装置、系统和存储介质 | |
TW201019683A (en) | Access control system and method based on hierarchical key, and authentication key exchange thereof | |
JP2016521029A (ja) | セキュリティ管理サーバおよびホームネットワークを備えるネットワークシステム、およびそのネットワークシステムにデバイスを含めるための方法 | |
US20170104748A1 (en) | System and method for managing network access with a certificate having soft expiration | |
Morii et al. | Research on integrated authentication using passwordless authentication method | |
EP1639782B1 (en) | Method for distributing passwords | |
Connect | What is OpenID Connect? | |
Bhargava et al. | Privacy in cloud computing through identity management | |
EP2359525B1 (en) | Method for enabling limitation of service access | |
CN114640472A (zh) | 一种受保护资源数据的获取方法、装置和统一开放平台 | |
KR20030075809A (ko) | 멀티도메인으로 구성된 웹사이트에서 단일 로그인에 의한접속자 인증 방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |