📅  最后修改于: 2020-11-03 10:25:50             🧑  作者: Mango
OAuth是一种开放式授权协议,该协议允许通过在HTTP服务(例如Facebook,GitHub等)上启用客户端应用程序来访问资源所有者的资源。它允许不使用其凭据将一个站点上存储的资源共享到另一个站点。它使用用户名和密码令牌代替。
OAuth 2.0由IETF OAuth工作组开发,于2012年10月发布。
您可以使用OAuth 2.0从另一个应用程序读取用户的数据。
它提供了针对Web,桌面应用程序和移动设备的授权工作流程。
它是使用授权代码且不与用户凭据交互的服务器端Web应用程序。
OAuth 2.0是一种简单的协议,允许在不共享密码的情况下访问用户的资源。
它提供用户代理流,以使用脚本语言(例如JavaScript)运行客户端应用程序。通常,浏览器是用户代理。
它使用令牌而不是使用令牌的凭据来访问数据,并将数据存储在用户的在线文件系统中,例如Google Docs或Dropbox帐户。
OAuth 2.0是一种非常灵活的协议,它依赖于SSL(安全套接字层,可确保Web服务器和浏览器之间的数据保持私有)来保存用户访问令牌。
OAuth 2.0依赖于SSL,该SSL用于确保加密行业协议,并用于确保数据安全。
它允许对用户数据的有限访问,并允许在授权令牌到期时进行访问。
它具有无需共享个人信息即可为用户共享数据的能力。
它更易于实现并提供更强大的身份验证。
如果您在规范的末尾添加更多扩展,它将产生各种各样的不可互操作的实现,这意味着您必须为Facebook,Google等编写单独的代码段。
如果您喜欢的站点连接到中央集线器并且中央帐户被黑,那么这将在多个站点而不是仅一个站点上造成严重影响。
在本章中,我们将讨论OAuth 2.0的体系结构样式。
步骤1-首先,用户使用客户端应用程序(例如Google,Facebook,Twitter等)访问资源。
步骤2-接下来,在注册重定向URI(统一资源标识符)期间,将向客户端应用程序提供客户端ID和客户端密码。
步骤3-用户使用身份验证应用程序登录。客户端ID和客户端密码对于授权服务器上的客户端应用程序是唯一的。
步骤4-认证服务器使用授权码将用户重定向到重定向统一资源标识符(URI)。
步骤5-用户访问客户端应用程序中位于重定向URI的页面。
步骤6-将向客户端应用程序提供身份验证代码,客户端ID和客户端密码,并将它们发送到授权服务器。
步骤7-身份验证应用程序将访问令牌返回到客户端应用程序。
步骤8-一旦客户端应用程序获得访问令牌,用户便开始使用客户端应用程序访问资源所有者的资源。
OAuth 2.0具有各种概念,下表对此进行了简要说明。
Sr.No. | Concept & Description |
---|---|
1 | Terminology
OAuth provides some additional terms to understand the concepts of authorization. |
2 | Web Server
Web server delivers the web pages and uses HTTP to serve the files that forms the web pages to the users. |
3 | User-Agent
The user agent application is used by client applications in the user’s device, which acts as the scripting language instance. |
4 | Native Application
Native application can be used as an instance of desktop or mobile phone application, which uses the resource owner password credentials. |
当客户端是资源所有者时,或者当授权范围限于客户端控制下的受保护资源时,客户端凭据可以用作授权授予。
客户端仅在客户端凭据的帮助下请求访问令牌。
客户端凭证授权流用于获取访问令牌以授权API请求。
使用客户端凭据授权,获取的访问令牌仅授予客户端应用程序搜索和获取目录文档的权限。
下图描述了客户端凭证流。
上图所示的流程包括以下步骤-
步骤1-客户端向授权服务器进行身份验证,并从令牌端点请求访问令牌。
步骤2-授权服务器对客户端进行身份验证,并提供访问令牌(如果该令牌有效且已授权)。
下表列出了客户端凭据的概念。
Sr.No. | Concept & Description |
---|---|
1 | Obtaining End-User Authorization
The authorization end point is typically URI on the authorization server in which the resource owner logs in and permits to access the data to the client application. |
2 | Authorization Response
The authorization response can be used to get the access token for accessing the owner resources in the system using the authorization code. |
3 | Error Response and Codes
The authorization server responds with a HTTP 400 or 401 (bad request) status codes, if an error occurs during authorization. |
访问令牌是标识用户,应用程序或页面的字符串。令牌包括诸如令牌何时到期以及哪个应用创建了该令牌之类的信息。
首先,必须从API控制台获取OAuth 2.0客户端凭据。
然后,客户端从授权服务器请求访问令牌。
它从响应中获取访问令牌,并将该令牌发送到您希望访问的API。
您必须首先将用户发送到授权端点。以下是虚拟请求的示例
https://publicapi.example.com/oauth2/authorize?client_id=your_client_id&redirect_uri=your_url
&response_type=code
以下是参数及其说明。
client_id-应将其设置为应用程序的客户端ID。
redirect_uri-应该设置为URL。请求被授权后,用户将被重定向回。
response_type-它可以是代码或令牌。该代码必须用于服务器端应用程序,而令牌必须用于客户端应用程序。在服务器端应用程序中,可以确保安全保存机密。
下表列出了客户端凭据的概念。
Sr.No. | Concept & Description |
---|---|
1 | Authorization Code
The authorization code allows accessing the authorization request and grants access to the client application to fetch the owner resources. |
2 | Resource Owner Password Credentials
The resource owner password credentials include only one request and one response, and is useful where the resource owner has a good relationship with the client. |
3 | Assertion
Assertion is a package of information that makes the sharing of identity and security information across various security domains possible. |
4 | Refresh Token
The refresh tokens are used to acquire a new access tokens, which carries the information necessary to get a new access token. |
5 | Access Token Response
Access token is a type of token that is assigned by the authorization server. |
6 | Access Token Error Response Codes
If the token access request, which is issued by the authorization server is invalid or unauthorized, then the authorization server returns an error response. |
客户端向资源服务器提供访问令牌,以访问受保护的资源。资源服务器必须验证并验证访问令牌是否有效且尚未过期。
有两种发送证书的标准方法-
承载令牌-访问令牌只能作为授权HTTP标头中的后备选项放置在POST请求正文或GET URL参数中。
它们包含在授权标头中,如下所示-
Authorization: Bearer [token-value]
例如-
GET/resource/1 HTTP /1.1
Host: example.com
Authorization: Bearer abc...
MAC-使用请求的元素计算密码消息认证码(MAC),并将其发送到授权标头。接收到请求后,资源所有者将对MAC进行比较和计算。
下表显示了访问受保护资源的概念。
Sr.No. | Concept & Description |
---|---|
1 | Authenticated Requests
It is used to get the authorization code token for accessing the owner resources in the system. |
2 | The WWW-Authenticate Response Header Field
The resource server includes the “WWW-Authenticate” response header field, if the protected resource request contains an invalid access token. |
可以通过两种方式定义访问令牌类型-
通过在访问令牌类型的注册表中进行注册。
通过使用唯一的绝对URI(统一资源标识符)作为其名称。
参数名称必须遵守参数名称ABNF(增强型Backus-Naur形式是基于Backus-Naur形式的元语言,由其自身的语法和派生规则组成),并且参数值的语法必须定义明确。
param-name = 1* name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
可以通过“ grant_type”参数为新的授权授予类型分配一个不同的绝对URI,以供使用。如果扩展授权类型需要其他令牌端点参数,则必须在OAuth参数注册表中注册。
response-type = response-name *(SP response-name)
response-name = 1* response-char
response-char = "_" / DIGIT / ALPHA
如果响应类型具有一个或多个空格字符(其中值的顺序无关紧要,并且只能注册一个值的顺序),则将其作为空格分隔的值列表进行比较。
如果扩展错误代码使用的扩展名是已注册的访问令牌或已注册的端点参数,则必须注册该扩展名错误代码。错误代码必须遵守错误ABNF(增强的Backus-Naur格式),并且在可能的情况下,应以标识它的名称作为前缀。
error = 1 * error_char
error-char = %x20-21 / %x23-5B / 5D-7E
IANA代表网际甲ssignedÑumbers其提供有关相关于R表情甲uthentication d IAL我N个U SER小号ervice(RADIUS)登记值的信息的uthority。
IANA包括以下注意事项-
OAuth访问令牌由具有所需规范的专家注册。如果他们对注册感到满意,则只有他们才会发布规范。注册请求将被发送到@ ietf.org进行主题审查(“访问令牌类型的请求:示例”)。专家将在请求后的14天内拒绝或接受该请求。
注册模板包含以下规范-
类型名称-这是请求的名称。
令牌端点响应参数-附加访问令牌响应参数将分别在OAuth参数注册表中注册。
HTTP身份验证方案-HTTP身份验证方案可用于通过使用访问令牌对资源进行身份验证。
变更控制器-将标准跟踪RFC的州名称指定为“ IETF”,对于其他名称,请使用负责方的名称。
规范文档-规范文档包含可用于检索文档副本的参数。
OAuth参数注册表包含专家对授权端点请求或响应,令牌端点请求或响应的注册,具有所需的规范。注册请求将发送给专家,如果他们对注册感到满意,则他们将发布规范。
注册模板包含上述OAuth访问令牌类型注册表部分中定义的规范,例如类型名称,更改控制器和规范文档,以下规范除外-
参数使用位置-它指定参数的位置,例如授权请求或响应,令牌请求或响应。
下表显示了包含初始内容的OAuth参数注册表-
Sr.No. | Parameter Name & Usage Location | Change Controller | Specification Document |
---|---|---|---|
1 |
client_id authorization request, token request |
IETF | RFC 6749 |
2 |
client_secret token request |
IETF | RFC 6749 |
3 |
response_type authorization_request |
IETF | RFC 6749 |
4 |
redirect_uri authorization request, authorization |
IETF | RFC 6749 |
5 |
scope authorization request or response, token request or response |
IETF | RFC 6749 |
6 |
state authorization request or response |
IETF | RFC 6749 |
7 |
code token request, authorization response |
IETF | RFC 6749 |
8 |
error_description authorization response, token response |
IETF | RFC 6749 |
9 |
error_uri authorization response, token response |
IETF | RFC 6749 |
10 |
grant_type token request |
IETF | RFC 6749 |
11 |
access_token authorization response, token response |
IETF | RFC 6749 |
12 |
token_type authorization response, token response |
IETF | RFC 6749 |
13 |
expires_in authorization response, token response |
IETF | RFC 6749 |
14 |
username token request |
IETF | RFC 6749 |
15 |
password token request |
IETF | RFC 6749 |
16 |
refresh_token token request, token response |
IETF | RFC 6749 |
这可用于定义OAuth授权端点响应类型注册表。响应类型由具有所需规范的专家注册,如果他们对注册感到满意,则只有他们才能发布规范。注册请求将发送到@ ietf.org进行审核。专家将在请求后的14天内拒绝或接受该请求。
注册模板包含上述OAuth访问令牌类型注册表部分中定义的规范,例如类型名称,更改控制器和规范文档。
下表显示了包含初始内容的授权端点响应类型注册表。
Sr.No. | Parameter Name | Change Controller | Specification Document |
---|---|---|---|
1 | code | IETF | RFC 6749 |
2 | token | IETF | RFC 6749 |
这可以用来定义OAuth Extensions Error Registry。错误代码以及协议扩展(例如授权类型,令牌类型等)均由具有所需规范的专家注册。如果他们对注册感到满意,那么他们将发布规范。注册请求将发送到@ ietf.org,以进行主题审查(“请求错误代码:示例”)。专家将在请求后的14天内拒绝或接受该请求。
注册模板包含上述OAuth访问令牌类型注册表部分中定义的规范,例如更改控制器和规范文档,但以下规范除外-
错误名称-这是请求的名称。
错误使用位置-指定错误的位置,例如授权码授予错误响应,隐式授予响应或令牌错误响应等,它们指定可以在何处使用错误。
相关协议扩展-您可以使用协议扩展,例如扩展授权类型,访问令牌类型,扩展参数等。