OAuth 2.0
2023-10-17 11:04:44 0 举报AI智能生成
登录查看完整内容
OAuth 2.0 - RFC 6749
作者其他创作
大纲/内容
作用：为客户端提供了成功使用访问令牌提出受保护资源请求所需的信息（以及特定于类型的属性）
GET /resource/1 HTTP/1.1 Host: example.com Authorization： Bearer mF_9.B5f-4.1JqM
链接：https://datatracker.ietf.org/doc/html/rfc6750
RFC6750
GET /resource/1 HTTP/1.1 Host: example.com Authorization:MAC id=\"h480djs93hd8\
链接：https://datatracker.ietf.org/doc/html/rfc6749#ref-OAuth-HTTP-MAC
OAuth-HTTP-MAC
示例
访问令牌类型
参考 【 IANA因素 - OAuth 扩展错误注册 】
错误响应
获取受保护的资源
在访问令牌类型注册中心注册参考：【 IANA因素 - OAuth 访问令牌类型注册 】
使用唯一的绝对 URI 作为其名称限于供应商特定的实现（不普遍）
定义方式
类型名称必须符合类型名称 ABNF
如果类型定义包含新的 HTTP 身份验证方案，则类型名称应与 HTTP 身份验证方案名称（由 [RFC2617] 定义）相同
格式：type-name = 1*name-charname-char = \"-\" / \".\" / \"_\" / DIGIT / ALPHA
所有其他类型都必须注册
定义访问令牌类型
在访问令牌类型注册中心注册参考：【 IANA因素 - OAuth 参数注册 】
要求：1、参数名称必须符合 param-name ABNF2、参数值语法必须定义明确3、未注册的特定于供应商的参数扩展，如果不常用，且特定于使用这些扩展的授权服务器的实现细节，则应使用不可能与其他注册值冲突的特定于供应商的前缀
格式：param-name = 1*name-charname-char = \"-\" / \".\" / \"_\" / DIGIT / ALPHA
定义新的端点类型
过程：为其分配一个唯一的绝对 URI 来定义
补充：额外参数需要自行定义参考：【 IANA因素 - OAuth 参数注册 】
定义新的授予授权类型
参考：【 IANA因素 - OAuth 授权端点响应类型注册 】
要求：1、响应类型名称必须符合响应类型 ABNF2、如果响应类型包含一个或多个空格字符（%x20），则将其作为空格分隔的值列表进行比较，其中值的顺序并不重要3、只能注册一个值的顺序，该顺序涵盖同一组值的所有其他排列
格式：response-type = response-name *( SP response-name )response-name = 1*response-charresponse-char = \"_\" / DIGIT / ALPHA
定义新的授权端点响应类型
参考：【 IANA因素 - OAuth 扩展错误注册 】
要求：错误代码必须符合错误 ABNF，并应尽可能以标识名称作为前缀
格式：error = 1*error-charerror-char = %x20-21 / %x23-5B / %x5D-7E
定义额外的错误代码
扩展性
定义：在资源所有者使用的设备上安装和执行的客户端
使用重定向 URI 从授权服务器捕获响应，重定向 URI 采用的方案是在操作系统中注册以调用客户端作为处理程序、手动复制并粘贴凭据、运行本地网络服务器、安装用户代理扩展
通过提供重定向 URI 来识别客户端控制下的服务器托管资源，进而将响应提供给本地应用程序
外部
通过监控资源加载过程中的状态变化或访问用户代理的 cookies 存储，直接与嵌入式用户代理通信，从而获得响应
嵌入式
类型
- 外部用户代理可能会提高完成率，因为资源所有者可能已经与授权服务器建立了活动会话，无需重新进行身份验证。 提供熟悉的终端用户体验和功能。 资源所有者也可以依靠用户代理功能或扩展来协助身份验证（如密码管理器、双因素设备阅读器）。- 嵌入式用户代理可以提高可用性，因为它消除了切换上下文和打开新窗口的需要。- 嵌入式用户代理会带来安全方面的挑战，因为资源所有者是在一个无法识别的窗口中进行身份验证，而无法使用大多数外部用户代理的可视化保护功能。 嵌入式用户代理会让终端用户相信不明身份的验证请求（使网络钓鱼攻击更容易实施）。
比较
用户代理
使用授权码授予类型的本地应用程序应该不使用客户凭据因为本地应用程序无法对客户凭据保密。
使用隐式授予类型流程时，不会返回刷新令牌，因此一旦访问令牌过期，就需要重复授权流程。
额外考虑
本地应用
要求：1、授权服务器：考虑比密码更强大的认证手段2、客户端：密码、凭证的保密性
关于凭证：1、授权服务器不可以向应用、客户端发放客户端密码、凭证等2、授权服务器可以在特定设备上安装签发客户端密码、凭证
无法验证客户端时：1、要求资源所有者确认身份、客户端重定向URI的注册2、重定向URI不足以确定身份，但可以防止交付凭证给伪造的客户端
⚠️：1、授权服务器需要考虑与未认证的客户端交互的安全风险，需要采取限制措施，防止发放其他凭证的潜在暴露问题
客户端认证
描述：被冒充的客户机未能或无法对其客户机凭证保密，恶意客户机就可以冒充其他客户机
客户端身份验证
重定向URI
客户端
身份验证
向其提供：客户端相关请求的授权范围有效期
资源所有者
手段
客户端冒用（impersonation）
要求：1、在传输和存储过程中必须保密（采用TLS）2、只能在授权服务器、访问令牌有效的资源服务器以及访问令牌的客户机之间共享3、客户端应请求最小范围的访问令牌
会在 URI 片段中传输 -> 确保访问令牌不会被未授权方生成、修改或猜测
隐式授权
访问令牌
要求：1、在传输和存储过程中必须保密（采用TLS）2、只能在授权服务器、访问令牌有效的资源服务器以及访问令牌的客户机之间共享3、授权服务器必须维护刷新令牌与客户端之间的绑定4、确保刷新令牌不会被未授权方生成、修改或猜测
验证刷新令牌与客户端身份之间的绑定
采用刷新令牌轮换的方法，即每次访问令牌刷新响应都会发出一个新的刷新令牌。 前一个刷新令牌失效
刷新令牌
要求：1、明文 -> TLS传输2、必须是短期和一次性使用的3、如果客户端可以通过验证，授权服务器必须对客户端进行验证，并确保授权码是发给同一个客户端的
授权码
1、要求公共客户端和机密客户端注册其重定向 URI2、授权服务器必须确保用于获取授权码的重定向 URI 与将授权码与访问令牌交换时提供的重定向 URI 相同
授权码重定向URI操作
作用：通常用于遗留或迁移原因1、降低了客户端存储用户名和密码的整体风险，但并不能消除向客户端暴露高权限凭证的需要
资源拥有者密码凭证
访问令牌、刷新令牌、资源所有者密码客户端凭证、授权码
不能明文传输
status、scope
安全传输和存储
请求保密性
避免中间人攻击：1、授权服务器必须要求对发送到授权和令牌端点的任何请求使用 [RFC2818] 所定义的带服务器验证的 TLS。 2、客户端必须按照 [RFC6125] 的定义并根据其对服务器身份验证的要求，验证授权服务器的 TLS 证书。
确保端点的真实性（authenticity）
说明：防止攻击者猜测访问令牌、授权码、刷新令牌、资源所有者密码和客户端凭证
要求：1、攻击者猜测生成的令牌的概率必须小于或等于 2^(-128)，并且应该小于或等于 2^(-160)。2、授权服务器必须使用其他方法来保护供最终用户使用的凭证
凭证猜测攻击
用户对于重定向后输入密码的方式感到厌烦容易忽略网站的真实性
背景
服务提供商应努力教育终端用户了解网络钓鱼攻击带来的风险
授权服务器必须要求用于终端用户交互的每个终端都使用 TLS
交互上：用户可以轻松确认、不繁琐
要求
钓鱼（phishing）攻击
描述：攻击者会使受害终端用户的用户代理跟踪恶意 URI（例如，以误导链接、图像或重定向的形式提供给用户代理）到可信服务器（通常通过存在有效的会话 cookie 来建立）
CSRF 攻击允许攻击者注入自己的授权代码或访问令牌，这可能导致客户端使用与攻击者受保护资源相关联的访问令牌，而不是受害者的访问令牌
特性
客户端必须为其重定向 URI 实施 CSRF 保护：1、发送请求时包含一个将请求与用户代理的验证状态绑定的值，如state2、授权服务器重定向返回时，客户端可以再次验证
授权服务器的保护方式：1、验证客户端发送来的特殊值（state）前后是否一致2、如果了解客户端构造值的方式，可以进行特殊值的验证
防范
同源策略
无法查看cookie
浏览器策略
跨站请求伪造（forgery）（CSRF）
案例：1、攻击者会注册一个合法客户端，然后构建一个恶意网站，在该网站上以透明 iframe 的形式加载授权服务器的授权端点网页，在上面叠加一组假按钮，这些假按钮经过精心设计，直接放置在授权页面上重要按钮的下方2、用户点击一个误导性的可见按钮时，实际上是在点击授权页面上的一个不可见按钮（如 \"授权 \"按钮），在不知情的情况下授予其客户端访问权
描述
本地应用程序在请求最终用户授权时应使用外部浏览器1、对于大多数较新的浏览器，授权服务器可以使用（非标准）\"x-frame-options \"头来避免使用 iframe2、标头有两个值：\"deny\"（拒绝）和 \"sameorigin\"（同一来源），它们将分别阻止任何框架或不同来源网站的框架3、对于旧版浏览器，可以使用 JavaScript 框架拦截技术，但并非对所有浏览器都有效
点击劫持（Clickjacking）
外部变量在未经审核的情况下被应用程序使用并导致应用程序逻辑被修改
后果：攻击者访问应用设备或其数据，导致拒绝服务，或引入各种恶意副作用
授权服务器和客户端必须对收到的任何值进行消毒1、尤其是 \"state \"和 \"redirect_uri \"参数的值2、并在可能的情况下进行验证
代码注入和输入验证
使用参数将用户代理自动重定向到参数值指定位置的端点，而不进行任何验证
被用于用于网络钓鱼攻击，或由攻击者通过使用熟悉和可信目的地的 URI 授权组件让终端用户访问恶意网站
如果授权服务器只允许客户端注册重定向 URI 的一部分，攻击者就可以使用客户端操作的开放式重定向器来构建重定向
问题
开放式转发器（open redirectors）
背景：隐式授权的客户端，访问令牌和客户端未进行绑定
被钓鱼：资源所有者可能会通过向攻击者的恶意客户端授予访问令牌，自愿委托他人访问资源
攻击者也可能通过其他机制窃取令牌。 然后，攻击者可能会向合法的公共客户端提供访问令牌，试图冒充资源所有者1、攻击者可以很容易地在授权服务器的响应中切换令牌，用之前发给攻击者的令牌替换真正的访问令牌2、与本机应用程序通信的服务器，如果依赖于在后信道中传递访问令牌来识别客户端的用户，那么攻击者也可能通过创建可注入任意窃取的访问令牌的受攻击应用程序，对服务器进行类似的攻击
按照隐式授权的要求，限制隐式授权的使用
在隐性（Implicit）流中滥用（impersonate）访问令牌冒充资源所有者
安全因素
The Internet Assigned Numbers Authority，互联网数字分配机构
流程：发邮件到oauth-ext-review@ietf.org -> 审核 -> 发布到补充协议 RFC5226
Additional Token Endpoint Response Parameters：与 \"access_token \"参数一起返回的附加响应参数
HTTP Authentication Scheme(s):HTTP 身份验证方案名称
Change controller:对于标准跟踪 RFC，请注明 \"IETF\"。 对于其他内容，请提供负责方的名称。 也可包括其他详细信息（如邮政地址、电子邮件地址、主页 URI）
Specification document(s):指明参数的文件参考，最好包括可用于检索文件副本的 URI。 也可包含相关章节的说明，但不是必需的。
注册模版
OAuth访问令牌类型注册
Parameter name:请求的名称
Parameter usage location:可使用参数的位置。 可能的位置包括授权请求、授权响应、令牌请求或令牌响应。
Change controller:参考上述
https://datatracker.ietf.org/doc/html/rfc6749#section-11.2.2
初始化注册内容
OAuth参数注册
Response type name:请求的名称
Change controller:参考上述
Specification document(s):指明参数的文件参考，最好包括可用于检索文件副本的 URI。 也可包含相关章节的说明，但不是必需的。
o Response type name: code o Change controller: IETF o Specification document(s): RFC 6749 o Response type name: token o Change controller: IETF o Specification document(s): RFC 6749
OAuth授权端点响应类型注册
Error Name:请求的名称
Error usage location:可使用错误的位置。 可能的位置包括授权代码授予错误响应、隐式授予错误响应、令牌错误响应或资源访问错误响应
Related protocol extension:与错误代码一起使用的扩展授予类型、访问令牌类型或扩展参数的名称
OAuth扩展错误注册
IANA因素
规范（Normative）参考
翔实（Informative）参考
参考
client_id
client_secret
response_type
scope
state
redirect_uri
error
error_description
error_uri
grant_type
code
access_token
token_type
expires_in
username
password
refresh_token
端点参数
增强的巴克斯-诺尔形式句法(ABNF: Augmented Backus-Naur Form)
来源：https://datatracker.ietf.org/doc/html/rfc6749
原理：客户端通过使用资源所有者的凭证与服务器进行认证，从而请求服务器上的访问受限资源（受保护资源）
缺陷：- 第三方应用程序需要存储资源所有者的凭证供将来使用，通常是明文密码。- 服务器必须支持密码认证，尽管密码本身存在安全漏洞。- 第三方应用程序对资源所有者受保护资源的访问权限过大，导致资源所有者无法限制资源的使用期限或对有限资源子集的访问权限。- 资源所有者无法在不取消所有第三方访问权限的情况下取消单个第三方的访问权限，而必须通过更改第三方的密码来实现。- 任何第三方应用程序的泄露都会导致最终用户的密码和受该密码保护的所有数据泄露。
客户端-服务器 认证模式
解决：引入一个授权层，将客户端和资源所有者的角色分开
原理：客户端 -> 授权服务器 -> 资源所有者发放访问令牌（特定范围、有效期、访问属性）
限制：仅限于HTTP协议
OAuth
概述
资源所有者1、能够授权访问受保护资源的实体2、如果是个人，则称：end-user
资源服务器1、托管受保护资源的服务器，能够接收和响应 使用访问令牌请求受保护资源的请求
客户端1、代表资源所有者并经其授权发出受保护资源请求的应用程序2、不意味着任何特定的实施特征（服务器、台式机、其他设备）
授权服务器1、在成功认证资源所有者并获得授权后，向客户端发放访问令牌的服务器
补充说明：1、授权服务器和资源服务器之间的交互不在本规范范围内 - 可以是相同的服务器，也可以是单独的实体2、单个授权服务器可以发出多个资源服务器接受的访问令牌
角色
抽象协议流
A：两种场景1、请求可以直接向资源所有者提出2、（默认）通过授权服务器做为中介间接提出
B：授权的凭证使用本规范定义的四种许可类型之一或扩展许可类型类型取决于：请求的方法、授权服务器支持的类型
过程补充
⚠️：A、B步骤是使用授权服务器做为中介，详见第四部分
协议流
含义：资源所有者授权访问其受保护资源的凭证
分类：下面4种、基于可扩展机制的定义
场景：使用授权服务器做为中介（RFC2616定义的用户代理）
前提工作：1、授权服务器对资源所有者进行认证（不会将凭据与客户端共享）
优势：1、可以对客户端进行认证2、不会潜在地暴露给其他人
原理：1、简化的授权码流程，不向客户端发放授权码，而是直接向客户端发放访问令牌2、因为没有签发中间凭据，所以是隐式的
场景：1、优化了使用 JavaScript 等脚本语言在浏览器中实现的客户端
分析：1、签发访问令牌时，授权服务器不会对客户端进行认证2、某些情况下，客户端身份可通过重定向URI进行验证3、缺点：访问令牌可能会暴露给资源所有者、其他可以访问资源所有者的用户代理的应用程序
和授权码比较：1、速度快、效率高2、安全性相对较差
第三方说明：1、不包含客户端认证的过程2、令牌直接编码在重定向URI中3、适合无授权服务器的场景
隐式授权（Implicit）
原理：1、资源所有者密码凭证（即用户名和密码）直接用作获取访问令牌的授权许可
要求：1、资源所有者对客户端高度信任2、无法使用其他授权类型
补充：1、资源所有者凭证用于单次请求，并与访问令牌交换2、可以通过用长期访问令牌或刷新令牌交换凭证，使客户端无需存储资源所有者凭证
资源所有者的密码凭证
原理：客户端凭证用作授权授予
要求：1、授权范围仅限于客户端控制的受保护资源，或仅限于授权服务器安排的受保护资源2、客户端即资源所有者
客户端凭证
授权许可
作用：用于访问受保护资源的凭证
结构：字符串（数据、签名）1、代表特定的访问范围和期限2、加密、属性等，由RFC6750定义
来源和使用：1、来源：资源所有者2、使用：资源服务器、授权服务器
优势：1、资源服务器不需要了解各种认证方法2、访问令牌的限制更严格，可以控制的粒度更细
流程图：CDEF不属于本规范范围，见【获取受保护的资源】
作用：在以下情况下获取访问令牌的凭证1、访问令牌失效或过期2、获取范围相同或更小的其他访问令牌
说明：1、是否发放由授权服务器自行决定2、仅和授权服务器交互
说明：1、TLS的版本取决于广泛的部署情况和已知的安全漏洞2、TLS 1.2【RFC5246】最新，但部署有限3、TLS 1.0【RFC2246】部署广泛，互操作性广4、符合其安全要求的其他传输层安全机制也可以
TLS版本
作用：客户端或授权服务器将资源所有者的用户代理指向另一个目的地本规范广泛使用到
HTTP重定向
未定义组件：客户端注册、授权服务器功能、端点发现
实现互操作：1、客户端必须针对特定的授权服务器和资源服务器进行手动和专门的配置2、定义必要的规范性配置文件和扩展
互操作性（interoperability）
关键词：按照RFC2119中的描述进行解释：\"MUST\"、\"MUST NOT\"、\"REQUIRED\"、\"SHALL\"、\"SHALL NOT\"、\"SHOULD\"、\"SHOULD NOT\"、\"RECOMMENDED\"、\"MAY \"、\"OPTIONAL\"
符号：1、RFC5234的ABNF2、RFC3986的URI
术语（安全相关）：RFC4949\"攻击\"、\"认证\"、\"授权\"、\"证书\"、\"保密\"、\"凭证\"、\"加密\"、\"身份\"、\"签名\"、\"签章\"、\"信任\"、\"验证 \"、\"核实\"\"attack\
协议参数名称、值都区分大小写（除特殊说明）
符号约定（Notational Conventions）
介绍
在启动协议之前，客户端要向授权服务器注册。客户端向授权服务器注册的方式超出了本规范的范围，但通常涉及终端用户与 HTML 注册表单的交互。
注册方式（不直接交互）：1、重定向URI2、客户端类型3、断言：自我发布、第三方发布4、可信任通道执行客户端发现
对客户端要求：1、规定的客户端类型2、提供重定向URI3、授权服务器要求的任何其他信息：名称、网站、描述、徽标、法律条款的接受
说明：客户端有能力维护其凭据的机密性，或有能力使用其他方式进行安全客户端认证
场景：安全服务器上实施的客户端，对客户端凭据的访问受到限制
机密
说明：客户端无法对其凭据保密，也无法通过任何其他方式进行安全客户端认证
场景：在资源所有者使用的设备上执行的客户端，如安装的本地应用程序、基于网络浏览器的应用程序
公共
分类
原则：基于授权服务器对安全认证的定义及其可接受的客户端凭证暴露级别
⚠️：授权服务区不应该假设客户端类型
案例方案：分布式客户端1、客户端做为一组分布式组件来实现，每个组件都有不同的类型（基于保密服务器、基于公共浏览器）和安全上下文2、如果授权服务器不支持此类客户端或不提供有关其注册的指导，则客户端应将每个组件作为单独的客户端注册
指定
说明：在网络服务器上运行的保密客户端
交互：资源所有者通过在资源所有者使用的设备上的用户代理中呈现的 HTML 用户界面访问客户端
特点：客户端凭证以及发给客户端的任何访问令牌都存储在网络服务器上，不会暴露给资源所有者，资源所有者也无法访问
网络应用程序
说明：一种公共客户端
交互：客户端代码从网络服务器下载，并在资源所有者所用设备上的用户代理（如网络浏览器）内执行
协议数据和凭证很容易被资源所有者访问（通常是可见的）
由于此类应用程序位于用户代理中，因此在请求授权时可以无缝使用用户代理的功能
特点
基于用户代理的应用程序
说明：在资源所有者使用的设备上安装和执行的公共客户端
资源所有者可访问协议数据和凭证（假设客户端中的凭证可以提取）
不会被敌对服务器窃取
不会被同一设备上的其他应用窃取
动态签发的凭证可以获得可接受程度的保护
本地应用程序
网络应用程序：网页程序（前后端分离）
基于用户代理的应用程序：网页程序（纯JS）
本地应用程序：APP
举例（个人理解）
配置文件（规范基准）
客户端类型
作用：代表客户端提供的注册信息的唯一字符串
限制：不得单独用户客户端认证
非保密的，暴露给资源所有者
对于授权服务器是唯一的
字符串格式不在本规范约束范围
特征
客户端标识符（Identifier）
授权服务器可以接受符合其安全要求的任何形式的客户端认证
客户端通常会获得一组客户端凭证，用于与授权服务器进行认证（密码、公/私钥对）
机密客户端
授权服务器不得依赖公共客户端认证来识别客户端
公共客户端
每次请求中不能使用超过一种的认证方法
限制
标准：RFC2617定义的HTTP基本认证方案
用户名：客户端标识符使用附录 B 中的 \"application/x-www-form-urlencoded \"编码算法进行编码，作为用户名
密码：使用与用户名相同的算法
要求：授权服务器必须支持 HTTP Basic 认证方案
认证
授权： Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
使用Basic
在请求正文中包含客户端凭据，使用以下参数1、client_id：客户端标识符2、client_secret：客户端密钥，没有可省略
参数只能在请求正文中，不能在URI中
示例：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
要求：1、授权服务器必须使用TLS2、确保任何终端免受暴力攻击
不能使用Basic
举例
客户端密码
授权服务器必须定义客户端标识符和认证方案之间的映射
授权服务器可以支持与其安全要求相匹配的任何合适的 HTTP 认证方案
其他认证方法
使用未注册的客户端不在本规范的范围内，但不排除
需要对互操作性影响进行额外的安全分析和审查
未注册的客户端
客户端注册
授权端点：客户端用于通过用户代理重定向，从资源所有者获取授权
令牌端点：客户端用于将授权许可换成访问令牌，通常需要进行客户端认证
授权服务器端点（HTTP）
重定向端点：由授权服务器通过资源所有者用户代理，向客户端返回包含授权凭证的响应
客户端端点
授权服务器验证资源所有者的身份（用户名密码、会话cookies）
客户端获取授权端点位置（一般在文档中给出）
超出规范范围
可以包括\"application/x-www-form-urlencoded \"格式（根据附录 B）的查询组件（[RFC3986]
不可以包含片段组件
端点URI
使用TLS：保护响应中的明文凭据
HTTP方法：授权服务器必须支持授权端点使用 HTTP \"GET \"方法[RFC2616]，也可以支持使用 \"POST \"方法
没有值的视为省略的参数，授权服务器需要忽略
请求和响应参数不得重复
请求参数
参数名：response_type
授权码授予类型
隐式授予类型流程
使用者
作用：被客户端使用，来通知授权服务器所需的授权类型
场景：1、（4.1.1）用于请求授权码2、（4.2.1）请求访问令牌（隐式授予）3、（8.4）注册扩展值
格式：1、可以包含空格的值的列表，顺序不重要2、含义由各自的规范规定举例：\"a b\" == \"b a\"
错误场景：1、请求缺少该参数2、响应类型不被理解授权服务器返回相应的错误响应
响应类型
场景：1、授权服务器在完成与资源所有者的交互后，会将资源所有者的用户代理定向回客户端2、重定向端点的建立：客户端注册时、提出授权请求时
定义：1、URI必须是 RFC3986 第4.3节定义的绝对URI2、端点URI可以包括\"application/x-www-form-urlencoded \"格式（根据附录 B）的查询组件（[RFC3986] 第 3.4 节）3、不得包含片段组件
使用TLS：正常响应请求的code或token
TLS不可用：授权服务器重定向前就不安全端点向资源所有者发出警告（提示消息）
补充：传输层安全性尤为关键，特别是当授权过程被用作客户端委托终端用户认证的一种形式（如第三方登录服务）时
终端请求保密性（Confidentiality）
隐式授权类型的机密客户端
需要重定向端点的客户端
要求：客户端在使用授权端点之前注册其重定向端点（可以是多个）无法满足要求的：提供注册URI方案、授权和路径（请求授权时仅动态更改重定向URI的查询组件）
缺乏重定向URI：使攻击者将授权端点用作第 10.15 节所述的开放式重定向器
注册请求
注册了多个重定向URI
注册了部分重定向URI
未注册重定向URI
使用redirect_uri请求参数场景
授权服务器需要与已注册的重定向URI做比较
如果注册了完整的重定向URI，则必须使用RFC3986 第6.2.1节中定义的方式比较URI
请求包含redirect_uri
动态配置
缺少
无效
不匹配
场景
处理：授权服务器将错误告知资源所有者，不得将代理进行重定向
无效端点
背景：1、重定向产生HTML文档响应，由用户代理处理2、HTML响应做为重定向请求的结果 -> HTML的任何脚本都会访问到重定向URI和所含凭证
要求：1、客户端不应在重定向端点响应中包含任何第三方脚本（分析、广告、插件）2、客户端应从URI提取凭据，并将用户代理再次重定向到另一个端点，不得暴露凭据3、如果包含第三方脚本，则应该先执行自己的脚本（提取凭据、删除凭据）
端点内容
重定向端点
授权端点
作用：客户端通过出示授权许可或刷新令牌来获取访问令牌
要求：1、除了隐式授权类型（因为访问令牌是直接签发的）外，令牌端点与每个授权许可一起使用2、端点 URI 可以包括 \"application/x-www-form-urlencoded \"格式（根据附录 B）的查询组件（[RFC3986] 第 3.4 节）3、端点 URI 不得包含片段组件4、必须使用TLS（明文凭据）5、请求方式：客户端必须使用 HTTP \"POST \"方法6、发送的参数如果没有值，必须视作请求中省略的参数。 授权服务器必须忽略未识别的请求参数。 7、请求和响应参数不得包含多次
补充：1、客户端获取令牌端点位置的方法超出了本规范的范围（应在文档中提供）
强制刷新令牌和授权码与所发放的客户端绑定（重定向URI未注册的情况，客户端认证非常重要）
通过禁用客户端或更改其凭据来恢复受损的客户端，从而防止攻击者滥用窃取的刷新令牌。更改单套客户端凭据的速度明显快于撤销整套刷新令牌。
实施认证管理最佳实践，需要定期轮换凭证。 轮换整套刷新令牌可能具有挑战性，而轮换单套客户端凭据则要容易得多。
目的
补充：1、客户端可以使用 \"client_id \"请求参数来标识自己2、在向令牌端点发送的 \"authorization_code\"\"grant_type \"请求中，未经验证的客户端必须发送自己的 \"client_id\"，以防止自己无意中接受了为具有不同 \"client_id \"的客户端设计的代码（可以保护客户端不被替换认证码）
令牌端点
客户端：使用 \"scope \"请求参数指定访问请求的范围
授权服务器：使用 \"scope \"响应参数通知客户端所发访问令牌的范围
格式：范围参数的值以空格分隔、大小写敏感的字符串列表的形式表示scope = scope-token *( SP scope-token ) scope-token = 1*( %x21 / %x23-5B / %x5D-7E )注：参数值包含多个以空格分隔的字符串，它们的顺序并不重要，每个字符串都会给请求的范围增加一个额外的访问范围
使用：1、授权服务器可以完全或部分忽略客户端请求的范围，当请求和签发的范围不一样时，必须返回包含scope的响应参数2、客户端遗漏scope参数时，授权服务器必须按照预定义的默认值来处理
访问令牌权限（scope）
协议端点
作用：获取访问令牌和刷新令牌，并针对保密客户端进行了优化
说明：基于重定向的流程1、客户端必须能与资源所有者的用户代理交互2、客户端能够接收来自授权服务器的传入请求（通过重定向）
(A) 客户端将资源所有者的用户代理引向授权端点，从而启动流程； 客户端包括其客户端标识符、请求范围、本地状态和重定向 URI；一旦访问被批准（或拒绝），授权服务器将把用户代理发回该 URI。
(B) 授权服务器（通过用户代理）认证资源所有者，并确定资源所有者是同意还是拒绝客户端的访问请求。
(C) 假设资源所有者同意访问，则授权服务器使用先前（在请求中或客户端注册期间）提供的重定向 URI 将用户代理重定向回客户端。 重定向 URI 包括授权码和客户端先前提供的任何本地状态。
(D) 客户端从授权服务器的令牌端点请求访问令牌，包括在上一步中收到的授权码。 发出请求时，客户端会对授权服务器进行认证。 客户端包括用于获取授权码以进行验证的重定向 URI。
(E) 授权服务器对客户端进行认证，验证授权码，并确保收到的重定向 URI 与步骤 (C) 中用于重定向客户端的 URI 一致。 如果有效，授权服务器将返回访问令牌和刷新令牌。
流程
客户端 -- 查询组件（application/x-www-form-urlencoded）参数 --> 授权端点
说明：1、授权服务器会验证请求，以确保所有必要参数都存在且有效2、如果请求有效，授权服务器将对资源所有者进行认证，并获得授权决定3、授权服务器将用户代理导向所提供的客户端重定向 URI3.1、使用 HTTP 重定向响应3.2、通过用户代理可用的其他方式，
response_type（必填）
cliend_id（必填）
state（推荐）：1、客户端用于在请求和回调之间保持状态的不透明值2、授权服务器将用户代理重定向回客户端时会包含此值3、该参数应用于防止跨站请求伪造
参数
示例：客户端引导用户代理使用 TLS 发出以下 HTTP 请求GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com
授权请求
授权服务器 -- 重定向（application/x-www-form-urlencoded）参数 --> 客户端
补充1、客户端必须忽略无法识别的响应参数2、响应字节码的大小不在本规范定义，客户端应避免假设3、授权服务器应记录其发布的任何值的大小
code（必填）：授权码1、降低泄密风险：发出不久后过期，建议10分钟2、不得多次使用
more than once1、授权码被多次使用后，会拒绝请求，并撤销之前该授权码签发的所有令牌2、授权码与客户端标识符和重定向 URI 绑定
state：参考请求
示例：HTTP/1.1 302 Found Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz
常规
重定向URI丢失、无效、不匹配
客户端标识符丢失、无效
将错误告知资源所有者
不得自动将用户代理重定向到无效的重定向URI
处理
格式：不得包含%x20-21 / %x23-5B / %x5D-7E 以外的字符
invalid_request
unauthorized_client
access_denied
unsupported_response_type
invalid_scope
server_error
temporarily_unavailable
error（必填）：单个ASCII错误码
error_description：不得包含 %x20-21 / %x23-5B / %x5D-7E 字符集以外的字符
error_uri：1、包含错误信息的人工可读网页2、不得包含 %x21 / %x23-5B / %x5D-7E 以外的字符
授权响应
客户端 -- 查询组件（application/x-www-form-urlencoded）参数 --> 令牌端点
授权服务器必须 1、要求机密客户端或任何已获得客户端凭证（或有其他认证要求）的客户端进行客户端认证、 2、如果包括客户端认证，则对客户端进行认证、 3、确保授权码是向经过认证的保密客户端发放的，如果客户端是公开的，则确保授权码是向请求中的 \"client_id \"发放的、 4、验证授权码是否有效，以及 4.1、如果 \"redirect_uri \"参数包含在第 4.1.1 节所述的初始授权请求中，则确保 \"redirect_uri \"参数存在；4.2、如果包含 \"redirect_uri \"参数，则确保其值相同。
grant_type（必填）：设置为 \"authorization_code\"
code（必填）：授权码
redirect_uri（必填）：与请求（如果存在）中的必须相同
client_id：未与授权服务器认证时，必填
示例：POST /token HTTP/1.1 Host: server.example.com Authorization： Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
访问令牌请求
参考：发放访问令牌
访问令牌、刷新令牌
返回
示例：HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { \"access_token\": \"2YotnFZFEjr1zCsicMWpAA\
访问令牌响应
授予授权码
作用：获取访问令牌（不支持发放刷新令牌）1、针对已知可操作特定重定向 URI 的公共客户端进行了优化2、客户端通常是在浏览器中使用 JavaScript 等脚本语言实现的
要求：1、客户端必须能够与资源所有者的用户代理（通常是网络浏览器）进行交互2、客户端能接收来自授权服务器的传入请求（通过重定向）
说明：1、不包括客户端认证，依赖于资源所有者的存在和重定向 URI 的注册。 2、由于访问令牌被编码到重定向 URI 中，因此可能会暴露给资源所有者和驻留在同一设备上的其他应用程序。
特殊说明：1、段中存储的访问令牌信息，在重定向时是不带上的
(E) 网络托管客户端资源会返回一个网页（通常是带有嵌入式脚本的 HTML 文档），该网页能够访问完整的重定向 URI，包括用户代理保留的片段，并提取片段中包含的访问令牌（和其他参数）。(F) 用户代理在本地执行网络托管客户端资源提供的脚本，提取访问令牌。(G) 用户代理将访问令牌传递给客户端。
流程：参考授权码授予流程
说明：1、授权服务器会验证请求，以确保所有必要参数都存在且有效2、如果请求有效，授权服务器将对资源所有者进行认证，并获得授权决定3、授权服务器将用户代理导向所提供的客户端重定向 URI3.1、使用 HTTP 重定向响应3.2、通过用户代理可用的其他方式，
client_id（必填）
示例：GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com
授权请求（与授权码授予的请求一致）
授权服务器 -- 经资源所有者的同意 --- 重定向（application/x-www-form-urlencoded）参数 --> 客户端
补充1、不得发出刷新令牌2、对于不支持fragment组件的代理，除了3XX响应外，序言额外的方法进行重定向（如：一个可以重定向到目标HTML页面的按钮）3、客户端必须忽略无法识别的响应参数4、响应字节码的大小不在本规范定义，客户端应避免假设5、授权服务器应记录其发布的任何值的大小
access_token（必填）：访问令牌
token_type（必填）：不区分大小写，参考 【获取受保护资源 - 令牌类型】
expires_in（建议使用）：有效期（以秒为单位）
scope：与请求的scope相同时，可以忽略；否则为必填
示例：HTTP/1.1 302 Found Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA &state=xyz&token_type=example&expires_in=3600
格式：不得包含%x20-21 / %x23-5B / %x5D-7E 以外的字符
error_description：不得包含 %x20-21 / %x23-5B / %x5D-7E 字符集以外的字符
error_uri：1、包含错误信息的人工可读网页2、不得包含 %x21 / %x23-5B / %x5D-7E 以外的字符
示例：HTTP/1.1 302 Found Location: https://client.example.com/cb#error=access_denied&state=xyz
响应访问令牌
隐式授权（Implicit Grant）
场景：资源所有者与客户端有信任关系如：设备操作系统
说明：1、⚠️：只有其他流程不可用的情况下才允许使用2、客户端可以获取到资源所有者凭证：用户名、密码（通常使用交互式表单），能将存储的凭证转换为访问令牌3、可用于将使用HTTP Basic 或 Digets 认证等直接认证方案的客户端迁移到OAuth
获取方法超过本规范的范围
一旦获得访问令牌，客户端必须丢弃凭证
授权请求和响应
授权服务器必须 1、要求机密客户端或任何已获得客户端凭证（或有其他认证要求）的客户端进行客户端认证 2、如果包含客户端认证，则对客户端进行认证3、使用现有密码验证算法验证资源所有者密码凭证。4、保护资源所有者的密码，免受暴力攻击
grant_type（必填），值必须设置为 password
username（必填）
password（必填）
示例：POST /token HTTP/1.1 Host: server.example.com Authorization： Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=password&username=johndoe&password=A3ddj3w
授予资源所有者的密码凭证
场景1、客户请求访问其控制下的受保护资源2、先前与授权服务器安排好的其他资源所有者的资源
要求：1、客户凭据授予类型只能由保密客户使用
不需要
授权服务器必须 1、授权服务器必须对客户端进行身份验证
grant_type（必填），值必须设置为 client_credentials
示例：POST /token HTTP/1.1 Host: server.example.com Authorization： Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=client_credentials
示例：HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { \"access_token\": \"2YotnFZFEjr1zCsicMWpAA\
授予客户端凭证
方式：1、使用绝对 URI（由授权服务器定义）作为令牌端点 \"grant_type \"参数的值指定授权类型2、并添加任何必要的附加参数
示例：POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2- bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU [...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
授予的扩展
获取授权
格式：[RFC4627] 定义的 \"application/json \"媒体类型
refresh_token：刷新令牌
内容
授权服务器必须在任何包含令牌、凭证或其他敏感信息的响应中包含（参考：RFC2616）1、Cache-Control: no-store2、Pragma: no-cache
响应体
成功响应
格式：[RFC4627] 定义的 \"application/json \"媒体类型
举例：HTTP/1.1 400 Bad Request Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { \"error\": \"invalid_request\" }
发放（issue）访问令牌
客户端 -- 重定向（application/x-www-form-urlencoded）参数 --> 授权服务器
补充1、前提：授权服务器向客户端发出了刷新令牌2、刷新令牌与向其签发的客户机绑定
授权服务器必须 1、要求机密客户端或任何已获得客户端凭证（或有其他身份验证要求）的客户端进行客户端身份验证、 2、如果包括客户端身份验证，则对客户端进行身份验证，并确保刷新令牌已签发给通过身份验证的客户端3、验证刷新令牌。
gramt_type（必填）：refresh_token
refresh_token（必填）：发给客户端的刷新令牌
示例：POST /token HTTP/1.1 Host: server.example.com Authorization： Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
刷新令牌更新：1、客户端必须丢弃旧的刷新令牌并用新的刷新令牌替换2、授权服务器可以在向客户机发出新的刷新令牌后撤销旧的刷新令牌。 3、如果签发了新的刷新令牌，刷新令牌的范围必须与客户端在请求中包含的刷新令牌的范围相同。
刷新访问令牌
OAuth 2.0
收藏
0 条评论
回复 删除
下一页
