アプリケーションの設定

認証を実装する前に、Workfront からアプリの統合を作成して、アプリを OAuth2 に登録する必要があります。

OAuth2 アプリケーションの作成手順については、Workfront 統合用の OAuth2 アプリケーションの作成にある、PKCE を使用した OAuth2 単一ページ web アプリケーションの作成を参照してください。

NOTE
一度に最大 10 個の OAuth2 アプリケーションを持つことができます。

コード交換用のプルーフキーの作成

標準の認可コードフローと同様に、アプリはユーザーのブラウザーを認可サーバーの /authorize エンドポイントにリダイレクトすることから開始します。ただし、この場合はコードチャレンジも渡す必要があります。

最初の手順は、コードベリファイアおよびコードチャレンジを生成することです。

コードベリファイア43 文字以上ののランダムな URL 対応文字列
コードチャレンジコードベリファイアの Base64 URL エンコードされた SHA-256 ハッシュ

コードベリファイアおよびコードチャレンジを生成するには、クライアントアプリにコードを追加する必要があります。

PKCE ジェネレーターコードは、次のような出力を作成します。

INFO
例:
{
  "code\_verifier":"N28zVMsKU6ptUjHaYWg3T1NFTDQqcW1R4BU5NXywapNac4hhfkxjwfhZQat",
  "code\_challenge":"wzgjYF9qEiWep-CwqgrTE78-2ghjwCtRO3vj23o4W\_fw"
}

アプリは後で使用できるように code_verifier を保存し、code_challenge を認可リクエストとともに認可サーバーの /authorize URL に送信します。

認証コードのリクエスト

デフォルトのカスタム認証サーバーを使用している場合、リクエスト URL は以下のようになります。

INFO
例:
/authorize?client\_id=<clientID>&response\_type=code&redirect\_uri=<redirectURL>
&code\_challenge\_method=S256&code\_challenge=wzgjYF9qEiWep-CwqgrTE78-2ghjwCtRO3vj23o4W\_fw"

渡されるパラメーターに注意してください。

  • client_id は、アプリケーションの設定時に作成した OAuth2 アプリケーションのクライアント ID と一致します。

    手順については、Workfront 統合用の OAuth2 アプリケーションの作成にある、PKCE を使用した OAuth2 単一ページ web アプリケーションの作成を参照してください。

  • response_typecode です。これは、アプリケーションが認証コード付与タイプを使用するためです。

  • redirect_uri は、ユーザーエージェントが code とともにリダイレクトされるコールバックの場所です。これは、OAuth2 アプリケーションの作成時に指定したリダイレクト URL の 1 つと一致する必要があります。

  • code_challenge_method はチャレンジの生成に使用されるハッシュメソッドであり、PKCE を使用する Workfront Oauth2 アプリケーションの場合は常に S256 です。

  • code_challenge は、PKCE で使用されるコードチャレンジです。

トークンのコードの交換

認証コードをアクセストークンと交換するには、認証コードを code_verifier とともに認証サーバーの /token エンドポイントに渡します。

INFO
例:
/token \\
  --header 'accept: application/json' \\
  --header 'cache-control: no-cache' \\
  --header 'content-type: application/x-www-form-urlencoded' \\
  --data 'grant\_type=authorization\_code&client\_id=<clientID>&redirect\_uri=<redirectURL>&code=<code>&code\_verifier=N28zVMsKU6ptUjHaYWg3T1NFTDQqcW1R4BU5NXywapNac4hhfkxjwfhZQat
IMPORTANT
通常の認証コードフローとは異なり、この呼び出しには、クライアント ID とクライアントシークレットを含む認証ヘッダーは必要ありません。そのため、このバージョンの認証コードフローは、バックエンドを持たないモバイルアプリケーションやシングルページアプリケーションなどのネイティブアプリケーションに適しています。

渡されるパラメーターに注意してください。

  • grant_typeauthorization_code です。これは、アプリが認証コード付与タイプを使用するためです。

  • redirect_uri は、認証コードの取得に使用された URI と一致する必要があります。

  • code は、/authorize エンドポイントから受け取った認証コードです。

  • code_verifier は、 コード交換用の証明キーを作成するでアプリが生成した PKCE コード検証ツールです。

  • client_id はクライアントを識別し、OAuth2 で事前に登録されている値と一致する必要があります。

コードが引き続き有効で、コード検証が一致する場合は、アプリケーションがアクセストークンを受け取ります。

INFO
例:
{
    "access\_token": "eyJhd\[...\]Yozv",
    "expires\_in": 3600,
    "token\_type": "Bearer"
}

アクセストークンの検証

アプリケーションがアクセストークンを使用してリクエストを渡す場合、リソースサーバーはそのリクエストを検証する必要があります。

次のような API 呼び出しを使用して、アクセストークンを検証できます。

INFO
例:
/attask/api/<api version>/proj/search \\
  --header 'sessionID: <access\_token>' \\

更新トークンのリクエスト

更新トークンをリクエストするには、次のように、API に対して POST 呼び出しを実行します。

INFO
例:
/token \\
  --header 'accept: application/json' \\
  --header 'cache-control: no-cache' \\
  --header 'content-type: application/x-www-form-urlencoded' \\
  --data 'grant\_type=refresh\_token&client\_id=<clientID>&redirect\_uri=<redirectURL>&refresh\_token=<refresh\_token>
5f00cc6b-2202-40d6-bcd0-3ee0c2316b43