API インテグレーションを使用したデータへのアクセス
学習の目的
- OAuth 2.0 で接続アプリケーションの API インテグレーションを可能にする方法を説明する。
- 接続アプリケーションの API インテグレーションのユースケースを挙げる。
接続アプリケーションの OAuth 2.0 認証フロー
接続アプリケーションを使用して、外部アプリケーションの代わりに Salesforce データへのアクセスを要求できます。接続アプリケーションがアクセスを要求するためには、OAuth 2.0 プロトコルを使用して Salesforce API に統合されている必要があります。OAuth 2.0 は、トークンの交換を通してアプリケーション間の認証と安全なデータ共有を可能にするオープンプロトコルです。開発者がアプリケーションを Salesforce に統合する場合は、OAuth API を使用します。これらの OAuth API によって、ユーザーがあるアプリケーションで作業しながら、別のアプリケーションのデータを参照できるようになります。
あなたが Salesforce モバイルアプリケーションを開いて Salesforce データにアクセスするときも、OAuth 2.0 認証フローを開始しています。このフローでは、Salesforce 組織がリソースサーバーで、Salesforce モバイルアプリケーションがアクセスを要求するクライアントです。あなたが Salesforce モバイルアプリケーションに、Web 経由でいつでも Salesforce データにアクセスして管理することを承認します。
OAuth 認証時のイベントのフローは、デバイスの認証状態によって異なります。
初回の認証フロー
- Salesforce モバイルアプリケーションを開きます。
- 認証プロンプトが表示されます。
- ユーザー名とパスワードを入力します。
- Salesforce モバイルアプリケーションがログイン情報を Salesforce に送信し、OAuth 認証フローを開始します。
- Salesforce モバイルアプリケーションにアクセスを許可する要求を承認します (上図を参照)。
- Salesforce が、認証成功の確認として、アクセストークンと更新トークンをモバイルアプリケーションに送信します。
- Salesforce モバイルアプリケーションが起動します。
継続的な認証
- Salesforce モバイルアプリケーションを開きます。
- セッションが有効な場合は、Salesforce モバイルアプリケーションがすぐに起動します。セッションの期限が切れている場合は、Salesforce モバイルアプリケーションが初回認証で取得した更新トークンを使用して、更新されたセッションを取得します。
- Salesforce モバイルアプリケーションが起動します。
Web アプリケーションインテグレーション (OAuth 2.0 Web サーバーフロー)
外部 Web アプリケーションを Salesforce API に統合する場合は、OAuth 2.0 Web サーバーフローを使用します。このフローでは、Web アプリケーションをホストするサーバーで、クライアント ID とクライアントの秘密で定義される、接続アプリケーションの ID を保護する必要があります。
たとえば、先日、顧客の注文状況に安全にアクセスできる Web サイトを開発したとします。注文状況データは Salesforce CRM プラットフォームに安全に保存されています。ヘルプデスクユーザーに顧客の注文状況の表示を承認するために、Order Status (注文状況) アプリケーションを開発して、Web サーバーフローを指定した接続アプリケーションとして設定します。
- ヘルプデスクユーザーが、Order Status (注文状況) Web アプリケーションをクリックします。
- このアプリケーションを認証して注文状況データへのアクセスを承認するために、接続アプリケーションがユーザーを Salesforce にリダイレクトします。
- ユーザーが Order Status (注文状況) アプリケーションに、データへのアクセスを承認します。
- Salesforce が、認証コードを含むコールバックを Order Status (注文状況) アプリケーションに送信します。
- Order Status (注文状況) アプリケーションがこの認証コードを Salesforce トークンエンドポイントに渡し、アクセストークンを要求します。
- Salesforce が認証コードを検証し、範囲の形態で関連付けられている権限を含むアクセストークンを返します。
- Order Status (注文状況) アプリケーションが、注文状況データへのアクセス要求を Salesforce に返します。この要求には、アクセストークンと関連付けられている範囲が含まれます。
- Salesforce がアクセストークンと関連付けられている範囲を検証します。
- Order Status (注文状況) アプリケーションが保護されているデータにアクセスでき、顧客の注文状況がアプリケーションに表示されます。
モバイルアプリケーションインテグレーション (OAuth 2.0 ユーザーエージェントフロー)
接続アプリケーションは、モバイルアプリケーションを Salesforce に結び付ける主要な手段です。Salesforce Mobile SDK は必ずしも必要ありませんが、この SDK を使用すると、モバイルアプリケーションを接続アプリケーションとして構築できます。これらのアプリケーションは、Salesforce OAuth サービスにアクセスして、Salesforce REST API をコールできます。
たとえば、Salesforce Mobile SDK を使用して、Salesforce 組織にある顧客の連絡先情報を検索するモバイルアプリケーションを構築するとします。Mobile SDK は、接続アプリケーションに OAuth 2.0 ユーザーエージェントフローを実装し、モバイルアプリケーションを Salesforce API に統合して、定義したデータに対する承認されたアクセスを許可します。
- エンドユーザーがモバイルアプリケーションを開きます。
- このモバイルアプリケーションを認証して承認するために、接続アプリケーションがユーザーを Salesforce にリダイレクトします。
- ユーザーはこの認証フローのアクセスを承認します。
- アプリケーションが Salesforce からリダイレクト URL へのコールバックを受信し、アクセストークンと更新トークンを抽出します。
- 接続アプリケーションがこのアクセストークンを使用して、エンドユーザーの代わりにデータにアクセスします。
Salesforce Mobile SDK についての詳細は、Trailhead の「Salesforce Mobile SDK の基礎」モジュールを参照してください。
サーバー間インテグレーション (OAuth 2.0 JWT ベアラーフロー)
サーバーが情報交換を必要とするたびに対話形式のログインをしなくても、サーバーが認証されるようにする必要のあることがあります。
サーバー間インテグレーションの認証を行う場合は、OAuth 2.0 JSON Web トークン (JWT) ベアラーフローを使用できます。このフローには、クライアントアプリケーションの事前承認が必要です。
- レポートサービスが、夜間のバッチレポートを開始します。
- 接続アプリケーションが、ID やセキュリティ情報をセキュリティドメイン全体で共有できるようにする JWT を Salesforce トークンエンドポイントに送信します。
- Salesforce が、以前に設定された証明書と追加のパラメーターを使用して、署名を基に JWT を検証します。
- JWT が有効で、接続アプリケーションに事前承認があるものとして、Salesforce がアクセストークンを発行します。事前承認は、次のいずれかの方法で実行されます。
- 接続アプリケーションのポリシーが [管理者が承認したユーザーは事前承認済み] に設定されている場合は、プロファイルと権限セットを使用できます。
- 接続アプリケーションのポリシーが [すべてのユーザーは自己承認可能] に設定されている場合は、エンドユーザーの承認と更新トークンの発行を使用できます。ただし、クライアントに現在の更新トークンや保存されている更新トークンは必要ありません。また、クライアントがクライアントの秘密をトークンエンドポイントに渡す必要もありません。
- 接続アプリケーションがアクセストークンを使用して、Salesforce サーバー上の保護されているデータにアクセスします。
- レポートサービスが、承認されたデータを夜間のレポートに取り込みます。
IoT インテグレーション (OAuth 2.0 デバイスフロー)
スマートテレビなど入力機能や表示機能が限定されたデバイスを統合する場合は、接続アプリケーションに OAuth 2.0 デバイスフローを設定できます。
デバイスフローでは、エンドユーザーが Web ベースのブラウザーを使用して接続アプリケーションの Salesforce データへのアクセスを承認できます。
たとえば、顧客が夜外出先から Bluetooth デバイスを使用して自宅の照明を管理するとします。この場合、Bluetooth デバイスの接続アプリケーションを作成して、このフローを有効にすることができます。
- ユーザーがモバイルデバイスで Bluetooth アプリケーションを開き、[Turn On Lights (点灯)] をクリックします。
- 接続アプリケーションが要求を Salesforce 認証エンドポイントに POST します。
- Salesforce がこの要求を検証し、人間が判読可能なユーザーコード、検証 URL、デバイスコードを返します。
- Bluetooth アプリケーションにデバイスコードが表示され、指定された検証 URL にそのコードを入力するようユーザーに指示します。アプリケーションはまた、認証のために Salesforce トークンエンドポイントのポーリングを開始します。
- ユーザーが検証 URI へのリンクをクリックして、コードを入力します。
- 続いて、アプリケーションに、保護されているデータ (この場合は自宅の所在地) へのアクセスを承認します。
- Salesforce がアクセストークンと更新トークンを接続アプリケーションに送信します。
- Bluetooth アプリケーションがユーザーの自宅の所在地にアクセスして点灯します。
IoT インテグレーションにはアセットトークンフローも使用できます。このフローでは、ユーザーとデバイスをつなげる JWT を使用して、デバイスを認証します。このフローについての詳細は、Salesforce ヘルプの「OAuth 2.0 アセットトークンフロー」を参照してください。
その他の OAuth API インテグレーションフロー
接続アプリケーションでは、上記の例以外に、次の OAuth 2.0 フローも使用できます。
更新トークンフロー
Web サーバーフローやユーザーエージェントフローの中で、現在のアクセストークンの期限が切れた後、接続アプリケーションが更新トークンを使用して、新しいアクセストークンを要求できます。このフローは特に、アプリケーションを承認後にユーザーを煩わせたくない場合に役立ちます。
クライアントログイン情報フロー
ユーザー操作を必要とせずに 2 つのアプリケーション間で直接情報を共有したい場合は、OAuth 2.0 クライアントログイン情報フローを使用できます。このフローでは、クライアントアプリケーションによってアクセストークン用に接続アプリケーションで定義されたクライアントログイン情報 (コンシューマー鍵とコンシューマーの秘密) が交換されます。このフローでは明示的なユーザー操作の必要はなくなりますが、インテグレーションを実行するインテグレーションユーザーを指定する必要があります。このフローを、OAuth 2.0 ユーザー名パスワードフローに代わるより安全な方法として使用できます。
SAML ベアラーアサーションフロー
接続アプリケーションは、SAML アサーションを使用して、Salesforce API をコールする OAuth アクセストークンを要求できます。
SAML アサーションフロー
現在 SAML を使用して Salesforce にアクセスしているが、同じ方法で Web サービス API にもアクセスしたい組織にとって、このフローがその代替法になります。
リソース
- Trailhead モジュール: Identity の基本
- Salesforce ヘルプ: OAuth Authorization Flows (OAuth 認証フロー)
- Salesforce ヘルプ: OAuth フローを使用したアプリケーションの認証