OAuth 2 アプリケーション

OAuth 2 コード認証フロー

概要

Frame.io は、OAuth 2 アプリケーションの作成および管理をサポートしています。開発者トークンとは異なり、OAuth 2 アプリを使用すると、Frame.io ユーザーは安全なログインを介して自分の資格情報を付与できます。その後、アプリはそのユーザーの代理で動作できます。

簡単に言えば、OAuth 2 アプリは、個々のユーザーのコンテキストおよびアクセスが重要な統合シナリオに最適です。

OAuth 2 コードフロー

基本的なシーケンス

大まかに言えば、OAuth 2 には、次の 3 つの関係者があります。

  1. ユーザー（この場合、Frame.io ログインを持つすべてのユーザー）
  2. クライアントアプリケーション（外部 OAuth2.0 アプリ）
  3. 資格情報サーバー（この場合、Frame.io）

OAuth 2 のコードフローは、次を通じた、4 ステップのプロセスです。

  1. アプリケーションが、ユーザーにログイン画面を表示します
  2. ユーザーが自分の資格情報を入力すると、サーバーに直接、移動します
  3. ログインに成功すると、サーバーが、事前設定されたアクセススコープセットをアプリケーションに付与するかどうかをユーザーに確認するページを返送します
  4. ユーザーが同意した場合、サーバーが、リクエストされたスコープで、ユーザーの代理で動作するために使用できるトークンをアプリケーションに送信します。

このようにして、クライアントアプリケーションは、ユーザーの許可ありで、（重要なことですが）ユーザーの実際の資格情報を表示または処理することなく、ユーザーの代理で安全にアクションを実行できます。

コールバックサイクル

上記のシーケンスは、それぞれ独自のルートを持つ 2 つのサービスをホスティングするサーバー（Frame.io）に依存します。

サービスURLメソッド説明
Authhttps://applications.frame.io/oauth2/authGETOAuth クライアントアプリケーションに関する情報が与えられると、サーバーで auth フローを呼び出します。
Tokenhttps://applications.frame.io/oauth2/tokenPOSTauth ステップからの情報が与えられると、ユーザーの代理でトークンを取得します。

このサイクルでの OAuth 2 アプリケーションの役割は、サーバーに身元を明かし、これらの 2 つのリクエストを行うことです。

簡単な例

これまでに OAuth 2 アプリを構築したことがありますか？

OAuth 2.0 に関する残りの実装まわりに精通している場合は、次の例を見るだけで開始できるかもしれません。もう少し詳しく知りたい場合は、こちらを参照してください。

アプリのセットアップ

  1. Frame.io 資格情報を使用して Frame.io 開発者ポータルにログインし、左側のリンクを使用して OAuth アプリに移動し、「新規」をクリックしてアプリの設定を開始します。
  2. 次の画面で、アプリの名前およびリダイレクト URI を入力し、「スコープ」を選択し、PKCE を使用するかどうかを選択します。
  3. 保存すると、新しいアプリ設定が表示されます。
PKCE について

Proof Key for Code Exchange（「pixie」）設定を使用すると、アプリがトークンを client_secret 指定なしでリクエストできるようになります。したがって、client_secret は指定しません。また、アプリのコールバックサイクルでトークンを POST する際に、Authorization ヘッダーを含めないでください。ただし、コールバックに client_id を含める必要があります。含めないと、リクエストが拒否されます。

PKCE はどのような場合に使用すべきですか？

一般に、PKCE を使用することに悪影響はなく、推奨され、好ましいアプローチです。OAuth2.0 クライアントアプリケーションを開発する場合は、次の 2 つのコンテキストのいずれかでコード認証フローを実装します。

  • プライベート：フローがサーバーサイド言語（Python、Java）で実装されるので、制御するサーバーで client_secret を安全に管理できます。
  • パブリック：フローは、クライアントサイド言語（Javascript）で実装されるか、エンドユーザーが制御するクライアントデバイス（iOS、Android）に直接、実装されます。

一般的な規則として、アプリケーション開発者がシークレット交換に関連するすべてのネットワークトラフィックを確認および制御できない場合は、アプリケーションを「パブリック」と見なすことができます。つまり、クライアントサイドアプリケーションに加えて、モバイルデバイスアプリケーション、組み込みデバイス、またはエンドユーザーのネットワーク上に存在するあらゆるデバイス（AppleTV、Roku など）は、パブリックと見なす必要があります。

プライベートコンテキストでは、PKCE を使用できます。 ** パブリックコンテキストでは、PKCE を使用する必要があります。 **

OAuth 2 アプリケーションの構築

Frame.io でアプリ設定を用意できたので、上記の表に従って、コールバックサイクルを完了するための 2 つの重要なルートを処理するようにコールバックサーバーを設定できます。

アプリケーションの構築方法について詳しくは、「OAuth 2 アプリの構築」を参照してください。