基本情報

カスタム コネクタは、空白のキャンバスまたは API 仕様から作成できます。

コネクタを作成する前に、利用可能な認証の種類についてよく理解しておいてください。

認証の種類

このセクションでは、コネクタ ビルダーで使用できる最も一般的な認証の種類について説明します。 ユースケース、認証フロー、セキュリティの観点からの 3 つの認証の種類の比較が含まれます。 詳しくは、「 認証の種類」をご覧ください。

OAuth 2.0 認可コード フロー

• ユーザーの代わりにユーザー データにアクセスする必要があるアプリケーションに最適です。
• 高セキュリティ:アクセストークンはユーザーエージェントに公開されることはなく、サーバー間で交換されます。

流れる：

1. ユーザー承認: ユーザーは、アクセスを許可するために承認サーバーにリダイレクトされます。
2. 認証コード: ユーザーがアクセスを許可すると、認証コードがクライアントに返されます。
3. トークン交換: クライアントは、トークン エンドポイントで承認コードをアクセス トークンと交換します。

OAuth 2.0 クライアント資格情報のコード フロー

• ユーザーの操作を伴わないサーバー間の対話に適しています。
• 中程度のセキュリティ: クライアント資格情報が安全に保たれていることに依存します。

流れる：

1. 直接トークン要求: クライアントは、クライアント資格情報を使用して、承認サーバーにアクセス トークンを直接要求します。
2. アクセストークン:認可サーバーはアクセストークンを返します

API キー

• シンプルで迅速に実装でき、パブリック API によく使用されます。
• セキュリティが低い: API キーは簡単に共有または公開できます。

流れる：

API キーの使用法: ユーザーは、認証する各要求に API キーを含めます。

認証フローを選択する

例 A: 個人用アクセス トークン認証を使用して空白のキャンバスからコネクタを構築する では、認証の種類として個人用アクセス トークン (PAT) を使用します。Generate Image API の例では、API キー (特に OAuth 2.0 トークンの場合) に Bearer スキームで Authorization ヘッダーを使用する標準的な方法に従っています。

SAP S4 ODataV2 リソースなどの一部の API では、API キーなどのカスタム ヘッダーを使用してアプリケーションを認証します。 これは、「 例 B: API キー認証を使用して空白のキャンバスからコネクタを構築する」で使用されています。

例 C: OAuth 2.0 を使用して API 仕様からコネクタを構築する クライアント資格情報認証 では、OAuth 2.0 アプリケーションで OAuth 2.0 クライアント資格情報フローを使用します。