oauth2协议简介

最新推荐文章于 2024-06-17 11:38:31 发布

80pc

最新推荐文章于 2024-06-17 11:38:31 发布

阅读量385

点赞数

oauth2

OAuth 2.0是用于授权的行业标准协议。OAuth 2.0专注于客户机开发人员的简单性，同时为web应用程序、桌面应用程序、移动电话和客厅设备提供特定的授权流。本规范及其扩展正在IETF OAuth工作组中开发

1.1 角色

resource owner：有权授予访问权的实体。当这个实体是一个人是，它指的是最终用户
resource server: 这个服务持有受保护的资源，能够接收以及使用访问令牌响应受保护的资源
client: 代表资源所有者及其授权发出受保护资源请求的应用程序。客户端的目标并不意味着任何特定的实现特征。(例如，无论这个应用程序运行在服务器，台式机或其他设备)
authorization server: 授权服务器发行accessToken给client，在成功认证资源拥有者并获取授权后。

授权服务器和资源服务器的交互不在本规范的范畴内。授权服务器也可能是资源服务器，也可能是单独的实体。一个单独的授权服务器可能会处理多个资源服务的accessToken

1.2 协议流程

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+
     
                Figure 1: Abstract Protocol Flow

图1中OAuth2.0协议的抽象流程，描述四个角色之间的交互流程，并包含下面四个步骤：

(A) client 请求资源拥有者的授权。这个授权请求可以由资源拥有者直接发起，或者间接由授权服务器作为中介发起。
(B) client 接收的授权，是代表着资源拥有者授权的票据。使用这个规范中四种之一的授权类型或者使用扩展的授权类型。
授权类型依赖client请求授权的方法，并且这个方法被授权服务器支持。
© client 请求授权服务器认证的accessToken，并且提供授权信息。
(D) 授权服务认证客户端，并且判断授权是否正确。如果正确则发行accessTokne
(E) 客户端从资源服务请求受保护的资源，并且通过提供accessToken进行认证
(F) 资源服务器检查accessToken是否正确，如果正确则为请求提供服务。

client获取从资源服务器获取授权的首选方法(步骤(A)和(B)描述的)，是通过授权服务器作为中间，在第 4.1 断中图标3 中有图解说明.

1.3 权限授权

权限授权是代表资源拥有者授权的票据(访问它的受保护资源)，由client使用来获取accessToken。
本规范定义了四种授权方式：授权码模式、隐式授权模式(简化模式)、密码模式、客户端模式。以及可定义其他类型的可扩展机制。

1.3.2 授权码模式

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zlUsHbBO-1597934404900)(images/AuthrizationCode.png)]

授权码通过使用授权服务作为client和资源拥有者的中介，来获取授权码。
client将资源拥有者定向到授权服务器，而不是向资源拥有者直接请求授权(如在[RFC2616]中的定义、通过他的客户端代理)。
依次使用授权码将资源拥有者引导回客户端。

在使用授权码将资源拥有者引导会客户端之前，授权服务器认证资源拥有者并且获取授权信息。
因为资源拥有者仅仅通过授权服务器认证，资源拥有者的票据从不会分享给client。

授权码提供了一些重要的安全能力，例如认证客户端的能力，以及将访问令牌直接传输给客户端，
而不是通过资源拥有的客户端代理传递，或者暴露给其他人包括资源的拥有者

1.3.3 隐式授权模式

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Uw3MfHl8-1597934404903)(images/Implicit.png)]

隐式授权是简化了的授权码流程适用于在在浏览器使用脚本语言(例如JavaScript)实现的客户端。
在隐式流程中，客户端直接被发行访问令牌(作为资源拥有者的授权结果),并不是给客户端发行一个授权码。

这种授权类型是隐式的，因为没有中间凭证(例如授权码)的发行(随后用于获取访问令牌)
在隐式授权流程中当发行一个访问令牌，授权服务并不会认证客户端。在一些案例中，客户端的身份可以通过用于传递访问令牌的重定向URI验证。
访问令牌可能会被暴露给资源拥有者或者其他应用通过访问资源拥有者的客户端代理。

隐式授权提高一些客户端的响应能力和效率(例如浏览器实现的客户端),由于它减少了获取访问令牌所需往返流程中的几个步骤。
然而，使用隐式授权带来的这种便利将会增加了安全隐患，例如在第10.3章和第10.16章描述的，尤其是当授权码模式是可用的时候

1.3.3 密码模式

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KukLIalv-1597934404904)(images/Password.png)]

资源拥有者密码票据(即，用户名和密码)可以被直接作为授权模式获取访问令牌。
票据只应被用于高度信任的客户端和资源服务器(例如客户端是运行系统的一部分设备或者拥有高度权限的应用),
并且在其他授权方式不可用时(例如授权码模式).

即使这种授权方式要求直接获取资源拥有者的凭证，这种资源拥有者的凭证用于单个请求并交换访问令牌。
这种授权模式，通过交换具有长期访问令牌或刷新令牌的凭证，可以消除客户端存储资源拥有者凭的证以供将来使用。

1.3.4 客户端模式

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-15N755cR-1597934404907)(images/ClientCredentials.png)]

这种客户端凭据(或者其他形式的客户端认证)可以作为授权模式使用，这种授权范围限于被保护的资源由客户端控制时,或
受保护的资源被授权服务器事先安排的服务器。
客户端凭证作为授权模式，一般当客户端代表自己行事时(客户端同样是资源的拥有者)，
或者它请求访问的受保护资源基于授权服务器事先安排好的认证。

1.4 访问令牌

访问令牌是用于访问受保护资源的凭证。访问令牌是一个代表发行给客户端授权的字符串。这个字符串通常对客户端是不透明的。
令牌代表特定的范围和访问的持续时间，资源拥有者授权，并且由资源服务和授权服务强制实施。

令牌可以表示一个用于检测认证信息的标识符或包含可认证方式的所有授权信息(即，令牌字符串由一些数据和签名组成)。
额外的授权凭证，超过指定范围，可能是必须的一遍客户端使用。

访问凭证提供了抽象层，替换为不同的授权结构(例如用户名和密码)带有可被资源服务理解的单个凭证。
这种抽象可以使发行访问凭证能够比用来获取认证的授权具有更多的限制，同样小区资源服务器了解各种授权方法的需要。

基于资源服务安全需要，访问令牌可以有多个格式、结构和使用的方法(例如，密码属性)。
访问令牌的属性和用来获取受保护资源的方法超过了规范的范围，并且由公司的规范定义例如[RFC6750]。

1.5 刷新令牌

刷新令牌是用来获取访问令牌的凭证。刷新令牌是由授权服务发行的，用来获取一个新的访问令牌当当前的访问令牌失效或过期时，
或者获取额外的相同或范围更窄的访问令牌(可能比资源拥有者授权有更短的声明周期或更少的权限)。发行刷新令牌是可选，具体由授权服务决定。
如果授权服务发行访问令牌，他将包含在发放访问令牌时(即在图1中的步骤(D))

刷新令牌是一个表示资源拥有者给客户端授权给予的字符串。这个字符串通常是对客户端不透明的。
刷新令牌描述一个用来检索认证信息的标识符。不像访问令牌，刷新令牌仅用于授权服务器并且永远不会发送给资源服务。

+--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+

               Figure 2: Refreshing an Expired Access Token

图2描述的流程如下几个步骤：

(A) 客户端通过向授权服务进行身份认证并且提供授权来获取访问令牌
(B) 授权服务器认证客户端并且验证授权，如果正确，发行一个访问令牌和刷新令牌
© 客户端通过提供访问令牌向资源服务器发起资源请求
(D) 资源服务验证访问令牌，如果正确，服务请求。
(E) 步骤©和(D)重复执行一旦访问令牌过期.如果客户端识别到访问令牌过期,跳到步骤(G);否则，他将发起另外一个受保护资源的请求。
(F) 当访问令牌不正确时，资源服务返回一个不正确令牌的错误
(G) 客户端通过向授权服务进行身份认证并提供刷新令牌来获取一个新的访问令牌。
(H) 授权服务器认证客户端并且验证刷新令牌是否正确，如果正确，发行一个新的访问令牌(并且可选择发行一个新的刷新令牌)

步骤©,(D),(E),和(F) 不在本规范的范围内，如第7章所述

1.6 TLS版本

每当在此规范中使用传输层安全性。适配的TLS版本(或多个版本)会随着时间推移而变化,基于广泛的应用和已知安全性的漏洞。
在本文档正在书写时，TLS版本1.2是最新的版本，但是有很少的部署量并且也许还没有准备好用于实现。
TLS 1.0是目前使用最广泛的部署版本，提供了最广泛的互通性。

实现也可以根据他们的安全需求提供额外的传输层安全性策略。

1.7 http重定向

规范大量的使用了http重定向，在客户端或授权服务重定向资源拥有者的客户端代理到另一个地址。
虽然此规范中的例子展示了http 302 状态码的使用，任何其他通过客户端代理来完成这些重定向的可用方法是允许的，并且视为一个实现细节

1.8 可操作性

OAuth 2.0 通过定义明确的安装属性提供丰富的授权框架。然而，作为一个带有很多可选组件的丰富、高扩展性的框架，
很可能会产生大量的不可互通的实现
另外，此规范遗留了一些必需组件，部分或全部没有定义(例如，客户端的注册能力，授权服务器容量，端点发现能力)
没有这些组件，客户端必须依赖一个指定的授权服务器和资源服务器进行手动或专门的配置，以进行交互。

1.9 符号约定

在此规范中的关键字 “必须” “必须不” “必备” “应” “最好不要” “应该” “不应该” “建议” “可以” “可选的”
应该按照[RFC 2119]的描述进行说明

本规范使用增强Backus-Naur形式（ABNF）
[RFC5234]的符号。另外，规则URI引用是
包括在“统一资源标识符（URI）：通用语法”中
[RFC3986]。

在某种意义上，应理解某些与安全性相关的术语
在[RFC4949]中定义。这些术语包括但不限于
“攻击”，“身份验证”，“授权”，“证书”，“机密”，“凭证”，“加密”，“身份”，“签名”，“签名”，“信任”，“验证”和“验证”。

除非有特殊说明，所有的协议参数名字和值都是大小写敏感的

2 客户端注册

在发起此协议前，客户端通过授权服务器注册。意思是客户端通过授权服务器进行注册超过了此规范的范畴，但是通常涉及最终用户通过html注册表表格的交互。

客户端注册并不需要客户端和授权服务器之前的直接交互。当授权服务支持客户端注册时，注册可以依赖其他方法来建立信任，并且获取必须要的客户端属性(例如。重定向URI，客户端类型)
例如，注册可以通过自我发行或第三方发行来完成，或者授权服务通过使用可信任通道来运行客户端发现。

当注册客户端是，客户端开发者应该：

如Section 2.1 描述的一样，明确客户端的类型
如Section 3.1.2 描述的一样，提供客户端重定向URIs
提供任何其他授权服务必需的信息(例如，应用名，网址，描述，logo图片，接受法律条款)

2.1. 客户端类型

OAuth定义了两种客户端类型，基于他们安全的通过授权服务器认证的能力(即，保持他们的客户端凭证的保密的能力)

机密的
客户端能够保持他们的凭证的机密性(例如，客户端实现了一个安全服务来限制客户端凭证的访问)，
或者能通过其他的方式保护客户端授权

公开的
客户端不能够保持他们的凭证的机密性(例如，客户端在资源拥有者的设备上运行，比如一个按照的原生应用或基于浏览器的应用)，
并且不能通过其他的方式保护客户端授权

客户端类型的设计基于授权服务器的安全认证的定义和它可接受客户端票据的暴露级别。
授权服务器不应该假设客户端的类型。

客户端可以实现为一组分布式组件，每个组件都支持不同的客户端类型和安全上下文(比如分布式客户端有基于服务器机密组件，和基于浏览器的公开组件)
如果授权服务器不提供这些客户端类型的支持或不提供有关注册的指导，这些客户端应该将注册为不同的客户端。

本规范围绕着一下几种客户端类型设计的：

网络应用(web application)

网络应用是一个运行为web服务器上的机密客户端。资源拥有者通过html用户接口呈现在资源拥有者使用的客户端代理设备上访问客户端。
客户端凭证以及任何访问令牌发行给客户端存储在web服务器并且不会暴露给资源拥有者。

基于用户代理的应用

基于用户代理的应用是公开的客户端，其中客户端code从web服务器下载并在用户代理的设备上执行(例如浏览器)被资源拥有者使用。
协议数据和凭证易于资源拥有者访问(并经常可见)。由于此类应用驻留在客户端代理中，因为他们在请求授权认证时他们可以无缝的访问客户端代理。

本机应用

原生应用是一个安装并执行在资源拥有者所使用的的设备上。协议数据和凭证对资源拥有者是可以访问。
假定包含在应用中的客户端凭证都是可以提取的。另一方面，动态的发行凭证例如访问令牌或刷新令牌可以获取可接受的保护级别。
至少，这些凭证是不被可能与之交互的敌对服务器攻击。在一些平台中，这些凭证可能被运行在同一个设备上的其他应用保护。

2.2 客户端标识(Client Identifier)

授权服务器向注册的客户端发行客户端标识–一个代表客户端提供的注册信息的唯一的字符串。
客户端标识不是一个机密。它暴露给资源拥有者并且不能单独用户客户端认证。
客户端标识对于授权服务器是唯一的。本规范并没有规定客户端标识。客户端应用避免假设标识的长度。
授权服务器应用记录发行的任何标识的长度。

2.3. 客户端认证

如果客户端类型是机密的，客户端和授权服务器创建一个客户端认证访的方法，适配授权服务器安全需求。
授权服务器可以接收任何格式的满足安全需求的客户端认证。

机密的客户端通常发行(或创建)一组客户端凭证用于在授权服务器认证(例如，密码，公开/私有的密钥对)。

授权服务器可以创建一个客户端认证方法通过公开的客户端。然而，授权服务器不能依赖公开的客户端认证用于识别这个客户端。

一个客户端在每个请求中不能使用多余一个认证的方法。

2.3.1. 客户端密码(Client Password)

拥有客户端密码的客户端可以使用HTTP Basic认证方案如[RFC2617]中定义身份认证方案，以通过授权服务器的认证。
客户端标识使用每个附录B中"application/x-www-form-urlencoded"的编码算法进行编码，并且编码后的值用作用户名。
客户端密码使用相同的算法编码并且用作密码。授权服务器必须支持HTTP Basic authentication方案用于发布了客户端密码的客户端的身份认证。

例如(带有额外的换行符，仅用于显示目的)

```
    Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
```

或者，授权服务器可以支持包含客户端凭证在request-body中，包含以下的参数：

client_id:必须的。客户端标识在Section2.2描述的注册流程中发行给客户端
client_secret:必须的。客户端密码。如果客户端密码是一个空字符串，客户端可以省略这个参数

不建议使用这两个参数在request-body中包含客户端凭证并且应该限制于不能直接使用HTTP Basic authentication方案的客户端(或者其他基于密码的http认证方案)。
参数智能在request-body传输并且不能包含在请求的uri中。

例如，一个刷新访问令牌的请求(Section 6)使用body参数(带有换行符，仅为展示使用):

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

授权服务必须要求使用TLS，如Section1.6中描述的，当使用密码认证发送请求时。
由于客户端授权方法涉及密码,认证服务器必须保护使用它的任何端避免暴力攻击。

2.3.2. 其他认证方法

认证服务可以支持满足其安全需求的任何合适的http授权方案。当使用其他授权方法，认证服务器必须定义一个客户端标识(注册记录)和认证方案的映射

2.4. 未注册的客户端

本规范不会排除使用未注册的客户端。然后，这种客户端的使用超过此规范的范畴并且依赖额外的安全分析和检查其互操作行的影响

80pc

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
oauth2协议简介

oauth2OAuth 2.0是用于授权的行业标准协议。OAuth 2.0专注于客户机开发人员的简单性，同时为web应用程序、桌面应用程序、移动电话和客厅设备提供特定的授权流。本规范及其扩展正在IETF OAuth工作组中开发1.1 角色resource owner：有权授予访问权的实体。当这个实体是一个人是，它指的是最终用户resource server: 这个服务持有受保护的资源，能够接收以及使用访问令牌响应受保护的资源client: 代表资源所有者及其授权发出受保护资源请求的应用程序。客户
复制链接

扫一扫