OAuth2.0とは？

OAuth2.0について

OAuth2.0の解説へようこそ！OAuth2.0は、Tulipの世界では強力な認証プロトコルですが、誤解されがちです。この記事では、OAuth2.0の基本を紐解き、Tulipでサポートされている認証フローを案内し、初期コネクタの設定方法を理解し、シームレスなスタートのための簡単なヒントを共有します。

OAuth2.0は複雑なため、この記事では詳細な技術的な説明は省略します。Tulipのリフレッシュトークンの扱い、スコープとオーディエンスの管理、カスタムコネクタの設定について詳しく知りたい場合は、この詳細なOAuth2.0テクニカルガイドをチェックすることをお勧めします。

認証タイプ

Tulipは3つのOAuth2.0認証タイプをサポートしています：OAuth2.0（サービスアカウント）、OAuth2.0（ユーザー認証情報）、OAuth2.0（クライアント認証情報）です。重要な違いは、ユーザー間でクレデンシャルを共有する方法と、OAuth 仕様に対して実行されるフローにあります。固有のOAuthフローの完全なリストと説明は、https://frontegg.com/blog/oauth-flows。

:::(Info) (注）旧バージョンのTulipでは、OAuth2.0（サービスアカウント）はOAuth2（Admin）、OAuth2.0（ユーザー認証情報）はOAuth2（Operator）と呼ばれていました：

認証コードの流れ：

• **OAuth2.0（サービスアカウント）：**Tulip Playerのすべてのユーザーに対して、コネクターのテスト中に提供された認証情報を使用します。組織全体で認証情報を共有する場合に最適です。認証情報の有効期限が切れた場合は、管理者の再認証が必要です。
• **OAuth2.0（ユーザー認証情報）：**Tulip Playerにログインしているユーザーに基づいて認証をセグメント化します。ユーザーが認証していない場合、または認証が失効した場合、ユーザーはTulip Player内でOAuthフローを受けます。

クライアント認証フロー：

• **OAuth2.0（クライアント認証情報）：**このグラント・タイプは、Tulipがクライアントの認証情報（クライアントIDとクライアント・シークレット）を使用して認証サーバーと認証することによってアクセストークンを取得するために使用されます。

基本事項の説明

具体的な説明に入る前に、エンバイロメントを理解し、コネクタホストとその機能の概要を理解することをお勧めします。

OAuth2.0は、Tulip（クライアント）がビジネスシステムとのアイデンティティを確立するためのメカニズムとして機能します。

認証コードの流れ

:::(Warning) (警告）ユーザー認証プロセスを完了するには、ブラウザでポップアップを許可する必要があります。コネクタが複数の環境で構成されている場合、認証時に各環境で別々のポップアップ・ウィンドウが開きます。

Chromeでポップアップが有効になっているかどうかを確認する方法：

1. Chromeを開き、ウィンドウの右上にある3つの点のメニューをクリックします。
2. ドロップダウンメニューから**「設定」を**選択します。
3. 下にスクロールし、「プライバシーとセキュリティ」をクリックします。
4. プライバシーとセキュリティ」セクションで、「サイト設定」をクリックします。
5. 下にスクロールし、「ポップアップとリダイレクト」をクリックします。
6. トグルがポップアップを許可に設定されていることを確認するか、または手動でポップアップの表示を許可するサイトのリストにウェブサイトを追加します。

ポップアップがブロックされると、アドレスバーに小さなアイコンが表示されます。このアイコンをクリックすると、Tulipからのポップアップをすばやく許可できます：

アクセスはハンドシェイクによって許可され、Tulipは主に最も一般的なOAuthフローであるAuthorization Code Flowをサポートしています。以下は、このフローがどのように展開されるかの要約です：

1. ユーザは Connector を保存する前にTestボタンをクリックしてフローを開始します。
2. Tulip は OAuth プロバイダから認証サーバと通信し、クライアント ID、スコープ（アクセスしようとしているもの）、およびその他の関連する詳細などの特定のパラメータを共有します。
3. 認証サーバーは、ユーザーにアクセスを許可するよう促します：

1. ユーザが同意すると、認証サーバは認証コードを生成し、認証ウィンドウを終了する。
2. 認証コードで武装したTulipは、トークン・エンドポイントにアクセスし、認証コード、クライアントID、クライアント・シークレット、その他のプロパティを提供して、トークンを安全に要求します。
3. 認証コードを検証した後、サーバーはトークン、およびオプションでリフレッシュ・トークンを応答します。このトークンは、ユーザー認証されたリクエストのためのものです。
4. Tulipは、提供されたトークンでユーザーに代わってリクエストを実行できるようになります。

実行の流れを理解するために、以下の図をご覧ください：

クライアント認証フロー

クライアント認証フローは、主に2つのビジネスシステムが相互作用するために使用されます。このフローは一度構成され、その後すべてのユーザーによって共有されます。

1. ユーザはコネクタを保存する前に**テスト・**ボタンをクリックしてフローを開始する。
2. Tulip は OAuth プロバイダから認証サーバと通信し、クライアント ID、スコープ（アクセスしようとしているもの）、その他の関連する詳細などの特定のパラメータを共有します。
3. 認証サーバーは、クライアントIDとクライアントシークレットが正確であることを前提として、アクセストークンを返します。オプションで、リフレッシュトークンを返すこともできます。このトークンは、ユーザが認証したリクエストのためのものです。
4. Tulipは、提供されたトークンを使って、ユーザーに代わってリクエストを実行することができます。

OAuthの設定

:::(Warning) (オンプレミスサービス)Tulipがコネクタの認証を実行するためには、AuthorizeエンドポイントとTokenエンドポイントがクラウドからアクセス可能である必要があります：

認証コードURL

認証コードフローのステップ2でTulipがコンタクトするURLです。OAuthプロバイダーのAPIドキュメントに記載されており、通常は/authまたは/authorizeで終わります。

注意: このフィールドはクライアント認証情報には存在しません。

アクセストークン URL

認証サーバからのレスポンスの後、認証用のトークンを取得するために Access Token URL にリクエストを行います。通常、/token で終わる。

注：このフィールドは、クライアント認証情報には存在しない。

クライアント ID とクライアントシークレット

クライアント ID は、OAuth プロバイダの UI から生成され、認証コードの最初のリクエストで渡される。クライアント ID とクライアントシークレットは、すべてのトークン要求に付随する。

オーディエンスおよびスコープ

Audience はユーザがアクセスを求める特定のアセットを指定し、Scope はこれらのアセットに必要なアクションを定義します。どちらも、ステップ 2 の認証コード リクエストで伝えられます。

追加オプション

• Send token request data as JSON: トークンURLに送信されるリクエストのエンコード形式を変更します。特定の統合に必要な場合は有効にします。
• **リフレッシュリクエストに認証ヘッダーを送信する：**有効にすると、リフレッシュリクエストに追加のヘッダーを追加します。
• **ユーザー同意プロンプトをスキップします：**認証コードリクエストのプロンプト属性を制御します。無効にすると同意に設定され、有効にするとログインに設定されます。

:::(Warning) (注意)統合によっては、プロンプト属性を除外するか、noneに設定してください。support@tulip.co までお問い合わせください：

さらに掘り下げる

もっと詳しく知りたいですか？以下の記事を参照してください：

• OAuth2.0の構成と技術的詳細
• 複数の環境でコネクタ機能を実行する方法