> This page is for プラットフォーム, version レガシー.
> For other versions, use one of these documentation indexes:
> - V4 (default): https://next.developer.frame.io/platform/v4/llms.txt
> - V4 Experimental: https://next.developer.frame.io/platform/v4-experimental/llms.txt
> - レガシー: https://next.developer.frame.io/platform/v2/llms.txt

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://next.developer.frame.io/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://next.developer.frame.io/_mcp/server.

# OAuth 2 コード認証フロー

## 概要
Frame.io は、OAuth 2 アプリケーションの作成および管理をサポートしています。[開発者トークン](/getting-started/authentication#developer-tokens)とは異なり、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| メソッド| 説明|
|----------|----------|----------|----------|
| Auth| `https://applications.frame.io/oauth2/auth`| `GET`| OAuth クライアントアプリケーションに関する情報が与えられると、サーバーで auth フローを呼び出します。|
| Token| `https://applications.frame.io/oauth2/token`| `POST`| auth ステップからの情報が与えられると、ユーザーの代理でトークンを取得します。|

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

## 簡単な例
<Info title="これまでに OAuth 2 アプリを構築したことがありますか？">
OAuth 2.0 に関する残りの実装まわりに精通している場合は、次の例を見るだけで開始できるかもしれません。もう少し詳しく知りたい場合は、[こちら](/oauth-2-applications/building-an-oauth2-app)を参照してください。
</Info>

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

<Info title="PKCE について">
**P**roof **K**ey for **C**ode **E**xchange（「pixie」）設定を使用すると、アプリがトークンを `client_secret` 指定なしでリクエストできるようになります。したがって、`client_secret` は指定しません。また、アプリのコールバックサイクルでトークンを `POST` する際に、`Authorization` ヘッダーを含めないでください。ただし、**コールバックに `client_id` を含める必要があります**。含めないと、リクエストが拒否されます。
</Info>

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

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

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

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

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

アプリケーションの構築方法について詳しくは、「[OAuth 2 アプリの構築](/oauth-2-applications/building-an-oauth2-app)」を参照してください。