ドキュメント web フックの認証

認証

Adobe Workfront ドキュメントの web フックでは、OAuth2 と ApiKey の 2 種類の認証形式をサポートしています。どちらの場合も、Workfront は API を呼び出す際に、認証トークンをヘッダーに入れて渡します。

OAuth2

OAuth2 を使用すると、Workfront は、承認済み API 呼び出しをユーザーの代わりに web フックプロバイダーに対して行うことができます。その前に、ユーザーは外部ドキュメントプロバイダーアカウントを Workfront に接続し、Workfront への

アクセス権を付与して、ユーザーの代わりに操作できるようにする必要があります。このハンドシェイクプロセスは、ユーザーごとに 1 回だけ行われます。仕組みは次のとおりです。

  1. まずユーザーが自分のアカウントに web フック統合を接続します。現在、これを行うには、「ドキュメントの追加」ドロップダウン/サービスを追加/カスタム統合名をクリックします。

  2. Workfront により、ユーザーは認証 URL に移動します。ここでは、外部ドキュメントプロバイダーへのログインを求められる場合があります。このページは、web フックプロバイダーまたは外部ドキュメント管理システムによってホストされています。その際、Workfront は認証 URL に「state」パラメーターを追加します。同じ値を以下の手順で Workfront の戻り URI に追加することにより、この値を Workfront に返す必要があります。

  3. 外部システムにログインしたら(またはユーザーが既にログインしている場合)、「認証」ページが表示され、ユーザーの代わりに一連のアクションを実行するためのアクセス権を Workfront が要求していることが説明されます。

  4. ユーザーが「許可」ボタンをクリックすると、ブラウザーは Workfront リダイレクト URI にリダイレクトされ、その際にクエリ文字列に「code=<code>」が追加されます。OAuth2 仕様に従い、このトークンの有効期間は短く設定されています。クエリ文字列には「state=<sent_by_workfront>」も必要です。

  5. Workfront はこのリクエストを処理し、認証コードを使用してトークンエンドポイント URL への API 呼び出しを行います。

  6. トークンエンドポイント URL は、更新トークンとアクセストークンを返します。

  7. Workfront はこれらのトークンを保存し、このユーザーに対して web フック統合を完全にプロビジョニングします。

  8. これ以降、Workfront は web フックプロバイダーに対して、承認済み API 呼び出しを実行できるようになります。これらの呼び出しを行う際に、Workfront は、以下に示すように、アクセストークンを HTTP リクエストヘッダーに入れて送信します。

    code language-none
    -------------------------------
    Authorization: Bearer [access_token] ­­­­­­­­­­­­­­­­­­­­­­­­­­
    -------------------------------
    
  9. アクセストークンの有効期限が切れている場合、Workfront はトークンエンドポイント URL を呼び出して新しいアクセストークンを取得したあと、その新しいアクセストークンを使用して承認済み API 呼び出しを再度試みます。

ApiKey

ApiKey を使用して web フックプロバイダーへの承認済み API 呼び出しを行う方が、OAuth2 よりもはるかに簡単です。API 呼び出しを行う際に、Workfront が ApiKey と Workfront ユーザー名を HTTP リクエストヘッダーに入れて渡すだけです。

-------------------------------

apiKey: 12345

username: johndoe@foo.com

-------------------------------

Web フックプロバイダーは、このユーザー名を使用して、ユーザー固有の権限を適用できます。この仕組みが最も効果を発揮するのは、両方のシステムがシングルサインオン(SSO)を使用して LDAP に接続している場合です。

recommendation-more-help
5f00cc6b-2202-40d6-bcd0-3ee0c2316b43