メインコンテンツにスキップ
ドキュメント
ドキュメント
Adaptive Planning
最終更新: 2024-03-08
API クライアントの登録

API クライアントの登録

セキュリティ: "System" 業務分野の以下のドメイン:
  • Set Up: Tenant Setup - Security
  • セキュリティ管理
Workday では、Workday API 基盤の一部として OAuth 2.0 がサポートされています。OAuth 2.0 を使用すると、Workday ユーザーは、サードパーティのクライアントが代理で Workday データに安全にアクセスできるように認証することができます。
Workday API にアクセスするには、OAuth 2.0 クライアントを Workday に登録します。OAuth 2.0 のクライアントが各テナントの Workday API にアクセスできるようにすることができます。
  1. "Edit Tenant Setup - Security"
     タスクにアクセスします。
  2. "OAuth 2.0 Settings
    " セクションで、
    "OAuth 2.0 Clients Enabled"
     チェックボックスをオンにします。
  3. "API クライアントの登録
     " タスクにアクセスします。
  4. "クライアント名"
    を入力します。
  5. "クライアントの付与タイプ"
    を選択します。
    オプション 説明
    認証コード付与
    モバイル アプリケーションなど、データを保持できるクライアントに使用します。
    暗黙的なグラント (使用不可)
    JavaScript アプリケーションなど、サーバー側のコンポーネントを含まないアプリケーションでは必要です。
    このクライアントの付与タイプは今後のリリースで廃止される予定です。代わりに以下のクライアントの付与タイプを使用することをお勧めします。
    • 承認コード付与 (DKC サポート付き)。
    • JWT Bearer 付与。
    JWT Bearer 付与
    Salesforce インテグレーションなどのクライアントに JSON Web トークン (JWT) を使用する。この付与タイプを使用すると、アクセス トークンとリフレッシュ トークンのセキュリティ アサーションの交換を、"インテグレーション システム ユーザー" フィールドで選択した
    インテグレーション システム ユーザー
     (ISU) に制限できます。 署名を検証するための
    "x509 Certificate"
     を提供します。
    "インテグレーション メッセージの許可
     " チェックボックスをオンにして、インテグレーションのステータスに関する必要な情報を Workday が確実に受け取ることもできます。
    SAML Bearer 付与
    認証に SAML SSO を使用するアプリケーションで使用します。
    "Assertion Verification"
    も選択します。以下のようにします。
    • 設定された IdP を使用し
       、
      署名の検証に "テナント設定の編集 - セキュリティ"
       で設定された SAML IdP の X.509 公開証明書を使用します。この場合の発行元は IdP です。
    • 証明書を使用 (x509 オプション):
       署名の検証用に
      x509 証明書を
       指定します。この場合の発行元は API クライアント ID です。 任意で、
      "インテグレーション システム ユーザー"
       フィールドで ISU を選択して、アクセス トークンとリフレッシュ トークンに対するセキュリティ アサーションの交換をそれらの ISU に制限することもできます。
    次の操作も可能です。
    • "Allow Access to All System Users"
       チェックボックスをオンにすると、インテグレーション システム ユーザー (ISU) だけでなく、すべてのユーザーが SAML Bearer アサーション フローを使用できるようになります。
    • "インテグレーション メッセージの許可
       " チェックボックスをオンにして、インテグレーションのステータスに関する必要な情報が Workday に提供されるようにします。
  6. (任意)
    "承認コード付与"
     クライアントの付与タイプを使用してクライアントに BPCE サポートを追加する場合は
    、"コード交換用サポート プリファレンス キー (DKCE)"
     チェックボックスをオンにします。
    DKCE を使用すると、認証コードがインターセプトされるという恐れをクライアントに軽減することができます。クライアントがクロス 生成元リソース共有 (CORS) を有効にした生成元間のリクエストをサポートする場合は、このチェックボックスをオンにします。
  7. (任意)
    "60 分のアクセス トークンの有効期限を
     適用する" チェックボックスをオンにして、API クライアントが以下の条件を満たす Bearer トークンを返せるようにします。
    • 60 分の有効期限がある。
    • 有効期限が切れていない限り、セッションが終了しても無効化しないでください。
    このチェックボックスをオンにして
    "OK"
    をクリックすると、オフにすることはできません。
  8. "x509 Certificate"
     フィールドで X.509 公開キーを選択します。
    このフィールドは、以下を選択した場合にアクティブになります。
    • "クライアントの付与タイプ"
      として
      "Jwt Bearer 付与"
      。
    • "クライアントの付与タイプ"
       として
      "SAML Bearer グラント" を
       選択し、
      "アサーション検証"
      として
      "証明書を使用" (x509 オプション) を選択します
       。
  9. (任意)
    "インテグレーション システム ユーザー"
     フィールドで 1 人以上の ISU を選択します。
    このフィールドは
    、"x509 Certificate"
     フィールドがアクティブな場合に表示されます。 このフィールドで ISU を選択しない場合、API クライアントによって ISU ユーザー アカウントに基づいてアクセスが制限されることはありません。1 人以上の ISU を選択した場合、他のユーザーを使ったサインイン試行は失敗します。クライアントのアクセスを特定の ISU に制限することをお勧めします。
  10. アクセス トークンの "タイプ"
    を選択します。
    オプション 説明
    運送会社
    よりシンプルな開発が可能になります。
    MAC (使用不可)
    セキュリティが向上します。
    このアクセス トークン タイプは今後のリリースで廃止される予定です。代わりに Bearer トークンを使用することをお勧めします。
  11. "リダイレクト URI"
    を入力します。
    • 複数のリダイレクト URI を指定する場合は、区切り文字としてカンマを使用します。
    • "認証コード付与
       " クライアントの付与タイプでは、"https" で始まるセキュリティ保護された URI のみが有効です。
    • 暗黙的なグラント
       および
      認証コード付与 (
      コード交換用の証明キー (DKCE) が有効)
       では、"https" で始まるセキュア URI とカスタム ドメイン URI のみが有効です。例: OfficeConnect:// test.com や https://Google.com
  12. (任意)
    "リフレッシュ トークンのタイムアウト (日数)"
    を選択します。1 ～ 365 日の間で値を選択できます。デフォルト値は 30 日です。リフレッシュ トークンのレートは、ユーザーごと、秒間 1 回に制限されています。
  13. (任意)
    "無期限のリフレッシュ トークン"
     チェックボックスをオンにして、リフレッシュ トークンがタイムアウトしないようにします。
  14. (任意)
    "無効"
     チェックボックスをオンにして、クライアントが Workday へのアクセスをリクエストできないようにします。
  15. REST API クライアントに対するテナント全体での OAuth 同意を付与する場合は
    、"管理者の同意の
     付与" チェックボックスをオンにします。オンにした場合、ユーザーは Workday 業務分野へのクライアント アクセスを明示的に許可する必要はありません。
  16. "Scope (Functional Areas)"
     プロンプトから、OAuth 2.0 クライアントがアクセス権を必要とする業務分野を選択します。
    Workday REST API に対して Workday で有効化されている業務分野を選択します。また、アクセス権を必要とする可能性があるカスタム オブジェクトのドメインの業務分野も選択します。アクセスを特に必要とする業務分野のみを公開することに注意してください。
  17. (任意) OAuth 2.0 クライアントで、どの業務分野にも属さない Workday のコア ドメインへのアクセスが必要な場合は、
    "Workday 所有の範囲を含める"
     チェックボックスをオンにします。
  18. (任意) 指定された IP アドレス範囲からのみ OAuth 2.0 クライアント アクセスが認証されるようにする場合は、"
    特定の IP 範囲に限定"
     プロンプトから範囲を選択します。
    "Create IP Range"
     を選択し、次のいずれかのフォーマットを使用して、IP アドレスの名前付きカンマ区切りリストを作成することもできます。
    • X.X.X.X.
    • CIHR 注記。例: 192.168.0.1/24。
    • X.X.X.X - Y.Y.Y.Y.
    Workday では、ダッシュを含む IP の範囲には制限があります。この形式で入力した IP 範囲の使用を開始した後に
    "サインインとサインイン試行"
     レポートでサインイン エラーが発生した場合は、次のようになります。
    1. 範囲が一連の小さなセグメントに分類されるかどうかを確認するには、IP アドレスの範囲を CIID 表記に変換するツールを使用します。このようなサードパーティの CIID 計算ツールは、オンラインで利用できます。
    2. ツールによって返されたセグメントのカンマ区切りリストとして、Workday の
      "IP 範囲"
       を再入力します。例: 199.67.128.0/18、199.67.192.0/24、または 199.67.128.0-199.67.191.255, 199.67.192.0-199.67.192.255
  19. 生成元間のリクエストに対して有効化されたドメインごとに、
    "許可された生成元"
     グリッドに行を追加してください。ドメインは次の値で始まる必要があります:
    https://
     または
    chrome-extension://
     CORS 形式を使用
    "許可された
     生成元" ドメインから生成されたクロス生成リクエストに応答するときに、CORS ヘッダーが追加される場合があります。Workday では、承認コード付与タイプを使用するクライアントの生成元間のリクエストのみがサポートされ、 BPCE サポートもサポートされます。
OAuth 2.0 クライアントのクライアント ID とクライアント シークレットが生成されます。ページから移動する前にクライアント シークレットをコピーし、安全に保存します。クライアント シークレットをなくした場合は、
"新しい API クライアント シークレットの生成"
 タスクを使用して新しいものを生成できます。
Workday では、OAuth 2.0 クライアントを更新の一部として提供できます。Workday が提供するすべての OAuth 2.0 クライアントは、デフォルトで無効になっています。
OAuth 2.0 クライアントに新しいクライアント シークレットを生成する場合は、以下の手順に従ってください。
  1. "新しい API クライアント シークレットの生成"
     タスクにアクセスします。
  2. プロンプトから
    "API クライアント"
     を選択します。
  3. "確認
     " チェックボックスをオンにします。
OAuth 2.0 クライアントがすでに使用中の場合、新しいクライアント シークレットを生成すると、クライアントは使用できなくなります。