目录

1.介绍
1.1 角色
1.2 协议流程
1.3 授权模式
1.3.1 授权码模式
1.3.2 简化模式
1.3.3 资源拥有者密码凭证模式
1.3.4 客户端凭证模式
1.4 访问令牌
1.5 刷新令牌
1.6 TLS 版本
1.7 HTTP 重定向
1.8 互相协同操作能力
1.9 符号约定
2.客户端注册
2.1 客户端类型
2.2 客户端标识
2.3 客户端认证
2.3.1 客户端密码
2.3.2 其他认证方式
2.4 取消客户端注册
3.协议端点
3.1 授权端点
3.1.1 响应类型
3.1.2 重定向端点
3.2 令牌端点
3.2.1 客户端认证
3.3 访问令牌范围
4.获取授权
4.1 授权码模式
4.1.1 授权请求
4.1.2 授权响应
4.1.3 访问令牌请求
4.1.4 访问令牌响应
4.2 简化模式
4.2.1 授权请求
4.2.2 访问令牌响应
4.3 资源拥有者密码凭证模式
4.3.1 授权请求和响应
4.3.2 访问令牌请求
4.3.3 访问令牌响应
4.4 客户端凭证模式
4.4.1 授权请求和响应
4.4.2 访问令牌请求
4.4.3 访问令牌响应
4.5 扩展模式
5.分发一个访问令牌
5.1 成功响应
5.2 错误响应
6.刷新一个访问令牌
7.访问受保护资源
7.1 访问令牌类型
7.2 错误响应
8.可扩展性
8.1 定义访问令牌类型
8.2 定义一个新的端点参数
8.3 定义一个新的授权请求类型
8.4 定义一个新的授权端点响应类型
8.5 定义额外的错误码
9.原生应用
10.安全考虑
10.1 客户端认证
10.2 客户端扮演
10.3 访问令牌
10.4 刷新令牌
10.5 授权码
10.6 授权码重定向 URI 操作
10.7 资源拥有者密码凭证
10.8 请求机密性
10.9 确保端点真实性
10.10 凭证猜测攻击
10.11 钓鱼攻击
10.12 跨站请求伪造
10.13 点击劫持
10.14 代码注入和输入校验
10.15 开放重定向器
10.16 在简化流程中扮演资源拥有者滥用访问令牌
11.IANA 考虑
11.1 OAuth 访问令牌类型注册
11.1.1 注册模板
11.2 OAuth 参数注册
11.2.1 注册模板
11.2.2 初始化注册内容
11.3 OAuth 授权端点响应类型注册
11.3.1 注册模板
11.3.2 初始化注册内容
11.4 OAuth2 扩展错误注册
11.4.1 注册模板
引用
规范引用
信息来源引用

1. 介绍**

在传统的客户端-服务器认证模式中，客户端通过使用资源拥有者的凭证来访问位于服务器上访问受限的资源（受保护资源）。为了能让第三方应用访问受限的资源，资源拥有者将自己的凭证共享给第三方。这样会引发以下几个问题和限制:

  • 为了后续的使用第三方应用需要存储资源拥有者的凭证，典型的为一个明文的密码
  • 服务器需要支持密码认证，尽管密码其天生的脆弱性
  • 第三方应用过度的获取资源拥有者的受保护资源的访问权，一旦第三方应用获取了资源拥有者的凭证，在此期间，资源拥有者将没有一点办法来限制其对受保护资源的访问或者只允许其访问受保护资源有限的子集
  • 资源拥有者不能只撤销某个独立的三方应用访问权而不撤销所有第三方应用的访问权，并且必须通过改变第三方密码来做到撤销所有第三方应用的访问权
  • 任何有危害的第三方应用将会导致终端用户的密码和被该密码保护的所有受保护数据被牵连

OAuth 通过引入一个授权层来解决该问题，并且从资源拥有者当中分离出了一个客户端的角色，在 OAuth 当中，客户端对资源的访问请求同时被资源拥有者和资源服务器共同控制，并且会分发一组不同于那些资源拥有者的凭证，来取代使用资源拥有者的凭证访问受保护资源的方式，客户端获取一个访问令牌——表示特定范围、使用期限和其他访问属性的字符 串。在资源拥有者的批准下，授权服务器会为第三方客户端分发访问令牌。客户端使用这个访问令牌来访问部署在资源服务器上的受保护资源。举个例子，一个终端用户（资源拥有者）可以授予一个打印服务（客户端）访问她存储在图片分享服务（资源服务器）上的受保护图片而不需要将她的用户名和密码共享给打印服务。取而代之的是，她直接为一个被图片分享服务（授权服务器）信任的服务器授权，分享服务为打印服务分发有明确指示的凭证（访问令牌）这个规范被设计用在 HTTP 中。OAuth 可以被使用在任何协议之上，而不局限在 HTTP 的范围之内。
OAuth 1.0 协议，是一个小的特别社区小组的成就，被作为一个报告文档进行发布。这个规范的记录建立在 OAuth 1.0 部署经验的基础上，作为额外的使用案例和扩展要求被广泛的收集在 IETF 社区。OAuth 2.0 协议不是向后兼容 OAuth 1.0 的。这两个版本可以在网络中共存，并且可选择同时实现支持这两个版本。然而，在这个文档中，这个规范的目的是新的实现规定支持 OAuth 2.0，同时 OAuth 1.0 仅仅用来支持已存在的部署。OAuth 2.0 协议只是共享了 OAuth 1.0 很少的实现细节。熟悉 OAuth 1.0 的实现者在处理这个文档时不需要任何关于其结构和细节的臆断。

1.1 角色

OAuth 定义了四种角色：
资源拥有者
一个有能力授予受保护资源访问权的实体，当资源拥有者是一个人的时候，它指的是终端用户
资源服务器
部署受保护资源的服务器，有能力接收使用访问令牌请求受保护资源的请求并进行响应
客户端
一个代表受保护资源以及其授权访问受保护资源的应用，这里的术语『客户端』没有暗示任何特殊的实现特征（比如，是否这个应用在服务器上执行，或者在桌面上，或者其他设备）
授权服务器
一个在成功认证资源拥有者并且获取其授权后为客户端分发访问令牌的服务器
授权服务器和资源服务器之间的互操作超出了本规范的范围。授权服务器有可能跟资源服务器是一个服务器或者是分离的两个服务器。一个授权服务可能会为多个资源服务器分发访问令牌。

1.2 协议流程

iShot2020-10-24 11.09.02.png
图 1：抽象的协议流程
抽象的 OAuth 2.0 流程如图 1 描述的在四个角色之间的交互包含下边几个步骤：
（A）客户端向资源拥有者请求授权。这个授权请求可以直接由资源拥有者发起（像展示的那样），或者更可取的是由授权服务器作为中间人间接地发起
（B）客户端接收到一个授权回执，它是一个代表资源拥有者授权的凭证，使用在当前规范中定义的四种授权模式之一或者一个扩展的授权模式来表示。这个授权回执类型依赖客户端在请求授权时使用的方法和授权服务器支持的授权模式
（C）客户端通过在授权服务器上认证并且提交授权回执来请求一个访问令牌
（D）授权服务器对客户端进行认证和校验授权回执，如果合法，然后为其分发一个访问令牌
（E）客户端通过提交访问令牌进行认证来访问资源服务器中受保护的资源
（F）资源服务器对访问令牌进行校验，如果合法，然后为该请求进行服务
这种更可取的客户端从资源拥有者（在步骤（A）和（B）中描述）那里获取授权回执的方法是为了将授权服务器作为一个中间人，这些细节可在章节 4.1 的图 3 中进行寻找

1.3 授权回执

授权回执是一个代表着资源拥有者授权（来访问他的受保护资源）的凭证，它被客户端用来获取访问令牌。这个规范定义了四种授权模式——授权码模式，简化模式，资源拥有者密码凭证，和客户端凭证——还有一个可扩展的机制用来定义额外的模式

1.3.1 授权码模式

在客户端和资源拥有者之间，授权服务器被作为一个中间人用来获取授权码。取代直接从资源拥有者那里请求授权，客户端指引资源拥有者到达授权服务器（通过资源拥有者的用户代理，该规范在『RFC2616』中定义），授权服务器在指引资源拥有者带着授权码返回到客户端。
在指引资源拥有者带着授权码返回到客户端之前，授权服务器对资源拥有者进行认证并且获取其授权。由于资源拥有者仅在授权服务器上认证，资源拥有者的凭证永远不会被共享给客户端。
授权码模式提供了一些非常重要的安全保护，比如，有能力对客户端进行认证，还可以直接给客户端传送访问令牌，而不需要通过资源拥有者的用户代理来传递，避免将其暴露给其他人，包括资源拥有者。

1.3.2 简化模式

简化模式是将授权码流程进行了简化，目的是为那些在浏览器中使用脚本语言（比如 JavaScript）的客户端优化而来的一种授权模式。在简化流程中，取代为客户端分发授权码的模式，授权服务器直接将访问令牌（作为资源拥有者授权的结果）分发给客户端。这种授权模式是简单直接的，没有中间凭证（比如授权码）被分发（然后在后续流程中用来换取访问令牌）。
在简化模式流程中为客户端份饭访问令牌时，授权服务器是没有对客户端进行认证的。在一些场景中，客户端身份可以通过传递给客户端访问令牌的重定向 URI 进行验证。访问令牌有可能暴露给资源拥有者或者其他访问资源拥有者浏览器的应用。
简化模式改善了一些客户端（比如在浏览器中实现的客户端）的响应和效率是由于它减少了获取访问令牌的往返次数。然而，这种便捷应该在简化模式中实现安全的应用需要被权衡，比如在章节 10.3 和 10.6 中描述的那样，尤其是当授权码类型也可用的时候。

1.3.3 资源拥有者密码凭证模式

资源拥有者密码凭证（换言之，用户名和密码）可以被作为授权回执直接用来换取访问令牌。这个凭证应该仅在资源拥有者和客户端（举个例子，客户端是操作系统的一部分或者高度私密的应用）高度信任的情况下使用，并且是当其他授权回执类型不可用的时候（比如一个授权码）。
即使这种授权模式请求指引客户端访问资源拥有者的凭证，资源拥有者的凭证也仅仅是被用来发送单次请求以及交换一个访问令牌。这中授权模式能消除客户端为了后续使用而存储资源拥有者凭证的必要，通过交换这个凭证获取一个很长生命期的访问令牌或者刷新令牌。

1.3.4 客户端凭证

当授权范围是被限制在受客户端控制的受保护资源，或者是被授权服务器事先安排好的受保护资源，客户端凭证（或者其他形式的客户端认证）也可以被当做一种授权模式。客户端凭证被当做一种授权模式，典型场景是当客户端代表的就是它自己本身（客户端也是资源拥有者）或者请求访问一些基于授权服务器被事先安排好的受保护资源

1.4 访问令牌

访问令牌是作为访问受保护资源的凭证。一个访问令牌是分发给客户端用来代表授权的字符串。这个字符串对于客户端通常来说是不透明的。令牌是由资源拥有者颁发，来代表具体的访问时间和权限范围，并且被资源服务器和授权服务器强制执行。
令牌会使用一种可验证的方式（例如，令牌是由一些数据和一个签名组成的字符串）来表示一个用来检索授权信息或者自包含授权信息的标识符。客户端为了使用一个令牌可能需要额外的认证凭证，这些内容超出了本规范的讨论范围。
访问令牌提供了一个抽象层，使用一个单独的可被资源服务器理解的令牌来替换不同的授权结构（比如，用户名和密码）。这种抽象使得分发访问令牌的授权模式相较于直接获取它们的授权模式更加有限制性，同时移除了资源服务器需要理解一大堆认证方式。
基于资源服务器的安全要求，访问令牌可以有不同的格式，结构，以及使用方式（比如，密码学属性）。用来访问受保护资源的访问令牌属性和方式超出了本规范讨论的范围。同类规范对此有所定义，比如『RFC6750』。

1.5 刷新令牌

刷新令牌是一种用来获取访问令牌的凭证。刷新令牌由授权服务器分发给客户端，在当前访问令牌变得非法或者失效时，或者为了获得额外的拥有完全相同的或者更少访问权限（和资源拥有者授权的权限相比，访问令牌可能有更短的生命周期以及更少的访问权限）的访问令牌。是否分发一个刷新令牌可选的，具体情况由授权服务器决定。如果授权服务器分发了一个刷新令牌，它会在分发访问令牌的时候包含在其中（即，图表 1 的步骤（D））。
一个刷新令牌是一个代表资源拥有者给客户端授权的字符串。这个字符串通常对于客户端是不透明的。这个刷新令牌表示一个用来检索授权信息的标识符。不像访问令牌，刷新令牌的意图仅仅是给授权服务器使用的，永远不会发送给资源服务器。
image.png
图 2：刷新一个失效的访问令牌
图 2 中说明的流程包含下面几个步骤：
(A) 客户端通过在服务器认证，同时提交一个授权回执来请求一个访问令牌。
(B) 授权服务器对客户端进行认证并且校验授权回执，如果合法，授权服务器给客户端分发一个访问令牌和刷新令牌
(C) 客户端通过提交访问令牌来请求资源服务器中的受保护资源。
(D) 资源服务器校验访问令牌，如果合法，资源服务器则为客户端提供服务
(E) 步骤 (C) 和 (D) 一直重复知道范文令牌过期。如果客户端知道访问令牌过期了，它会跳过步骤 (G)；否则，它会继续请求其他受保护资源。
(F) 由于访问令牌是非法的，资源服务器返回了一个非法令牌错误。
(G) 客户端通过在服务器认证，同时提交这个刷新令牌来请求一个新的访问令牌。客户端是否需要认证取决于客户端类型和授权服务器策略。
(H) 授权服务器认证客户端并且校验刷新令牌，如果合法，则分发一个新的访问令牌（并且作为可选项，分发一个刷新令牌）。
步骤（C)，(D)，(E)，和 (F) 不在本规范讨论的范围，它们在第 7 章会有描述

1.6 TLS 版本

无论什么时候在本规范中使用传输层安全（TLS）时，相应的 TLS 版本会有所不同，随着时间的推移，基于广泛的部署和已知的安全性漏洞。在撰写本规范时，TLS 1.2 版本 RFC5264 时最新版本，但是只有有限的功能，并且可能不适用于实施。TLS 1.0 RFC2246 是使用最广泛的部署版本，并将提供最为广泛的互操作性。
实施也可能支持额外的传输层安全，这也会满足我们的安全要求。

1.7 HTTP 重定向

本规范广泛使用 HTTP 重定向，客户端或者授权服务器使用重定向引导资源拥有者的用户代理到另外一个目标地址。同时本规范中的示例展示了使用 HTTP 302 状态码，任何其他可用的方式通过用户代理来完成这个重定向都是允许的并且被认为是一种实现细节。

1.8 互操作性

OAuth 2.0 提供了一个拥有定义良好的安全属性的丰富的授权框架。然而，作为一个丰富的、高可扩展的框架，它拥有很多可选组件，对于本规范来说， 它更多的时为了创建广泛的非交互实现。
除此之外，本规范舍弃了一小部分必要的组件或者整个都没有定义（比如，客户端注册，授权服务器的能力，端点发现）。没有这些组件，为了实现互操作，客户端必须手动配置一个特殊的授权服务器和资源服务器。
这个框架在设计之初就有明确的预期，即规定定义的配置和必要的扩展可以在一起很好的工作来达到全网规模的互操作。

1.9 符号约定

本规范中的关键字“必须”，“不能”，“要求”，“应该”，“不应该”，“建议”，“可以”，和“可选的”被解释如 RFC2119 中描述的那样。
本规范使用 ABNF (扩充巴克斯范式) 符号 RFC5234。除此之外，URI 引用规则也被包含在 “URI（统一资源定位符：通用语法）”RFC3986
安全相关的术语可以被理解如 RFC4949 中定义的场景那样。这些术语包括，但不限于，“攻击”，“认证”，“授权”，“证书”，“保密性”，“凭据”，“加密”，“身份”，“签名”，“加签”，“信任”，“校验”，“验证”。
除非特别提示，所有协议的参数名和参数值都是大小写敏感的。

2. 客户端注册

在初始化协议之前，客户端在授权服务器进行注册。客户端通过何种方式向授权服务器注册超出了本规范讨论的范围，但是典型的方式是终端用户通过和HTML 注册表单交互来实现注册。
客户端注册不要直接在客户端和授权服务器之间交互。当授权服务器支持的时候，注册可以依赖其他方式来建立信任以及获取必要的客户端属性（比如，重定向 URI，客户端类型）。举个例子，注册可以使用自行发放或者第三方分发断言来完成，或者通过授权服务器在一个可信的通道中执行客户端发现。
当注册一个客户端的时候，客户端的开发中应该做以下几件事情：

  • 指定客户端的类型如章节 2.1 中描述的
  • 提供客户端重定向 URI 如章节 3.1.2 中描述的
  • 包含任何授权服务器要求的信息（如，应用名，站点，描述，logo，法律条款）

    2.1 客户端类型

    OAuth 定义了两种客户端类型，基于它们能否安全的在授权服务器中认证（即，是否有能力来保持它们的客户端凭证的隐私性）：
    私有类型：
    客户端有能力保持它们客户端凭据的隐私性（比如，客户端在一个安全的服务器中实现，并且严格限制客户端凭证的访问），或者有能力使用其他方式保证认证的安全性。
    公共类型：
    客户端没有能力保持它们客户端凭据的隐私性（例如，客户端在资源拥有者的设备上执行，比如，一个安装在本地的应用或者基于 Web 浏览器的应用），同时，没有任何能力通过其他方式保证客户端认证的安全性。
    客户端类型设计的意图是建立在授权服务器关于认证安全的定义和其可接受的客户端凭证暴露级别基础之上的。授权服务器不应该对客户端类型做任何的假设。
    客户端可以被实现为一些列分布式的组件集合，每一个都有一个不同的客户端类型和安全上下文（例如，一个分布式的客户端既拥有一个私密的基于服务器的组件，也拥有一个公共的基于浏览器的组件）。如果授权服务器不为这些客户端提供支持或者不提供注册客户端的注意事项指导，这个客户端应该注册每一个组件作为一个分离的客户端。
    本规范围绕以下几种客户端场景进行设计的：
    web 应用
    一个 web 应用是一个运行在 web 服务器上的客户端。资源拥有者通过在自己设备上渲染处的 HTML 界面来访问客户端，分发给客户端的凭证也作为访问一切资源的访问令牌被存储在 web 服务器上，并且不会暴露或者被资源拥有者访问。
    基于用户代理的应用
    一个基于用户代理应用是一个公共的客户端，这种客户端的客户端标识从资源服务器中下载，并且在用户代理中执行（比如：资源拥有者在自己设备上使用的 web 浏览器）。对于资源拥有者来说，协议数据和凭证通常是很容易被访问（或者通常是可见的）。因为这种应用常驻在用户代理中，当请求授权时，它们可以无缝使用用户代理的能力。
    本地应用
    一个本地应用是一种公共的客户端，它被安装和执行在资源拥有者的设备上。资源拥有者可以访问协议数据和凭证。它假设客户端中的任何客户端凭证都是可以被提取的。另外一方面，动态的分发凭证，比如访问令牌或者刷新令牌可以接收一个可接受的保护水平。至少，这些凭证被保护以避免和那些图谋不轨的服务器进行交互。在一些平台，这些凭证可能被常驻在相同设备上的另外一个应用来进行保护。

    2.2 客户端标识

    授权服务器分发给已注册的客户端一个客户端标识——一个唯一表示客户端提供的注册信息的字符串。客户端标识不是秘钥；它可以被暴露给资源拥有者，同时不应在客户端认证时独立使用。在授权服务器当中，客户端标识是唯一的。
    客户端标识的长度在本规范中没有定义。客户端应用避免对客户端标识长度做任何假设。授权服务器应该记录任何它分发的客户端标识。

    2.3 客户端认证

    如果客户端类型是私密的，出于授权服务器安全方面的要求，客户端和授权服务器建立一个合适的客户端认证方式。授权服务器可以接受任何形式的客户端认证满足其安全要求。
    私密型客户端典型的会分发一系列凭证（比如，密码，公/私钥 秘钥对）用户在授权服务器上认证。
    授权服务器可以建立为公共客户端建立一种客户端认证方式。但是，授权服务器不应该依赖公共客户端的认证方式来作为识别客户端的目的。
    在每一个请求中，客户端不应该使用多于一种的认证方式。

    2.3.1 客户端密码

    客户端密码作为客户端的个人财产可能使用 HTTP Basic 认证方案在授权服务器中认证，该方案在 [ RFC2617 ] 中定义。客户端标识被使用“application/x-www-form-urlencoded” 编码算法，编码后的值作为用户名；客户端密码使用同样的算法编码，编码后的值作为密码。当客户端被分发了一个客户端密码的时候，授权服务器必须支持 HTTP Basic 认证方案来对客户端进行认证。
    举个例子
    Authorization：Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
    可选的，授权服务器可以支持在请求体中包含客户端凭证使用如下参数：
    client_id
    必须的。章节 2.2 中描述的在客户端注册流程中分发的客户端标识。
    client_secret
    必须的。客户端秘钥，如果客户端秘钥是一个空串可以省略这个参数。
    在请求体中包含使用这两个参数来包含客户端凭证是不推荐的，同时应该限制客户端不能直接利用 HTTP Basic 认证方案（或者其他基于密码的 HTTP 认证方案）。这个请求参数只能通过请求体传输，同时不应该被包含在请求 URL 中。
    举个例子，一个刷新访问令牌的请求（章节 6）使用请求体参数：
    POST /token
    Host: server.example.com
    Content-Type: application/x-www-form-urlencode

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw
授权服务器必须要求使用章节 1.6 中描述的 TLS，在使用密码认证发送请求的时候。
由于，这种客户端认证方式涉及一个密码，这个授权服务器必须提供保护防止任何端点利用它进行暴力攻击。

2.3.2 其他认证方式

授权服务器可以支持任何符合其安全要求的 HTTP 认证方案。当使用其他认证方案时，授权服务器必须在客户端标识和授权方案之间定义一个映射关系。

2.4 解除客户端注册

本规范不排除未注册客户端的使用。然而，此类客户端的使用超出了本规范的范围，同时要求额外安全分析和审查其互操作性的影响。

协议端点

授权流程利用了两个授权服务器端点（HTPP 资源）：

  • 授权端点——客户端通过用户代理的重定向来获取资源拥有者的授权。
  • 令牌端点——客户端通过交换授权回执来获取令牌。

还有一个客户端端点：

  • 重定向端点——授权服务器通过资源拥有者的用户代理返回给客户端一个包含授权凭证的响应。

不是所有的授权模式都会利用这两个端点。扩展的授权模式可能会根据自己的需要定义额外的端点。

3.1 授权端点

授权端点用来和资源拥有者互操作来获取一个授权回执。授权服务器必须首先校验资源拥有者的身份标识。通过这种方式，授权服务器对资源拥有者进行认证（比如，用户名和密码登录，会话 cookies) ，这些内容超出了本规范的范围。
客户端通过何种方式获取授权端点的路径超出了本规范的范围，但是，这个地址通常是有服务文档提供。
这个端点的 URI 可能包含一个 “application/x-www-form-urlencoded”格式的查询组件（[RFC3986 章节 3.4），当添加额外参数的时候，这个组件必须保留。该端点 URL 一定不能包含片段标识符组件。
由于请求授权端点会导致用户认证，并且在 HTTP 响应中会传送明文凭证，当发送请求到授权端点时，授权服务器必须要求使用如章节 1.6 中描述的 TLS。
授权服务器必须支持使用 HTTP “GET”和“POST” 方法[RFC2616] 。
当接收到的参数没有值时，必须按照请求忽略了该参数来进行处理。授权服务器必须忽略未识别的请求参数。请求和相应参数不能多也不能少。

3.1.1 响应类型

授权端点是给授权码模式和简化模式使用的。客户端通过以下参数来通知授权服务器其期望的授权类型：
response_type
必须，当请求一个授权码（在章节 4.1.1 中描述）时，这个值必须是“code”，当请求一个访问令牌时（简化模式，在章节 4.2.1 中描述），这个值必须是“token”，或者像章节 8.4 中描述的注册一个扩展值。
扩展响应类型可能包含一个空格分隔符（%x20）列表，它们的顺序可能不会匹配（比如，响应类型‘a b’是和 ‘b a’一样的）。像这种组合的响应类型是由开发者各自的规范定义的。
如果一个授权请求缺少“response_type”参数，或者不能理解响应类型，授权服务器必须返回一个错误如章节 4.1.2.1 中定义的。

3.1.2 重定向端点

在和资源拥有者完成授权交互之后，授权服务器引导资源拥有者的用户代理返回到客户端。在客户端注册流程或者请求授权时，授权服务器已经和指引资源拥有者的用户代理的重定向客户端建立了联系。
这个重定向 URI 必须是绝对路径如 [RFC3986] 章节 4.3 中定义的。这个端点 URI 必须包含一个 “application/x-www-form-urlencode”格式的查询组件[RFC3986] 章节 3.4，并且必须保留添加的额外查询参数。这个端点 URI 一定不能包含一个片段标识符组件。

3.1.2.1 端点请求私密型

当请求的响应类型是“code”或者“token”，或者当重定向请求将会导致在公共网络上传输敏感的凭证时，重定向端点应该要求使用 TLS (章节 1.6 中描述的），这个规范没有委托使用 TLS 是因为截至写这篇规范时，对于很多客户端开发者，要求客户端部署 TLS 已经不是严重的障碍了。如果 TLS 不可用，授权服务器应该在之前的重定向时警告资源拥有者资源拥有者端点的不安全（比如，在请求授权时，显示一个消息）。
缺乏传输层安全会对客户端安全和它被授权访问的受保护资源有严重的影响。当客户端使用一个表单来代表终端用户的授权进行授权流程的行为在传输层安全性的使用场景中是被特别批判的（比如，三方登陆服务）。

3.1.2.2 注册要求

授权服务器必须要求客户端按照如下流程注册它们的重定向端点：

  • 公共客户端
  • 私密客户端使用简化授权模式

在使用授权端点之前，授权服务器必须要求所有的客户端注册它们的重定向端点。