OAuth2.0 配置和技术细节

在本文中，我们将深入探讨 Tulip 如何为连接器身份验证实现 OAuth 的技术细节。OAuth 功能强大，但也增加了一些复杂性。本指南旨在解决与 Tulip 支持的内容及其集成方式有关的任何技术问题。

注意：客户端凭证流程与授权代码流程有一些不同。步骤 1 和 2 与客户证书流程无关。

Tulip 授权代码流程

:::(Warning) (内部部署服务）授权和令牌端点必须可访问云，以便 Tulip 为连接器执行身份验证：::：

测试连接器或在应用程序中运行连接器功能时，Tulip 会启动身份验证流程。

1.重定向到授权服务器：

Tulip 应用程序将用户连同特定参数重定向到授权服务器（AS），这些参数包括 response_type（为授权代码流设置为 "代码"）、client_id（在连接器用户界面中分配）、redirect_uri（由 Tulip 预定义）、scope 和 audience（在用户界面中设置）以及 state（一个随机字符串，用于防止跨站请求伪造攻击）。

示例：GET /authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=SCOPE&audience=AUDIENCE&state=STATE

2.用户同意：

授权服务器会对用户进行身份验证，并向其显示同意屏幕。用户可查看请求的权限，并决定是否允许访问第三方应用程序。

:::(Warning) (注）在给定连接器的配置中，"跳过用户同意提示 "控件可让您控制授权请求的提示属性。禁用该控制时，将使用 "同意 "值，启用时将使用 "登录 "值。

如果需要提示属性的其他值，请联系 support@tulip.co，我们将为该属性启用更多选项：

3.授权代码：

如果用户同意，授权服务器将生成一个授权码，并将用户连同授权码一起重定向回 Tulip。状态参数也包括在内，允许客户端验证响应的完整性。该状态参数必须与步骤 1 中传递的状态参数相匹配。

重定向到客户端重定向 URI 的示例：

REDIRECT_URI?code=AUTHORIZATION_CODE&state=STATE 4.

4.令牌请求：

客户端现在有了授权代码，并用它向授权服务器的令牌端点发出服务器到服务器的安全请求。客户端包括 grant_type（设置为 "authorization_code"）、client_id、client_secret（只有客户端和授权服务器知道的秘密）、redirect_uri 和授权代码。

令牌请求示例

POST /token Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI&client_id=CLIENT_ID&client_secret=CLIENT_SECRET ```.

5.访问令牌响应：

如果授权码有效，授权服务器将回复一个访问令牌和一个刷新令牌。客户端在代表用户向受保护的 API 发出请求时，会使用访问令牌对自己进行身份验证。

令牌响应示例

{ "access_token"："ACCESS_TOKEN", "token_type"："Bearer", "expires_in"：3600, "refresh_token"："REFRESH_TOKEN", "scope"："SCOPE" } 6.

6.访问资源服务器

现在，Tulip 可以使用获得的访问令牌代表用户向资源服务器（API）发出授权请求。访问令牌通常包含在 HTTP 请求的授权头中。

示例 API 请求：GET /api/resource 授权：Bearer ACCESS_TOKEN

使用刷新令牌管理令牌有效期

授权服务器通常会为令牌设置过期日期，以规范访问权限，过期窗口因接口系统而异。然而，由于持续的用户身份验证会破坏 Tulip 应用程序的用户体验，因此短效令牌带来了挑战。

为了解决这个问题，OAuth 支持刷新令牌。虽然刷新令牌是可选的，但我们强烈建议使用它们，因为它们允许 Tulip 无缝刷新令牌，无需操作员手动输入，从而简化了用户体验。

Tulip 如何管理令牌刷新

当 Tulip 检测到访问令牌已过期时，它会自动尝试使用相关的刷新令牌来获取新令牌。其主要目的是尽量减少用户的重新认证。以下步骤概述了 Tulip 执行的逻辑：

1. 过期检测：

2. Tulip 根据认证流程步骤 5中收到的expires_in属性识别过期令牌。

3. 令牌流尝试：

4. Tulip 使用refresh_token 授权类型启动令牌流，取代初始身份验证流中使用的authorization_code授权类型。

5. 令牌验证：

6. 如果获得新令牌，Tulip 会将其存储起来，并继续执行用户请求的连接器功能。

   • 如果成功，数据将提供给 Tulip 应用程序运行时。
   • 如果新令牌因 OAuth 错误而失败，Tulip 会重试该过程最多 5 次，每次都会返回到步骤 1。
   • 如果新令牌因任何其他错误而失败，播放器运行时将显示错误。

7. 处理令牌缺失：

8. 如果没有提供新的令牌，Tulip 会提示播放器中的用户进行身份验证，启动整个身份验证过程。

9. 完成后，将执行连接器函数并返回数据。

通过实施刷新令牌，Tulip 可智能管理令牌到期和更新，最大限度地减少工作流程中断，从而确保更流畅的用户体验。

更多阅读

• Tulip 连接器主机介绍
• 连接器快照
• OAuth2.0 解释