OAuth 2 代码授权流程
OAuth 2 代码授权流程
概述
Frame.io 支持创建和管理 OAuth 2 应用程序。与开发者令牌不同，OAuth 2 应用程序使任何 Frame.io 用户都能通过安全登录授予其凭据，之后应用程序便可以代表该用户执行操作。
简单来说，OAuth 2 应用程序最适合那些个人用户的上下文和访问权限至关重要的集成场景。
OAuth 2 授权代码流程
基本顺序
从很高的层面来看，OAuth 2 涉及以下三方：
- 用户（在我们的示例中：任何拥有 Frame.io 登录凭据的人员）
- 客户端应用程序（外部 OAuth2.0 应用程序）
- 凭据服务器（在我们的示例中：Frame.io）
OAuth 2 的授权代码流程是一个四步过程，通过该过程：
- 应用程序向用户展示登录界面
- 用户输入其凭据，这些凭据直接发送到服务器
- 如果登录成功，服务器会返回一个页面，询问用户是否确认向应用程序授予一组预配置的访问权限范围
- 如果用户同意，服务器会向应用程序发送一个令牌，该令牌可用于在请求的权限范围内代表用户执行操作。
通过这种方式，客户端应用程序可以在获得用户许可的情况下，安全地代表用户执行操作，并且（重要的是）始终无需查看或处理用户的实际凭据。
回调循环
上述顺序依赖于服务器 (Frame.io) 托管两个服务，每个服务都有自己的路由：
OAuth 2 应用程序在此循环中的角色是向服务器标识自己的身份，并发出这两个请求。
快速示例
您之前构建过 OAuth 2 应用程序吗？
如果您已熟悉 OAuth2.0 的其他基础流程，下面的示例可能足以让您开始上手。如果您想了解更多详情，请在此处查看更详细的指南。
设置您的应用程序
- 使用您的 Frame.io 凭据登录 Frame.io 开发者门户，使用左侧的链接导航到 OAuth 应用程序，然后点击新建开始设置您的应用程序。
- 在后续界面上，为您的应用程序输入名称和重定向 URI，选择您的权限范围，并选择是否使用 PKCE。
- 保存后，您现在应该可以看到新的应用程序配置了。
关于 PKCE
代码交换的证明密钥 (“pixie”) 设置将使您的应用程序能够在不提供其 client_secret 的情况下请求令牌。因此，您将不会收到 client_secret，并且在您的应用程序回调循环中，POST 请求令牌时不应包含 Authorization 标头。也就是说，您需要在回调中包含您的 client_id，否则您的请求将被拒绝。
我应该何时使用 PKCE？
总的来说，使用 PKCE 没有负面副作用，并且是推荐和首选的方法。在开发 OAuth2.0 客户端应用程序时，您将在以下两种情况之一中实施代码授权流程：
- 私有：您的流程是以服务器端语言（Python、Java）实施的，并且您可以在自己控制的服务器中安全地管理您的
client_secret。- 公开：您的流程是以客户端语言 (JavaScript) 实施的，或者直接在终端用户控制的客户端设备（iOS、Android）上实施。
一般来说，如果您（应用程序开发者）无法查看和控制与密钥交换相关的所有网络流量，那么您可以将应用程序视为“公开”。这意味着，除了客户端应用程序之外，移动设备应用程序、嵌入式设备，或任何位于终端用户网络上的设备（AppleTV、Roku 等）都应被视为“公开”。
在私有环境中，您 可以 使用 PKCE。在公开环境中，您 必须 使用 PKCE。
构建您的 OAuth 2 应用程序
现在，您在 Frame.io 中已有一个应用程序配置，您可以着手设置回调服务器来处理完成回调循环所需的两个关键路由，如上表所示。
有关如何构建应用程序的更多详细信息，请参阅构建 OAuth 2 应用程序。