授权类型

Verify授权类型指客户端用于从...获取身份令牌和访问令牌的授权机制。 您可以选择授权码隐式授权、授权码与隐式授权组合、 设备流资源所有者凭据JWT基于上下文的授权刷新令牌以及令牌交换

请参阅下表以了解支持的授权类型的比较,并确定要为应用程序设置的授权类型。
表 1. 资助类型
特征 预授权代码 授权代码 隐式 授权代码和隐式
描述 /preauth 预授权端点会返回预授权码。 预授权码被兑换为访问令牌。 /token必须进行客户端身份验证,才能从令牌端点交换访问令牌。

授权端点 /authorize 返回授权代码。 然后,可以使用授权代码交换标识令牌、访问令牌或刷新令牌。

需要进行客户机认证,方法是使用客户机标识和密钥来从令牌端点 /token 检索标识令牌或访问令牌。

这是最常用的流程。

授权端点 /authorize 直接返回标识令牌或访问令牌。

它不使用授权代码或令牌端点 /token

它允许客户机前端和后端相互独立地接收令牌。

客户机从授权端点 /authorize 获取授权代码和令牌。 某些令牌是从令牌端点 /token 请求的。

用例 用于以下凭证签发场景:
  • 用户身份验证和授权由凭证签发方负责。
  • 所签发的凭证无需高安全级别,例如购买电影票。

用于此类客户机:它们可以安全地维护客户机密钥(例如 Web 应用程序)和本机移动应用程序。

其目的是对用户和客户端进行身份验证。

用于此类客户机:它们无法保存客户机密钥,例如,基于浏览器或基于 JavaScript 的应用程序。

旨在认证用户。

用于此类客户机
  • 可安全地维护客户机密钥(例如 Web 应用程序)和本机移动应用程序。
  • 需要立即访问标识令牌以获取身份信息。
  • 需要通过使用刷新令牌获取有效期更长的令牌。
响应类型值 不适用
code
id_token
token
id_token token
code id_token
code token
code id_token token
从授权端点返回所有令牌。 不适用
从令牌端点返回所有令牌。
不向用户代理显示令牌。
可以认证客户机应用程序。
生成刷新令牌。
来回通信
多数通信服务器到服务器 可变
登录提示 (login_hint)
john@ibm.com该值可以是字符串形式的用户名(例如),也可以是 JSON 格式(例如),
{"realm":"securityVerifyRealm",
"username":"john@ibm.com"}
. 使用 JSON 值时,域表示身份源域。
john@ibm.com该值可以是字符串形式的用户名(例如),也可以是 JSON 格式(例如),
{"realm":"securityVerifyRealm",
"username":"john@ibm.com"}
. 使用 JSON 值时,域表示身份源域。
john@ibm.com该值可以是字符串形式的用户名(例如),也可以是 JSON 格式(例如),
{"realm":"securityVerifyRealm",
"username":"john@ibm.com"}
. 使用 JSON 值时,域表示身份源域。
最长认证年限 (max_age) 不适用 此值是自上次用户活动认证以后允许的耗用时间(以秒为单位)。 此属性仅适用于云目录登录会话。 此值是自上次用户活动认证以后允许的耗用时间(以秒为单位)。 此属性仅适用于云目录登录会话。 此值是自上次用户活动认证以后允许的耗用时间(以秒为单位)。 此属性仅适用于云目录登录会话。
工作流程
  1. 凭证签发方对最终用户进行身份验证,并获取用户的授权。
  2. 凭证签发方向Verify授权服务器请求预授权码。
  3. Verify 授权服务器会生成预授权码。
  4. Verify 授权服务器可选择性地将交易代码发送给最终用户。
  5. 凭证签发方向钱包提交预授权代码。
  6. 钱包会要求最终用户输入交易代码(如适用)。
  7. 钱包将预授权码兑换为访问令牌。
  8. Wallet 使用访问令牌从凭证签发方检索凭证。
  1. 客户机准备一个包含必需请求参数的认证请求。
  2. 客户端将请求发送至授权服务器 Verify
  3. 授权服务器对 Verify 用户进行身份验证。
  4. 授权服务器 Verify 获取用户的同意或授权。
  5. 授权服务器 Verify 将用户重定向回客户端,并附带一个授权码。
  6. 客户机通过使用令牌端点处的授权代码来请求认证响应。
  7. 客户机接收到响应,响应主体中包含标识令牌和访问令牌。
  8. 客户机验证标识令牌并检索用户的主体标识。
  1. 客户机准备一个包含必需请求参数的认证请求。
  2. 客户端将请求发送至授权服务器 Verify
  3. 授权服务器对 Verify 用户进行身份验证。
  4. 授权服务器 Verify 获取用户的同意或授权。
  5. 授权服务器 Verify 将用户重定向回客户端,并返回一个身份令牌,若收到请求,还会返回一个访问令牌。
  6. 客户机验证标识令牌并检索用户的主体标识。
  1. 客户机准备一个包含必需请求参数的认证请求。
  2. 客户端将请求发送至授权服务器 Verify
  3. 授权服务器对 Verify 用户进行身份验证。
  4. 授权服务器 Verify 获取用户的同意或授权。
  5. 授权服务器 Verify 将用户重定向回客户端,并返回一个授权码,以及根据响应类型返回的一个或多个参数。
  6. 客户机通过使用令牌端点处的授权代码来请求响应。
  7. 客户机接收到响应,响应主体中包含标识令牌和访问令牌。
  8. 客户机验证标识令牌并检索用户的主体标识。
表 2. 资助类型(续)
特征 设备流 资源所有者密码凭证 JWT
描述 它允许使用 QR 码或发送到 URL 的用户代码对客户机进行授权。 需要进行客户机认证和用户认证,方法是使用客户机标识、客户机密钥、用户名和密码从令牌端点/令牌来检索访问令牌和标识令牌。 用户名和密码将根据 Cloud Directory 进行验证。 在 RFC7523 中进行定义。 允许客户机提供签名、加密或签名且加密的 JWT 以交换授权。 JWT 由授权服务器进行验证,JWT 中的身份用作授权的主题。
用例
用于此类客户机
  • 缺少用于执行基于用户代理的 OAuth 流的浏览器。
  • 输入约束到需要用户输入大量文本的程度是不可行的。
例如,智能电视、媒体控制台、数字图片框和打印机。
仅当没有其他流程可用时,才可以启用此授权类型。 可将其用于:
  • 与客户机有信任关系的资源所有者,例如设备操作系统或高度权限的应用程序。
  • 通过使用交互式表单可获取资源所有者凭证(用户名和密码)的客户机。
  • 通过将存储的凭证转换为访问令牌,将使用定向认证方案(如 HTTP Basic 或 Digest 认证)的现有客户机迁移到 OAuth。
授权服务器 (Verify) 与签发 JWT 的实体之间已建立信任关系。 客户机从发出实体的 JWT 获取 JWT,并将其提供给授权服务器以交换授权。 发出实体的 JWT 可能具有其自己的需求,必须在发出 JWT 前满足这些需求(例如,替代认证和授权检查)。
响应类型值 不适用 不适用 不适用
从授权端点返回所有令牌。
从令牌端点返回所有令牌。
不向用户代理显示令牌。
可以认证客户机应用程序。
生成刷新令牌。
来回通信
多数通信服务器到服务器
登录提示 (login_hint)
最长认证年限 (max_age) 不适用
工作流程
  1. 用户通过从设备发送客户标识来启动流程,请求用户代码和设备代码。
  2. 如果客户机标识有效,那么将返回验证 URI,用户代码和设备代码。
  3. 设备会显示用于输入浏览器的验证 URI 和用户代码,或者显示以供用户扫描的 QR 码。
  4. 设备不断尝试交换令牌的设备代码。
  5. 用户将手动扫描或键入验证 URI 和用户代码,以将用户代码发送到 OIDC 服务。
  6. 如果用户代码有效,那么将发送成功消息,设备代码将交换成访问令牌。
  1. 用户在信赖方的表单上输入其用户名和密码。
  2. 客户机将用户名、密码、客户机标识以及客户机密钥发送到令牌端点。
  3. 根据 Cloud Directory 来验证用户名和密码。
  4. 客户机将接收到一个响应,其主体中包含了标识令牌和访问令牌。
  1. 客户机获取 JWT(通过任意外部方式)并将其提供给端点。
  2. 验证 JWT,并抽取主题和其他属性。
  3. 客户机接收到响应,响应主体中包含标识令牌和访问令牌。
表 3. 资助类型(续)
特征 基于上下文的授权 刷新令牌 令牌交换
描述 API 驱动的流,在其中执行其他认证和授权检查。 在向客户机发出授权之前,可能需要多因子认证。 必须通过客户端 ID、客户端密钥和刷新令牌进行客户端和用户身份验证,以便从令牌端点 /token 获取一组新的访问令牌、身份令牌和刷新令牌。 刷新令牌必须属于同一个客户端 ID。 在此流程中,与该令牌关联的属性值不会被刷新。 定义在 RFC8693 中。 允许客户端提交一个令牌,以换取另一个令牌。
用例
  • 必须检测客户机以处理来自授权服务器的质询类型响应。

  • 客户端使用中提供的身份验证因素 Verify API 来获取一个 JWT,随后提交该 JWT 以继续后续流程。
  • 客户机必须通过“context”参数在请求中包含其他上下文信息。
使用此授权类型可获取一组新的访问令牌,并延长令牌的有效期。 这样既能保持访问令牌的有效期较短,又无需用户重新登录以获取新的访问令牌。
  • 冒充:指客户端以其他实体的身份访问资源。

  • 代理:指客户代表被授权实体行事。

响应类型值 不适用 不适用 不适用
从授权端点返回所有令牌。
从令牌端点返回所有令牌。
不向用户代理显示令牌。
可以认证客户机应用程序。
生成刷新令牌。
来回通信
多数通信服务器到服务器
登录提示 (login_hint)
最长认证年限 (max_age) 不适用
工作流程
  1. 客户端通过在请求中提供一些 `context` 来启动该流程,具体方式为 grant_type=Context-based authorization
  2. 客户机接收 DENY(如果在此上下文中不允许访问)或 CHALLENGE(通过返回的作用域标识)。
  3. 客户机使用与质询响应一起返回的访问令牌来访问可用的认证因子 API,包含标志以请求 JWT 作为完成因子结果。
  4. 将从已完成的因子返回的 JWT 作为发出的 JWT 持有者授权请求(还必须包含上下文)和令牌呈现回 /token
注意:
  • 根据配置的策略,在执行第一个因子后,可能需要其他因子。 这些因子可能需要执行第二个 CHALLENGE 和第二个认证因子。
  • 此授权类型需要编写定制访问策略并将其附加到应用程序。 此访问策略必须包含第一个因子认证规则以及(可选)任何 2FA 需求。
  1. 客户端检测到访问令牌即将过期或已过期,并希望获取新的访问令牌。
  2. 客户端将客户端凭据和刷新令牌发送至令牌端点。
  3. 已验证刷新令牌和客户端凭据。
  4. 客户端收到的响应正文中包含 ID 令牌、刷新令牌和访问令牌。
  1. 客户端生成或获取一个令牌,将其用作主体令牌。 此外,它还可以包含一个演员令牌。

  2. 向授权服务器的令牌端点发送请求,请求中包含主体令牌,并可选地包含操作者令牌。

  3. 授权服务器返回请求的令牌。