- 基本情報
- 通知
- トラブルシューティング
- コネクタ ビルダー
- ActiveCampaign
- Active Directory - プレビュー
- Adobe Acrobat Sign
- Adobe PDF Services
- Amazon Bedrock
- Amazon Connect
- Amazon Polly
- Amazon SES
- Amazon Transcribe
- Amazon Web Services
- Anthropic Claude
- Asana
- AWeber
- Azure AI Document Intelligence
- Azure Maps
- BambooHR
- Box
- Brevo
- Calendly
- Campaign Monitor
- Cisco Webex Teams
- Citrix ShareFile
- Clearbit
- Confluence Cloud
- Constant Contact
- Coupa
- Customer.io
- Datadog
- Deputy
- Discord
- DocuSign
- Drip
- Dropbox
- Egnyte
- Eventbrite
- Exchangerates
- Exchange Server - プレビュー
- Expensify
- Facebook
- Freshbooks
- Freshdesk
- FreshService
- Getresponse
- GitHub
- Gmail
- Google Cloud Platform
- Google ドキュメント
- Google ドライブ
- Google Maps
- Google スプレッドシート
- Google Speech-to-Text
- Google Text-to-Speech
- Google ToDo リスト - プレビュー
- Google Vertex
- Google Vision - プレビュー
- Google Workspace - プレビュー
- GoToWebinar
- Greenhouse
- HTTP Webhook - プレビュー
- HubSpot CRM
- Hubspot Marketing
- HyperV - プレビュー
- iContact
- Insightly CRM
- Intercom
- Jira
- Keap
- Klaviyo
- LinkedIn
- Mailchimp
- Mailgun
- Mailjet
- MailerLite
- Marketo
- Microsoft 365
- Microsoft Azure
- Microsoft Azure Active Directory
- Microsoft Azure OpenAI
- Microsoft Dynamics 365 CRM
- Microsoft OneDrive & SharePoint
- Microsoft Outlook 365
- Microsoft Sentiment
- Microsoft Teams
- Microsoft Translator
- Microsoft Vision
- Miro
- Okta
- OpenAI
- Oracle Eloqua
- Oracle NetSuite
- PagerDuty
- Paypal
- PDFMonkey
- Pinecone
- Pipedrive
- QuickBooks Online
- Quip
- Salesforce
- Salesforce Marketing Cloud
- SAP BAPI - プレビュー
- SAP Concur
- SendGrid
- ServiceNow
- Shopify
- Slack
- SmartRecruiters
- Smartsheet
- Stripe
- Sugar Enterprise
- Sugar Professional
- Sugar Sell
- Sugar Serve
- システム センター - プレビュー
- TangoCard
- Todoist
- Trello
- Twilio
- X(旧ツイッター)
- Xero
- watsonx.ai
- WhatsApp Business
- WooCommerce
- Workable
- Workday
- YouTube
- Zendesk
- Zoho Campaigns
- Zoho Desk
- Zoho Mail
- ZoomInfo
認証を構成する
コネクタ作成の要の 1 つは、認証設定を識別して正しく連携することです。 連携が正しく行われていれば、コネクタが Integration Service カタログにパブリッシュされると、ユーザーはカタログ内の他のコネクタと同様に、コネクタへのコネクションを作成できます。
すべてのコネクタで認証フレームワークが再利用されるため、認証フロー全体とコネクションの管理を統一された方法で管理できます。
認証を行うと最終的に、このコネクタ内の後続の要求では、すべての API 呼び出しに対して認証プロセスの結果が使用されることになります。 たとえば、ベアラー トークンはすべての API 呼び出しのヘッダーで送信されます。
コネクタ ビルダーは、長いコーディングではなく、簡単な構成によって次の業界標準をサポートします。
- OAuth 2.0 の認可コード
- PKCE を使用した OAuth 2.0 認可コード
- OAuth 2.0 クライアント資格情報
- ベーシック
- API キー
- 個人用アクセス トークン (PAT)
- カスタム
- 認証なし
コネクタ ビルダーは Integration Service フレームワークに結び付けられているため、認証設定の定義に複雑なプロセスは必要なくなり、設定を行うだけでよくなりました。これは、フレームワークがトークンの交換、更新、およびその他の類似のタスクを処理することを意味します。 コネクタ ビルダーでは、OAuth 2.0 認可コードが既定で使用されます。これは、ベンダーを使用した認証を処理する上で最も一般的な手法だからです。
認証ページは、次の 3 つの要素から構成されています。
-
認証の種類は、認証フレームワークがどのように反映されるかを制御し、PKCE や完全なトークン交換 (OAuth の場合) などの追加の検証を含みます。さらに、必要なプロパティの概要が示されるように、下にプロパティを含んだ表を再構成います。
- プロパティ表は、カスタム パラメーターで変更および/または既存のパラメーターを編集したりできます。ドロップダウン メニューで選択した認証の種類によっては、一部のフィールドは必須で、赤で指定されている場合があります。
注: この表でこれらのプロパティを変更するか、認証の種類に変更を加えると、コネクタ ビルダーで作成済みのコネクションが無効になります。設計時に使用できるコネクションは 1 つのみで、これは最新の認証設定に対して設定・テストする必要があります。認証設定を更新すると、既存のコネクションは失敗します。新しいコネクションを作成し、その新しいコネクションを使用するようにプロセスを更新する必要があります。
- 指定した設定に基づいて自動的に生成される認証設定画面です。コネクタ ビルダーでの構成中に表示される内容は、アクティビティ パッケージのユーザーに表示される最終結果と同じです。
認証の種類にかかわらず、読み込まれるプロパティ表で次の 2 つの項目を識別できます。
- 認証画面内でユーザーに表示される内容。
- 認証フレームワークによって認証が処理される方法。
- 表内のすべての項目は、ユーザーが上書きできるプロパティと上書きできないプロパティを表します。特定のフィールドを画面に表示するには、[ユーザーに確認] 列で [はい] のフラグを付ける必要があります。
- すべての項目には [名前] と [表示名] があります。[名前] はベンダーが技術的な設定での使用を期待するものであり、後者は認証画面でユーザーに入力を求める際に重要です。
- すべての項目には、プロパティをより詳細に編集できるアクション メニューがあります。ここで、特定のプロパティをヘッダーとして送信する必要があることを指定できます。他の例については「API キー」セクションをご覧ください。
[認証] タブで、コネクタの認証の種類を設定します。サポートされるオプションは次のとおりです。
- OAuth 2.0 の認可コード
- PKCE を使用した OAuth 2.0 認可コード
- OAuth 2.0 クライアント資格情報
- ベーシック
- API キー
- 個人用アクセス トークン (PAT)
- カスタム
- 認証なし
認証を設定する際は、作成したコネクタを使用する人がどのように認証するかを設定します。コネクタを使用する人とは、コネクタを構築中の自分自身を指しますが、同時に、作成したコネクタを使用する他のユーザーも含みます。
概要
OAuth 2.0 認証コードは、最も一般的に使用される認証プロトコルの 1 つです。
認証フィールド
[認可 URL] や [トークン URL] などの [URL] フィールドは、コネクタからベース URL を継承せず、URL 全体を必要とします。 これにより、プロバイダーが認証に他の API とは異なるベース URL を使用するユース ケースが可能になります。
必須フィールド
フィールド | 説明 |
---|---|
クライアント 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}'
curl --request GET \
--url https://{baseUrl}/{resource} \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer {yourToken}'
概要
PKCE を使用した OAuth 2.0 認証コード (コード交換の証明キー) は、シングル ページ アプリケーション、クライアント シークレットを安全に格納できないアプリケーション、または認証コードの安全な取得を保証できないアプリケーションで主に利用される一般的な認証プロトコルです。
認証フィールド
[認可 URL] や [トークン URL] などの [URL] フィールドは、コネクタからベース URL を継承せず、URL 全体を必要とします。 これにより、プロバイダーが認証に他の API とは異なるベース URL を使用するユース ケースが可能になります。
必須フィールド
フィールド | 説明 |
---|---|
クライアント 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}',
curl --request GET \
--url https://{baseUrl}/{resource} \
--header 'Accept: application/json' \
--header 'Content-Type: application/json'
--header 'Authorization: Bearer {yourToken}',
概要
OAuth 2.0 クライアント資格情報は、必要なアクセス許可を付与するアプリケーション固有の資格情報を使用して、保護されたリソースへのアクセスを許可するアクセス トークンを返す方法です。 クライアント資格情報は、マシン間 (M2M) アプリケーションによく使用され、通常はユーザーのアクセス許可を表すものではありません。
認証フィールド
[トークン URL] などの [URL] フィールドはコネクタからベース URL を継承せず、URL 全体を必要とします。 これにより、プロバイダーが認証に他の API とは異なるベース URL を使用するユース ケースが可能になります。
必須フィールド
フィールド | 説明 |
---|---|
クライアント 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}',
curl --request GET \
--url https://{baseUrl}/{resource} \
--header 'Accept: application/json' \
--header 'Content-Type: application/json'
--header 'Authorization: Bearer {yourToken}',
概要
Basic
を付けることができます。 ユーザー名とパスワードは変更でき、すべてのコネクタ要求で認可ヘッダーの値として使用されます。
認証フィールド
フィールド | 説明 |
---|---|
ユーザー名 | ヘッダー値 (Base64 でエンコードされた 2 つの部分からなるコロン) の最初の値 Authorization 。
|
パスワード | 2 部構成のコロンの 2 番目の値は、ヘッダー値として Base64 でエンコード Authorization 。
|
コネクション名 | 認証完了後の UiPath でのコネクションの名前です。 |
動作のしくみ
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)'
curl --request GET \
--url https://{baseUrl}/{resource} \
--header 'Accept: application/json' \
--header 'Content-Type: application/json'
--header 'Authorization: Basic base64(username:password)'
概要
'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}'
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 でのコネクションの名前です。 |
動作のしくみ
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}'
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'
curl --request GET \
--url https://{baseUrl}/{resource} \
--header 'Accept: application/json' \
--header 'Content-Type: application/json'