Facebookログイン

アクセストークンポータビリティ

このガイドでは、ニーズに応じた構成でアプリをビルドできるように、ポータビリティの一般的なシナリオのいくつかを説明します。

さまざまなアプリタイプでのトークンの使用

アクセストークンは移植可能です。トークンを取得したら、そのトークンをどのマシンからでも使用できます。ウェブインターフェイス、モバイルクライアント、サーバーをまとめるとき、異なる使用可能な構成を組み合わせたものを取得できます。しかし、これらの異なる構成には、機能とセキュリティの面でそれぞれ独自のメリットとデメリットがあります。

設定メリットデメリットセキュリティに関する注

ログインとAPIリクエストはウェブクライアントで行われる(短期トークン)。

シンプルな実装。

オフライン投稿なし。

長期アクセスなし。

認証の回数が多い。

ログインとAPIリクエストはネイティブモバイルクライアントまたはウェブクライアントで行われる(長期トークン)。

認証の回数が多くない。

オフライン投稿なし。

ログインとAPIリクエストはウェブクライアントで行われる(コード交換後の長期トークン)。

特定の状況における追加のセキュリティ。

実装が困難。

オフライン投稿なし。

特定の状況においてのみ有益。

ログインはネイティブモバイルクライアントまたはウェブクライアントで行われる。

APIリクエストは(長期トークンを使用して)サーバーで行われる。

オフライン投稿。

追加のセキュリティ機能がサーバーベースの呼び出しで利用可能。

クライアントは、どのプロキシ呼び出しでもサーバーを呼び出す必要がある。

すべての呼び出しにappsecret_proofを使用する。

ログインはネイティブモバイルクライアントまたはウェブクライアントで行われる。

APIリクエストはサーバーまたはクライアントで行われる。

オフライン投稿

クライアントからのユーザー主導投稿

実装が困難

サーバーから行われるすべての呼び出しにappsecret_proofを使用する。

ネイティブまたはウェブクライアントログインとAPIリクエスト

これは最もシンプルな構成で、認証とAPIリクエストはクライアントで行われます。このモデルでは3通りの構成が可能です。

  1. ネイティブまたはウェブクライアントが認証を行って、返された短期または長期トークンを使用して呼び出しを行います。
  2. ウェブクライアントが認証を行い、サーバー経由で長期トークン用の短期トークンを交換します。このトークンはウェブクライアントに送り返され、ウェブクライアントはそのトークンを使用してAPI呼び出しを行います。
  3. ウェブクライアントが認証を行い、サーバー経由で長期トークン用の短期トークンを交換します。サーバーはコードをクライアントに送ります。クライアントは長期トークンのコードを交換し、それを用いてAPI呼び出しを行います。この構成はほとんど使用されません。

ネイティブまたはウェブクライアントのフロー

長期トークンを使用したウェブクライアントのフロー

コード交換を使用したウェブクライアントのフロー

クライアントのログインとサーバーAPI呼び出し

この一般的な構成では、認証はクライアントで行われますが、すべてのAPI呼び出しはクライアントに代わってサーバーで行われます。サーバーはappsecret_proofパラメーターを使用することで、呼び出しを行う際にセキュリティをさらに強化できます。

クライアントのログインとクライアントまたはサーバーのAPI呼び出し

この構成は、上記の方法の組み合わせです。

SDKを使用したアクセストークンの設定

SDKのAPI呼び出しで使用するアクセストークンを指定する方法は何通りかあります。