Skip to main content

2026 年 7 月 17 日

创建 OAuth 2.0 应用并对应用程序进行身份验证

Omnissa Connect 使用 OAuth 2.0,以便您可以为应用程序授予对组织中受保护资源进行安全委派访问的权限。Omnissa Connect 支持 Web 应用程序访问(应用用户授权访问)和服务器到服务器交互(直接向您的应用颁发访问令牌)。

什么是 OAuth 2.0?

OAuth 2.0 是一种授权协议,支持为您的应用程序授予对资源的安全访问权限。您的客户端通过访问令牌获得授权。访问令牌具有一个范围,用于定义令牌可以访问哪些资源。有关 OAuth 2.0 的信息,请参阅 OAuth 规范,网址为:https://tools.ietf.org/html/rfc6749

OAuth 2.0 如何与 Omnissa Connect 配合使用

Omnissa Connect 支持使用不同授权类型的应用授权。

  • 适合服务器到服务器应用的客户端凭据
  • 适合 Web 应用的授权码
  • 适合本机/移动应用的使用授权码的公共客户端

OAuth 应用的违规策略文档

有关如何为 OAuth 应用创建访问违规策略的详细信息,请参阅监管主题。

服务器到服务器 OAuth 应用示例

假设您是一名有权访问 Omnissa 服务的所有者。您开发了一个可帮助您进行股票交易的应用程序。您将该应用称为 Trading 1.0。您想在由另一个 Omnissa 服务管理的虚拟机上运行该应用,但首先,您必须使用 API 和自动化脚本为您的应用授权,该脚本位于您的组织托管脚本的位置。

  1. 您在 Omnissa Connect 中创建 OAuth 2.0 应用。
    • 将此场景视为向 Omnissa Connect(授权服务器)注册您的 Trading 1.0 应用(在 Omnissa 管理的虚拟机上运行)。
    • 在 Connect 中,可以通过在身份管理 > OAuth 应用程序 > 拥有的应用选项卡中选择创建新 OAuth 应用并执行一系列步骤,来启动应用的创建。
    • 在该过程结束时,Omnissa Connect 会颁发包含客户端密钥和客户端 ID 的客户端凭据。
    • 您可以将这些凭据粘贴到自动化脚本内的 API 中,以从 Connect 请求访问令牌。
  2. 在 Connect 中,授予您的应用对 Omnissa Connect 组织的访问权限。
    • 您可以通过将已注册的应用 Trading 1.0 添加到 Omnissa Connect 中的组织来授予访问权限。这是添加过程的最后一步。
    • 完成此添加操作将允许应用访问您组织中的服务和资源。
  3. 运行 Trading 1.0 客户端应用时,它会从授权服务器,即 Omnissa Connect 请求访问令牌。
    • 获得授权后,授权服务器 Omnissa Connect 会向客户端应用发送访问令牌,您的客户端应用便可以请求访问您的 Omnissa 资源。

谁可以创建和管理 OAuth 应用?

作为所有者用户或具有开发人员角色的成员用户,您可以创建和管理 OAuth 应用。

您还可以管理组织中的其他所有者创建或添加的 OAuth 应用。

服务器到服务器 - 客户端凭据

如果您的应用程序需要直接访问另一台服务器,而无需用户授权,您可以在 Connect 中创建服务器到服务器应用。此选项基于 OAuth 2.0 客户端凭据授权类型。在此流程中,您的应用使用其 OAuth 凭据从 Omnissa Connect 检索访问令牌。

范围

范围在服务器到服务器应用中特别重要。范围提供了一种方法,可对客户端有权访问组织中的哪些区域实施控制,具体而言,组织中的哪个角色、哪些服务和权限级别。

作为所有者,您可以向任何组织添加服务器到服务器应用。因此,虽然您可以为应用程序指定许多服务的广泛访问权限,但访问权限最终由组织中包含的服务决定。向其添加 OAuth 应用的组织不包含应用范围所含的服务时,您会收到通知。

必备条件

您必须具有在组织中添加和管理 OAuth 应用所需的权限。

过程

  1. 登录到 Omnissa Connect,然后转到身份管理 > OAuth 应用程序
  2. 选择拥有的应用选项卡,然后选择创建新的 OAuth 应用
  3. 选择服务器到服务器应用,然后选择继续
    使用服务器到服务器应用将令牌直接颁发给您的应用。
  4. 通过输入名称和描述来注册客户端。
  5. 为新 OAuth 应用设置访问令牌 TTL 值。
    访问令牌生存时间 (TTL) 定义了访问令牌的有效时间段。
    • 默认访问令牌 TTL 时间为 30 分钟。
    • 可以设置的最长访问令牌 TTL 时间为 300 分钟(5 小时)。
    • 可以设置的最短访问令牌 TTL 时间为 1 分钟。
  6. 定义范围。
    • 范围提供了一种方法,可对客户端有权访问组织中的哪些区域实施控制,具体而言,组织中的哪个角色、哪些服务和权限级别。
  7. 选择创建以生成客户端凭据。
  8. 在"已创建 OAuth 应用"弹出窗口中,复制凭据或下载 JSON 文件,然后选择继续
    • 您应将凭据存储在一个安全的位置。
    • 将凭据粘贴到自动化脚本中的应用身份验证 API 中,或将凭据 JSON 文件安全地存储在某个位置,以便应用可以安全地使用它来检索访问令牌。
    • 客户端应用必须验证访问令牌。
    • 验证后,应用即可请求访问令牌以访问资源。
  9. (可选)在 Connect 中,将应用添加到活动组织。
    • 完成此步骤将允许应用访问 Connect 组织中的服务和资源。
    • 您可以跳过此步骤,稍后将应用添加到此组织和其他组织。

Web 应用 - 授权码

如果您的应用是在服务器上运行的常规 Web 应用并且需要用户授权,则可以在 Connect 中创建 Web 应用。此选项基于 OAuth 2.0 授权码授权类型

在此流程中,用户先对您的应用进行授权,然后通过授权请求 URL(该 URL 用于检索授权码)来访问任何资源。您的应用将以授权码交换来自 Connect 的访问令牌。有了该访问令牌,用户便可通过应用访问 Omnissa 资源。应用也可以选择从 Connect 检索刷新令牌。

必备条件

您必须具有在组织中添加和管理 OAuth 应用所需的权限。

过程

  1. 登录到 Omnissa Connect,然后转到身份管理 > OAuth 应用程序
  2. 选择拥有的应用选项卡,然后选择创建新的 OAuth 应用
  3. 选择 Web/移动应用,然后选择继续
  4. 输入应用程序详细信息以注册您的应用程序。
    • 键入新 OAuth 应用的名称和描述。
  5. 至少输入一个重定向 URI。
    • 用户对您的客户端进行授权后,授权服务器会将用户重定向回您的客户端以访问通过访问令牌指定的 URI。
    • 最好添加多个 URI。
    • 使用格式 http://acme.com。
  6. 指定访问令牌的时间范围。
    • 默认访问令牌生存时间 (TTL) 设置为 30 分钟。
    • 可以设置的最大值为 300 分钟(5 小时)。
    • 可以设置的最小值为 1 分钟。
  7. 如果您希望访问令牌持续授权请求,请选择颁发刷新令牌复选框并设置刷新令牌 TTL 值。
    • 默认刷新令牌 TTL 为 30 分钟。
    • 可以设置的最大值为 300 分钟(5 小时)。
    • 可以设置的最小值为 1 分钟。
  8. 定义范围。
    • 范围提供了一种方法,可对客户端有权访问组织中的哪些区域实施控制,即哪些服务和权限级别。
  9. 选中 OpenID 复选框,获取有关为应用授权的用户的信息。
  10. 选择创建以生成客户端凭据。
  11. 复制凭据或下载包含您凭据的 JSON 文件。
    • 您应将凭据存储在一个安全的位置。
    • 将 Connect 客户端凭据粘贴到应用的身份验证 API 中,或将凭据 JSON 文件安全地存储在某个位置,以便应用可以安全地使用它来从 Connect 检索访问和刷新令牌。
  12. 选择继续

移动应用 - 使用授权码的公共客户端

诸如原生应用和移动应用之类的公用客户端无法维护客户端密钥的机密性。将 OAuth 2.0 用于移动应用时,Omnissa Connect 会生成应用 ID,并使用代码交换证明密钥 (PKCE) 提供额外的验证。

PKCE 是一种保护未使用客户端密钥的公共客户端的技术。有关详细信息,请参阅 OAuth 规范《用于 OAuth 公共客户端代码交换的证明密钥》,网址为:https://datatracker.ietf.org/doc/html/rfc7636

在此流程中,用户先对您的应用进行授权,然后通过授权请求 URL(该 URL 必须包括 Connect 生成的应用 ID 以检索授权码)来访问任何资源。您的应用将以授权码交换来自 Connect 的访问令牌。有了该访问令牌,用户便可通过应用访问 Omnissa 资源。应用也可以选择从 Connect 检索刷新令牌。

必备条件

您必须具有在此组织中添加和管理 OAuth 应用所需的权限。

过程

  1. 登录到 Omnissa Connect,然后转到身份管理 > OAuth 应用程序
  2. 选择拥有的应用选项卡,然后选择创建新的 OAuth 应用
  3. 选择 Web/移动应用,然后选择继续
  4. 输入应用程序详细信息以注册您的应用程序。
    • 键入新 OAuth 应用的名称和描述。
  5. 至少输入一个重定向 URI。
    • 用户对您的客户端进行授权后,授权服务器会将用户重定向回您的客户端以访问通过访问令牌指定的 URI。
    • 最好添加多个 URI。
    • 使用格式 http://acme.com。
  6. 指定访问令牌的时间范围。
    • 默认访问令牌生存时间 (TTL) 设置为 30 分钟。
    • 可以设置的最大值为 300 分钟(5 小时)。
    • 可以设置的最小值为 1 分钟。
  7. 如果您希望访问令牌持续授权请求,请选择颁发刷新令牌并设置刷新令牌 TTL 值。
    • 默认刷新令牌 TTL 为 30 分钟。
    • 可以设置的最大值为 300 分钟(5 小时)。
    • 可以设置的最小值为 1 分钟。
  8. 定义范围。
    • 范围提供了一种方法,可对客户端有权访问组织中的哪些区域实施控制,即哪些服务和权限级别。
  9. 选中 OpenID 复选框,获取有关为应用授权的用户的信息。
  10. 选择创建以生成凭据。
  11. 复制应用程序 ID 或下载包含应用程序 ID 的 JSON 文件。
    • 您应将这些凭据存储在一个安全的位置。
    • 将应用 ID 置于应用的身份验证 API 中,或将应用 ID JSON 文件安全地存储在某个位置,以便应用可以安全地使用它来从 Connect 检索访问和刷新令牌。
  12. 选择继续

如何管理 OAuth 2.0 应用程序

作为所有者,您可以创建、查看和修改组织中 OAuth 应用的详细信息。您还可以管理组织中的其他所有者创建或添加的 OAuth 应用。授予对在您拥有所有者角色的任何组织中创建的应用的访问权限。

目标执行操作
查看有权访问您组织的 OAuth 应用。- 选择身份管理 > OAuth 应用
- 在已分配角色的应用选项卡上,查看在其他组织中创建并有权访问您组织的应用。
添加在其他组织中创建的 OAuth 应用。1. 选择身份管理 > OAuth 应用,然后选择已分配角色的应用选项卡。
2. 选择添加 OAuth 应用
3. 要确定您要添加的 OAuth 应用,请选择输入应用 ID按组织搜索
4. 选择继续

5a. 如果选择了使用 OAuth 应用程序的 ID 确定 OAuth 应用程序,系统会提示您输入 OAuth 应用程序 ID。

5b. 如果选择了通过创建 OAuth 应用的组织确定 OAuth 应用,则系统会提示您先从下拉菜单中选择组织名称,然后从该组织中可用的 OAuth 应用列表中选择 OAuth 应用。组织下拉菜单仅显示您具有所有者访问权限的组织。

6. 查看应用详细信息,然后选择添加
移除在其他组织中创建并有权访问您组织的 OAuth 应用。1. 选择身份 管理 > OAuth 应用,然后选择已分配角色的应用选项卡。
2. 从显示的 OAuth 应用程序列表中,选择要阻止其访问您组织的应用程序。
3. 选择移除
查看在您的组织中创建的应用程序。选择身份管理 > OAuth 应用,然后选择拥有的应用选项卡。

您可以在此处查看在您的组织中创建的所有应用程序。
在您的组织中创建新的 OAuth 应用。1. 转到身份 管理 > OAuth 应用,然后选择拥有的应用选项卡。
2. 选择创建新的 OAuth 应用
3. 选择要添加的应用类型。
管理在您的组织中创建的 OAuth 应用。选择身份管理 > OAuth 应用,然后选择拥有的应用选项卡。选择要管理的应用:

- 要修改 OAuth 应用,请选择编辑
注意:如果更改应用的范围,则位于其他组织中的应用实例不会包含所做的更改。要更新范围,所有者必须从其组织中移除该应用,然后重新添加该应用,或者编辑该应用以反映更新的范围。

- 要移除应用,请选择删除
注意:此操作无法恢复。使用这些客户端凭据的任何应用程序将无法再访问受保护的资源,且凭据将失效。

- 通过选择应用并选择分配角色,您可以添加已在组织中创建但尚未授予组织访问权限的服务器到服务器应用。如果需要,您可以修改应用范围所允许的可用组织和服务角色,然后选择添加

- 如果要先修改应用的范围,请选择编辑,然后对组织和服务角色进行所需的更改。准备就绪后,选择添加到此组织

注意:无法将 Web/移动应用添加到组织。

是否可以重新生成应用密钥?

可以,作为所有者,您可以重新生成组织中 OAuth 应用的应用密钥。如果创建 OAuth 应用的所有者离开您的公司,而您想继续运行该应用,此方法会非常有用。

是否可以使用 API 令牌身份验证,而不使用 OAuth 应用?

可以,如果 API 在授权过程中要求用户是经身份验证的实体,则必须使用 API 令牌。

OAuth 应用与 API 令牌有何区别?

您可以使用 OAuth 应用和 API 令牌与 Omnissa Connect API 进行交互。有关 Connect 中此身份监管和管理功能的详细信息,请参阅 API 令牌

重要提示:使用服务器到服务器类型的 OAuth 应用自动调用您的服务之前,必须先查阅相关的 API 文档。

API 令牌由组织中的用户颁发,并与用户的帐户以及从中生成 API 令牌的组织相关联。只有创建 API 令牌的用户才能执行 API 令牌管理。

OAuth 应用由组织中的用户创建后,将充当服务器到服务器交互中的实体,并可在多个组织中使用。OAuth 应用的所有者是创建该应用的组织,可由作为所有者或具有开发人员角色的成员的用户进行管理。有关管理角色请求的详细信息,请参阅请求主题。

您可以使用 OAuth 应用和 API 令牌自动处理与 API 交互的过程。不同之处在于,API 令牌在访问令牌中包含用户帐户,而 OAuth 应用在执行授权时无需用户帐户。选择使用 API 令牌或 OAuth 应用进行 API 调用时,必须考虑交互中涉及的 API 服务的特定要求。

一些 API 要求用户帐户为经身份验证的实体,而其他一些 API 则不作要求。例如,如果您在 Omnissa Connect 中调用 API 以获取组织的订阅信息,则可以使用服务器到服务器类型的 OAuth 应用或 API 令牌调用 API 服务,因为它不要求通过用户凭据进行身份验证,并且也接受客户端凭据。如果组织的用户使用 API 更新其密码,则该 API 要求用户充当身份验证实体。

此页面对您有帮助吗?

对本主题提供反馈

本主题对您有帮助吗?

请勿填写任何个人信息或机密信息。

正在生成链接…