認証を構成する

コネクタ作成の要の 1 つは、認証設定を識別して正しく連携することです。 連携が正しく行われていれば、コネクタが Integration Service カタログにパブリッシュされると、ユーザーはカタログ内の他のコネクタと同様に、コネクタへのコネクションを作成できます。

すべてのコネクタで認証フレームワークが再利用されるため、認証フロー全体とコネクションの管理を統一された方法で管理できます。

認証を行うと最終的に、このコネクタ内の後続の要求では、すべての API 呼び出しに対して認証プロセスの結果が使用されることになります。 たとえば、ベアラー トークンはすべての API 呼び出しのヘッダーで送信されます。

コネクタ ビルダーは、長いコーディングではなく、簡単な構成によって次の業界標準をサポートします。

• OAuth 2.0 の認可コード
• PKCE を使用した OAuth 2.0 認可コード
• OAuth 2.0 クライアント資格情報
• ベーシック
• API キー
• 個人用アクセス トークン (PAT)
• カスタム
• 認証なし

コネクタ ビルダーは Integration Service フレームワークに結び付けられているため、認証設定の定義に複雑なプロセスは必要なくなり、設定を行うだけでよくなりました。これは、フレームワークがトークンの交換、更新、およびその他の類似のタスクを処理することを意味します。 コネクタ ビルダーでは、OAuth 2.0 認可コードが既定で使用されます。これは、ベンダーを使用した認証を処理する上で最も一般的な手法だからです。

認証ページは、次の 3 つの要素から構成されています。

1. 認証の種類は、認証フレームワークがどのように反映されるかを制御し、PKCE や完全なトークン交換 (OAuth の場合) などの追加の検証を含みます。さらに、必要なプロパティの概要が示されるように、下にプロパティを含んだ表を再構成います。
   

   

   
   
2. プロパティ表は、カスタム パラメーターで変更および/または既存のパラメーターを編集したりできます。ドロップダウン メニューで選択した認証の種類によっては、一部のフィールドは必須で、赤で指定されている場合があります。
   注: この表でこれらのプロパティを変更するか、認証の種類に変更を加えると、コネクタ ビルダーで作成済みのコネクションが無効になります。設計時に使用できるコネクションは 1 つのみで、これは最新の認証設定に対して設定・テストする必要があります。

   認証設定を更新すると、既存のコネクションは失敗します。新しいコネクションを作成し、その新しいコネクションを使用するようにプロセスを更新する必要があります。
3. 指定した設定に基づいて自動的に生成される認証設定画面です。コネクタ ビルダーでの構成中に表示される内容は、アクティビティ パッケージのユーザーに表示される最終結果と同じです。
   
   
   
   

認証の表の構成

認証の種類にかかわらず、読み込まれるプロパティ表で次の 2 つの項目を識別できます。

1. 認証画面内でユーザーに表示される内容。
2. 認証フレームワークによって認証が処理される方法。

• 表内のすべての項目は、ユーザーが上書きできるプロパティと上書きできないプロパティを表します。特定のフィールドを画面に表示するには、[ユーザーに確認] 列で [はい] のフラグを付ける必要があります。
• すべての項目には [名前] と [表示名] があります。[名前] はベンダーが技術的な設定での使用を期待するものであり、後者は認証画面でユーザーに入力を求める際に重要です。
• すべての項目には、プロパティをより詳細に編集できるアクション メニューがあります。ここで、特定のプロパティをヘッダーとして送信する必要があることを指定できます。他の例については「API キー」セクションをご覧ください。

認証の種類

[認証] タブで、コネクタの認証の種類を設定します。サポートされるオプションは次のとおりです。

• OAuth 2.0 の認可コード
• PKCE を使用した OAuth 2.0 認可コード
• OAuth 2.0 クライアント資格情報
• ベーシック
• API キー
• 個人用アクセス トークン (PAT)
• カスタム
• 認証なし

注:

認証を設定する際は、作成したコネクタを使用する人がどのように認証するかを設定します。コネクタを使用する人とは、コネクタを構築中の自分自身を指しますが、同時に、作成したコネクタを使用する他のユーザーも含みます。

OAuth 2.0 の認可コード

概要

OAuth 2.0 認証コードは、最も一般的に使用される認証プロトコルの 1 つです。

認証フィールド

[認可 URL] や [トークン URL] などの [URL] フィールドは、コネクタからベース URL を継承せず、URL 全体を必要とします。 これにより、プロバイダーが認証に他の API とは異なるベース URL を使用するユース ケースが可能になります。

必須フィールド

手記： クライアント ID とクライアント シークレットは、多くの場合、API プロバイダーから生成されます。 認証用にこれらの値を生成する方法については、プロバイダーのドキュメントを参照してください。

フィールド	説明
クライアント ID	プロバイダーによって生成されたアプリケーション識別子。
クライアント シークレット	プロバイダーによって生成されたアプリケーション秘密鍵。
認可 URL	認証プロセスを完了するようにユーザーをリダイレクトするURLです。 認証コードを返します。
トークン URL	UiPath が認可コードをトークンと交換するために使用する URL です。

追加フィールド

フィールド	説明
スコープ	コネクタに必要なスコープを追加し、各スコープをスペースで区切ります (例: read write openid)。
トークン更新 URL	更新トークンも返された場合に新しいアクセス トークンを生成するために必要な URL。 これは多くの場合、 トークン URL に使用される URL と同じです。
トークン失効 URL	アクセス トークンを取り消すために必要な URL。
更新間隔	アクセス トークンの有効期間。 既定値は 3600 秒または 60 分です。
コネクション名	認証完了後の UiPath でのコネクションの名前です。
基本ヘッダー	クライアント ID とシークレットを Authorization ヘッダーで Base64 エンコード値として送信するかどうかを示します。 Boolean 値 (true/false);デフォルトは True です。

動作のしくみ

コネクタにすべてのフィールド値が追加または設定されると、 UiPath® は認証フローを完了するために必要な手順を自動的にガイドします。 UiPath はこのプロトコルをサポートしており、更新トークン URI が指定されている場合、必要に応じてバックグラウンドでアクセス トークンを自動的に再生成します。 これにより、基になる更新トークンが有効である限り、接続が維持され、機能します。

承認後の要求の形式

初期構成の完了後 接続が確立されると、そのコネクタに対して行われたすべての要求には 承認ヘッダーは自動的に 依頼。

curl --request GET \
  --url https://{baseUrl}/{resource} \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer {yourToken}'

PKCE を使用した OAuth 2.0 認可コード

概要

PKCE を使用した OAuth 2.0 認証コード (コード交換の証明キー) は、シングル ページ アプリケーション、クライアント シークレットを安全に格納できないアプリケーション、または認証コードの安全な取得を保証できないアプリケーションで主に利用される一般的な認証プロトコルです。

認証フィールド

[認可 URL] や [トークン URL] などの [URL] フィールドは、コネクタからベース URL を継承せず、URL 全体を必要とします。 これにより、プロバイダーが認証に他の API とは異なるベース URL を使用するユース ケースが可能になります。

必須フィールド

手記： クライアント ID とクライアント シークレットは、多くの場合、API プロバイダーから生成されます。 認証用にこれらの値を生成する方法については、プロバイダーのドキュメントを参照してください。

フィールド	説明
クライアント ID	プロバイダーによって生成されたアプリケーション識別子。
クライアント シークレット	プロバイダーによって生成されたアプリケーション秘密鍵。
認可 URL	認証プロセスを完了するようにユーザーをリダイレクトするURLです。 認証コードを返します。
トークン URL	UiPath が認可コードをトークンと交換するために使用する URL です。

追加フィールド

フィールド	説明
スコープ	コネクタに必要なスコープを追加し、各スコープをスペースで区切ります (例: read write openid)。
トークン更新 URL	更新トークンも返された場合に新しいアクセス トークンを生成するために必要な URL。 これは多くの場合、 トークン URL に使用される URL と同じです。
OAuth2 PKCE コード チャレンジ メソッド	チャレンジの生成に使用されるメソッド。 S256 または plain を指定できます (推奨: S256)。
トークン失効 URL	アクセス トークンを取り消すために必要な URL。
更新間隔	アクセス トークンの有効期間。 既定値は 3600 秒または 60 分です。
コネクション名	認証完了後の UiPath でのコネクションの名前です。
基本ヘッダー	クライアント ID とシークレットを Authorization ヘッダーで Base64 エンコード値として送信するかどうかを示します。 Boolean 値 (true/false);デフォルトは True です。

動作のしくみ

コネクタにすべてのフィールド値が追加または設定されると、認証フローを完了するために必要な手順が UiPath® によって自動的に実行されます。 UiPath はこのプロトコルをサポートしており、更新トークン URI が指定されている場合、必要に応じてバックグラウンドでアクセス トークンを自動的に再生成します。 これにより、基になる更新トークンが有効である限り、接続が維持され、機能します。

UiPath では、PKCE ベースの認可に必要なチャレンジ文字列を提供しています。必要なのは、OAuth2 PKCE Code Challenge Method のみです。

承認後の要求の形式

初期構成が完了して接続が確立されると、すべての要求 そのコネクタ用に作成された承認ヘッダーは、 依頼。

curl --request GET \
  --url https://{baseUrl}/{resource} \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json'
  --header 'Authorization: Bearer {yourToken}',

OAuth 2.0 クライアント資格情報

概要

OAuth 2.0 クライアント資格情報は、必要なアクセス許可を付与するアプリケーション固有の資格情報を使用して、保護されたリソースへのアクセスを許可するアクセス トークンを返す方法です。 クライアント資格情報は、マシン間 (M2M) アプリケーションによく使用され、通常はユーザーのアクセス許可を表すものではありません。

認証フィールド

[トークン URL] などの [URL] フィールドはコネクタからベース URL を継承せず、URL 全体を必要とします。 これにより、プロバイダーが認証に他の API とは異なるベース URL を使用するユース ケースが可能になります。

必須フィールド

手記： クライアント ID とクライアント シークレットは、多くの場合、API プロバイダーから生成されます。 認証用にこれらの値を生成する方法については、プロバイダーのドキュメントを参照してください。

フィールド	説明
クライアント ID	プロバイダーによって生成されたアプリケーション識別子。
クライアント シークレット	プロバイダーによって生成されたアプリケーション秘密鍵。
トークン URL	アクセス トークンの取得に使用する URL です。

追加フィールド

フィールド	説明
スコープ	コネクタに必要なスコープを追加し、各スコープをスペースで区切ります (例: read write openid)。
更新間隔	アクセス トークンの有効期間。 既定値は 3600 秒または 60 分です。
コネクション名	認証完了後の UiPath でのコネクションの名前です。
基本ヘッダー	クライアント ID とシークレットを Authorization ヘッダーで Base64 エンコード値として送信するかどうかを示します。 Boolean 値 (true/false);デフォルトは True です。

動作のしくみ

コネクタにすべてのフィールド値が追加または構成されると 、UiPath® は認可要求を生成し、アクセス トークンを生成するために必要な資格情報を渡します。 OAuth 2.0 クライアント資格情報は M2M アプリケーション用であるため、最初の UiPath 認証ページのみが表示され、それ以上のリダイレクトはありません。

正常な認可フローが検出されると、指定された資格情報が有効である限り、UiPath は接続を維持します。

承認後の要求の形式

初期構成が完了して接続が確立されると、そのコネクタに対して行われたすべての要求に承認が付与されます ヘッダーが自動的に要求に含まれます。

curl --request GET \
  --url https://{baseUrl}/{resource} \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json'
  --header 'Authorization: Bearer {yourToken}',

基本認証

概要

基本認証の種類では、ユーザー名とパスワードを定義し、それらのパスワードを Base64 でエンコードし、プレフィックスとして Basicを付けることができます。 ユーザー名とパスワードは変更でき、すべてのコネクタ要求で認可ヘッダーの値として使用されます。

認証フィールド

フィールド	説明
ユーザー名	ヘッダー値 (Base64 でエンコードされた 2 つの部分からなるコロン) の最初の値 Authorization 。
パスワード	2 部構成のコロンの 2 番目の値は、ヘッダー値として Base64 でエンコード Authorization 。
コネクション名	認証完了後の UiPath でのコネクションの名前です。

動作のしくみ

ユーザー名とパスワードの値が指定された場合、 UiPath® は値を組み合わせてコロンで区切り、Base64 でエンコードし、 Basic にプレフィックスを付けて Authorization ヘッダー値 (例: Authorization: Basic base64(username:password))。 このヘッダー値は、認証手段として各要求に渡されます。

承認後の要求の形式

初期構成が完了して接続が確立されると、すべての要求 そのコネクタ用に作成された承認ヘッダーは、 依頼。

curl --request GET \
  --url https://{baseUrl}/{resource} \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json'
  --header 'Authorization: Basic base64(username:password)'

API キー

概要

一部のプロバイダーは、API リソースにアクセスするための認証形式として API キーを提供しています。 コネクタ ビルダーでは、この認証の種類により、コネクタ要求に渡される 'X-Acess-Token: <provider_api_key>' ヘッダーが使用されます。

認証フィールド

フィールド	説明
API キー	API プロバイダーから生成された API キーです。すべてのコネクタ要求で X-Access-Token ヘッダーの値として使用されます。
コネクションマメ	認証完了後の UiPath でのコネクションの名前です

動作のしくみ

プロバイダーによって生成された API キーの値を [設定] - [認証] の [API キー] パラメーターに使用すると、そのコネクタに対して行われるすべての要求に X-Access-Token ヘッダーが含まれ、ヘッダー値として API キーが提供されます。

承認後の要求の形式

初期構成が完了して接続が確立されると、そのコネクタに対して行われたすべての要求には、 X-Access-Token ヘッダーが自動的に要求に含まれます。

curl --request GET \
  --url https://{baseUrl}/{resource} \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json'
  --header 'X-Access-Token: {yourtoken}'

個人用アクセス トークン

概要

一部のプロバイダーは、有効期限のないアクセス トークンを提供し、要求の認証に Authorization: {access_token} ヘッダー パターンを使用します。 PAT 認証方式では、必要なアクセス トークンを指定し、前述のヘッダーを適用できますが、いずれかの時点で有効期限が切れた場合、アクセス トークンは保持されません。

認証フィールド

フィールド	説明
個人用アクセス トークン	すべてのコネクタ要求の Authorization ヘッダー フィールドの値として使用される、プロバイダーによって生成されたアクセス トークン。 フィールド 既定では、共通のベアラー認証パターンに対応するために、トークンの先頭に Bearer を付けます。
コネクション名	認証完了後の UiPath でのコネクションの名前です。

動作のしくみ

プロバイダーによって生成された API キーの値を [設定] - [認証] の [ Personal Access トークン] パラメーターに使用すると、そのコネクタに対して行われるすべての要求に X-Access-Token ヘッダーが含まれ、そのヘッダー値として個人用アクセス トークンが設定されます。

承認後の要求の形式

初期構成が完了して接続が確立されると、すべての要求 そのコネクタ用に作成されたものには、ヘッダー Authorization が自動的に付けられます に含まれるもの 依頼。

curl --request GET \
  --url https://{baseUrl}/{resource} \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json'
  --header 'Authorization: {personal_access_token}'

カスタム

概要

カスタム認証は、ベンダー構成がどの標準にも準拠していないが、要求ごとに認証の詳細を交換して送信する必要がある場合に使用する必要があります。

認証フィールド

カスタム認証フィールドには、サンプル フィールドとして Authorization パラメーターが付属していますが、API プロバイダーの認証パターンに合わせてカスタマイズできます。

カスタム認証から認証に追加されたパラメーターは、コネクタの要求に適用されます。

手記： 現在のところ、カスタム認証ではカスタム認証フローを作成できません。 これにより、コネクタ内の要求に適用される標準の認証パラメーターをカスタマイズできます。

動作のしくみ

認証セクションに追加されたパラメーターは、すべてのコネクタ要求に自動的に含まれます。

認証なし

「認証なし」オプションでは、リストからすばやく選択でき、認証構成テーブルからすべてのプロパティーが削除されます。

使用方法

このオプションは、接続先のベンダー アプリケーションがサインインしなくても使用できる場合に使用します。 これは、オンラインのパブリック サービスでも、社内で公開されている API でもかまいません。 API 呼び出しを行っているユーザーを識別する要求でヘッダーを送信する必要はありません。

送信時の結果 依頼

curl --request GET \
  --url https://{baseUrl}/{resource} \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json'