方法：承認の管理（アプリケーション）

はじめに

このガイドでは、Frame.io の **C2C アプリケーションの承認情報の更新、取り消し、保存を行う方法について説明します。

必要なもの

C2C の実装：セットアップガイドをまだ読んでいない場合は、目を通してから先へ進んでください。

当社のチームから提供された client_id と、認証および承認ガイドで使用したものと同じ device_id が必要です。このガイドを完了するには、access_token と refresh_token も必要です。

承認トークン

直前のガイドでは、ユーザーにプロジェクト上のデバイスを認証および承認してもらうことで新しい承認トークンを生成する方法を学習しました。 **

アクセストークンの有効期限は約 1 **時間です。デバイスのユーザーが 8 時間ごとにログインする必要性は排除したいことから、直前のガイドでは offline スコープをリクエストし、Frame.io **での承認時に更新トークンも取得しました。更新トークンは、現在のトークンの有効期限が切れた場合に新しいアクセストークンの生成に使用できます。

更新トークンの有効期限は 30 **日です。access_token の有効期間を制限することで、アクセストークンが漏洩した場合に生じうる潜在的な悪質行為を制限します。更新トークンの使用前に承認が更新されない場合、ユーザーには再認証が必要となります。 **

アクセストークンの更新

アクセストークンを必要とする API を呼び出して、次のレスポンスが返された場合は：

1
{
2
    "code": 401,
3
    "errors": [
4
        {
5
            "code": 401,
6
            "detail": "You are not allowed to access that resource",
7
            "status": 401,
8
            "title": "Not Authorized"
9
        }
10
    ],
11
    "message": "Not Authorized"
12
}

アクセストークンの有効期限が切れています。

トークンを更新するために、次の呼び出しを実行します。

$
curl -X POST https://applications.frame.io/oauth2/token \
>
    --form 'client_id=[client_id]' \
>
    --form 'scope=offline device.connect asset.create' \
>
    --form 'grant_type=refresh_token' \
>
    --form 'refresh_token=[refresh_token]' \
>
    | python -m json.tool

更新トークンだけではなく、これらすべての値を使用することで、漏洩した更新トークンでは新しい承認をオンラインで生成できないようになっています。誰かが統合になりすましてトークンを生成しようとしても、refresh_token と client_id **の両方が必要となります。

次のようなレスポンスが返されます。

1
{
2
    "access_token": "[access_token]",
3
    "expires_in": 3599,
4
    "refresh_token": "[refresh_token]",
5
    "scope": "offline device.connect asset.create",
6
    "token_type": "bearer"
7
}

これらは新しい承認トークンです。トークンを更新すると、古いトークンは機能しなくなるので、これらをいつでも参照できるようにしておいてください。 **

古い更新トークンを使用して今すぐ更新しようとすると、次のエラーが返されます。

1
{
2
    "error": "token_inactive",
3
    "error_description": "Token is inactive because it is malformed, expired or otherwise invalid. Token validation failed."
4
}

トークンが更新済みなので、既存の更新トークンの使用は無効です。

更新レスポンスの欠落

更新トークンを使用できるのは 1 **回のみです。Frame.io **を呼び出してトークンを更新したが、ネットワークエラーまたは予期しないパワーサイクルが原因でレスポンスを受け取りそこねた場合は、認証／承認フロー全体をやり直す必要があります。

これは不運な可能性ですが、面倒でも安全性を優先してください。

トークンの取り消し

Frame.io から「ログアウト」したいという状況が考えられます。例えば、撮影完了後のユーザーが接続状態を望まない場合です。アプリが悪い状態に陥り、クリーンな状態にリセットする必要がある場合も、承認の取り消しは良い慣行です。現在の承認を破棄する予定がある場合は、その承認の取り消しをアプリが試行する必要があります。

承認を取り消すには、次の呼び出しを実行します。

$
curl -X POST https://applications.frame.io/oauth2/revoke \
>
    --include \
>
    --form 'client_id=[client_id]' \
>
    --form 'token=[refresh_token]'

レスポンスにペイロードは含まれません。ここでは、コマンドで --include を使用して、返されたヘッダーを出力しています。呼び出しが成功した場合、ヘッダーはステータスコード 200 で始まっているはずです。

HTTP/2 200
...

トークンが取り消されたので、access_token を必要とするすべての Frame.io 呼び出しは Not Authorized を返します。ユーザーが Frame.io 接続を再度使用する場合は、Frame.io にログインしてプロジェクトに再度接続する必要があります。

トークンの保存

パワーサイクルをまたいで機能を維持するためには、承認ヘッダーを永続的に保存しておく必要があります。これは、ファイル、データベースまたは独自のクラウドで実現できます。承認トークンを保存するためのガイドラインは次のとおりです。

ユーザーによるトークンの表示やアクセスを許可しないでください。ユーザーによる自身のトークンの表示または取得は許可されるべきものではありません。これらは、アプリのみで管理する必要があります。

保管するトークンは暗号化してください。client_id と同様、アクセストークンと更新トークンは、可能な場合は保存時に暗号化して、鍵の盗難を防ぐ必要があります。承認鍵をプレーンテキストで保存しないでください。

**承認トークンを client_id と同じファイルに保存しないでください。**Python アプリの例では client_id と device_id を承認トークンと同じファイルに保存しています。これは、デモでは問題ありませんが、本番環境のコードでは適切な慣行ではありません。client_id と device_id **はデバイスの静的な値であり、これらが失われるとデバイスが機能を停止します。

承認トークンは静的ではなく、デバイスの有効期間中に何度も書き直しが必要となります。新しいトークンを使用してファイルを更新している最中にデバイスが電源を喪失すると、そのファイルが破損して client_id **が失われ、以降、そのデバイスを Frame.io で再認証できなくなる可能性があります。トークンを分けておけば、最悪の場合でも、ユーザーは Frame.io に再度ログインすれば済みます。

トークンの保管に最適な場所は、SQLite のような実績あるデータベースですが、少なくとも承認データを他の値と分けておく必要があります。

次のステップ

まだの場合は、当社チームにお問い合わせください。そのうえで、次のガイドに進んでください。ご連絡をお待ちしております。