OAuth 認可フロー

たとえば、Salesforce データにアクセスするために Salesforce モバイルアプリケーションを開くと、OAuth 2.0 認可フローが開始されます。このフローでは、Salesforce 組織は、保護されたリソースをホストするリソースサーバーです。Salesforce モバイルアプリケーションは、アクセスを要求するクライアントです。あなたはリソース所有者で、Salesforce モバイルアプリケーションに、Web 経由でいつでも Salesforce データにアクセスして管理することを承認します。Salesforce 組織は、認証サーバーとして機能し、アクセストークンを発行して Salesforce モバイルアプリケーションにアクセス権を付与します。フローを 1 つずつ見ていきましょう。

1. Salesforce モバイルアプリケーションを開きます。
2. ユーザー名とパスワードを入力する認証画面が表示されます。
3. Salesforce モバイルアプリケーションがログイン情報を Salesforce に送信し、OAuth 認可フローを開始します。
4. Salesforce は、ユーザーおよびモバイルアプリケーションの検証成功の確認として、アクセストークンと更新トークンをモバイルアプリケーションに送信します。
5. Salesforce モバイルアプリケーションにアクセス権を付与する要求を承認します。
6. Salesforce モバイルアプリケーションが起動します。

この最初のフローの後、セッションが有効になるとすぐに Salesforce モバイルアプリケーションが起動します。セッションの期限が切れている場合は、Salesforce モバイルアプリケーションが初回認証で取得した更新トークンを使用して、更新されたセッションを取得します。

このアプローチを、クライアントアプリケーションにユーザー名とパスワードを指定して代わりにリソースサーバーにアクセスさせる方法と比較してみましょう。このクライアントアプリケーションは、まったく同じデータアクセス権で実質的にユーザーを偽装します。クライアントアプリケーションを信頼できなくなった場合、リソースサーバーでパスワードを変更する必要があります。これは不便なうえに、セキュリティリスクでもあります。こうした理由から、OAuth 認証はより適切なソリューションとなります。

OAuth 認可フローと外部クライアントアプリケーション

SAML アサーションフローを除くすべての OAuth 認可フローでは、外部クライアントアプリケーションを定義する必要があります。外部クライアントアプリケーションフレームワークを使用すると、API や標準プロトコル (SAML、OAuth、OpenID Connect など) を使用してサードパーティアプリケーションを Salesforce と統合できます。外部クライアントアプリケーションは、これらのプロトコルを使用して、外部アプリケーションとサービスプロバイダーを認証、承認、統合します。Salesforce と統合されている外部アプリケーションは、カスタマーサクセスプラットフォーム、デバイス、SaaS サブスクリプション、またはその他のプラットフォームで実行できます。上記の例では、Salesforce モバイルアプリケーションは外部クライアントアプリケーションを使用して組織と統合します。

メモ ユーザーは、外部クライアントアプリケーションが保護されたデータに複数回アクセスすることを承認できます (ラップトップ、デスクトップコンピューター、モバイルデバイスなど)。デフォルトでは、1 ユーザーにつき外部クライアントアプリケーションあたり 5 件の認証です。組織の制限に達した後にユーザーが外部クライアントアプリケーションへのアクセスを許可しようとすると、最も長い間使用されていないアクセストークンが取り消されます。Web サーバーフローを使用する新しい OAuth 2.0 外部クライアントアプリケーションは、ユーザーがアクセス権を付与すると、より多くのデバイスで承認されます。ユーザーエージェントフローでは、ユーザーの承認が毎回必要です。

OAuth 認可フローの使用事例

Salesforce 開発者は、いくつかの OAuth 認可フローから選択できます。アプリケーションに適切なフローを選択するとき、次の使用事例を考慮してください。

重要 一部のフローには、重要なセキュリティ上の考慮事項があります。たとえば、Web サーバーフローを使用するときには、クライアントの秘密をセキュアに保存する必要があります。ユーザーエージェントフローとユーザー名パスワードフローは、ログイン情報を送信するため、使用を避けることをお勧めします。代わりに、アプリケーションがログイン情報を管理、保存、および保護する必要のないフローを選択します。

• ヘッドレス ID フロー
  ヘッドレス ID API を使用して、プラットフォーム外アプリケーションのログイン、登録、パスワードなしのログインなどを設定できます。ヘッドレス ID フローは、外部ユーザーのみが使用できます。外部ユーザーは顧客やパートナーとも呼ばれます。
• アプリケーション内のネイティブのシングルサインオン環境の作成
  OAuth 2.0 Web サーバーフローとユーザーエージェントフローの省略可能なパラメーターを使用して、サードパーティアプリケーションが外部 ID プロバイダーと統合されているかのようなシングルサインオン (SSO) 環境を構築できます。このプロセスでは、アプリケーション内の環境を制御しながら、OAuth フローを SSO フローにリンクします。このパラメーターは Experience Cloud サイトでサポートされているため、この機能を使用して SSO をヘッドレス ID 実装に追加できます。このパラメーターは、[私のドメイン] でもサポートされています。
• Web アプリケーションインテグレーションの OAuth 2.0 Web サーバーフロー
  外部 Web アプリケーションを Salesforce API に統合するには、OAuth 2.0 認証コード許可種別を実装する OAuth 2.0 Web サーバーフローを使用します。このフローでは、Web アプリケーションをホストするサーバーが、クライアント ID とクライアントの秘密で定義された外部クライアントアプリケーションの ID を保護できる必要があります。
• デスクトップまたはモバイルアプリケーションのインテグレーションの OAuth 2.0 ユーザーエージェントフロー
  ユーザーは、OAuth 2.0 ユーザーエージェントフローを使用して、デスクトップまたはモバイルアプリケーションが外部ブラウザーや組み込みブラウザーを使用してデータにアクセスすることを承認します。JavaScript などのスクリプト言語を使用してブラウザー内で実行されるクライアントアプリケーションでも、このフローを使用できます。このフローは、OAuth 2.0 暗黙的許可種別を使用します。
• 更新セッションの OAuth 2.0 更新トークンフロー
  OAuth 2.0 更新トークンフローは、OAuth 2.0 Web サーバーフローまたは OAuth 2.0 ユーザーエージェントフローによって発行されたアクセストークンを更新します。
• OAuth 2.0 トークン交換フロー
  Salesforce が複数のアプリケーションやマイクロサービスと共に中央 ID プロバイダーが含まれるアーキテクチャの 1 つのコンポーネントにすぎない場合は、OAuth 2.0 トークン交換フローを使用してインテグレーションパターンを簡略化します。このフローでは、外部 ID プロバイダーからのトークンを Salesforce トークンと交換し、Salesforce データへのアクセス権を付与します。
• ハイブリッドアプリケーションの OAuth 2.0 認証およびセッション管理
  通常のユーザーエージェントまたは更新トークンフローでは、ハイブリッドアプリケーションの Web セッションの管理が複雑になります。これらのフローでは、ハイブリッドアプリケーションで、要求されたドメインの Cookie を設定してアクセストークンを Web セッションに連結します。ただし、このフローではアクセストークンと Web セッションは接続されません。代わりに、アクセストークンと更新トークンが期限切れになったときと Web セッションが期限切れになったときを追跡し、セッションを手動で再度連結して、サービスの中断を回避する必要があります。この複雑なプロセスを回避するには、OAuth 2.0 ハイブリッドアプリケーションを使用します。これらのフローでは、アクセストークンと更新トークンが Web セッションに接続され、ハイブリッドアプリケーションで Web セッションを直接管理できます。
• サーバー間インテグレーション用の OAuth 2.0 JWT ベアラーフロー
  サーバーが情報交換するたびに対話形式のログインをしなくてもデータにアクセスすることを承認したい場合があります。このような場合は、OAuth 2.0 JSON Web トークン (JWT) ベアラーフローを使用できます。このフローは、証明書を使用して JWT 要求に署名し、明示的なユーザー操作を必要としません。ただし、このフローには、クライアントアプリケーションの事前承認が必要です。
• サーバー間インテグレーション用の OAuth 2.0 クライアントログイン情報フロー
  ユーザーの介在なしで 2 つのアプリケーション間で情報を直接共有する必要がある場合があります。このようなシナリオでは、OAuth 2.0 クライアントログイン情報フローを使用できます。このフローでは、外部クライアントアプリケーションによってアクセストークン用に接続アプリケーションで定義されたクライアントログイン情報 (コンシューマー鍵とコンシューマーの秘密) が交換されます。このフローでは明示的なユーザー操作の必要はなくなりますが、インテグレーションを実行するインテグレーションユーザーを指定する必要があります。このフローを、OAuth 2.0 ユーザー名パスワードフローに代わるより安全な方法として使用できます。
• 外部 API ゲートウェイの OpenID Connect 動的クライアント登録
  一般的な認証フローではありませんが、OpenID Connect 動的クライアント登録を使用して、Salesforce インスタンスを独立した OAuth 認証サーバーとして有効化し、外部 API ゲートウェイでホストされるリソースを保護できます。
• 初期アクセストークンの生成
  OpenID Connect 動的クライアント登録により、OAuth 2.0 クライアント (接続アプリケーション) は接続アプリケーションを Salesforce に直接登録できます。このクライアント登録要求を認証するには、Salesforce で初期アクセストークンが必要です。
• OpenID Connect トークンイントロスペクション
  トークンイントロスペクションでは、認証プロセスの一環として、すべての Oauth 接続アプリケーションが OAuth 2.0 のアクセストークンや更新トークンの現在の状態を確認できます。リソースサーバーまたは接続アプリケーションが、クライアントアプリケーションのクライアント ID と秘密を認証サーバーに送信して、OAuth 認証フローを開始します。このフローの中で、認証サーバーがクライアントアプリケーションのアクセストークンを検証または調査します。アクセストークンが最新で有効な場合は、クライアントアプリケーションにアクセスが許可されます。
• IoT インテグレーションの OAuth 2.0 デバイスフロー
  スマートテレビ、アプライアンス、およびその他の IoT デバイスなど入力機能や表示機能が限定されたデバイスを統合するには、OAuth 2.0 デバイスフローを使用します。コマンドラインアプリケーションでもこのフローを使用できます。ユーザーは、より高度な入力機能を持つデバイス (デスクトップ、モバイルデバイスなど) でブラウザーにアクセスすることで、これらのアプリケーションを Salesforce に接続できます。
• 接続デバイスを保護するための OAuth 2.0 アセットトークンフロー
  IoT デバイスを Salesforce API に統合するには、OAuth 2.0 アセットトークンフローを使用します。アセットトークンとは、接続デバイスからの要求を検証してそのセキュリティを確保することを目的とするオープン標準ベースの JWT 認証トークンです。アセットトークンは、データのストリームやデバイスからのイベントを処理するバックエンドサービスに対してデバイスを識別します。これらのトークンを使用すると、Salesforce Platform にデバイスデータを登録したり、顧客、取引先、または取引先責任者に関する Salesforce CRM データにデバイスデータをリンクしたりできます。
• アセットトークンフローのデモ
  アセットトークンのクイックデモでは、「Asset Token Explorer (アセットトークンエクスプローラー)」デモアプリケーションを使用できます。このデモアプリケーションでは、アクセストークンを取得してアセットトークンと交換するための初期操作が簡素化されています。
• 特別なシナリオの OAuth 2.0 ユーザー名パスワードフロー
  すでにユーザーのログイン情報がある接続アプリケーション経由で、ユーザー名パスワードフローを使用してクライアントを承認できます。ただし、このフローはログイン情報をやりとりするため、使用を避けることをお勧めします。このフローの使用は、リソース所有者とクライアントの間に確固たる信頼があり、クライアントがファーストパーティアプリケーションで、Salesforce がデータを提供し、他の許可種別を使用できない場合に限定します。こうした場合、アクセス権が最小限になるようにユーザー権限を設定し、保存されているログイン情報を不正なアクセスから保護します。
• 認証フローをブロックしてセキュリティを強化
  OAuth 2.0 ユーザーエージェントフローとユーザー名パスワードフローは安全でないとみなされ、推奨されません。セキュリティを強化するために、Salesforce でこれらのフローブロックし、開発者が新しいインテグレーションを構築するためにこれらを使用できないようにすることを強くお勧めします。組織が Summer '23 以降に作成されている場合、ユーザー名パスワードフローはデフォルトでブロックされます。必要に応じて、ユーザー名パスワードフローを有効にすることができます。ユーザーエージェントフローまたはユーザー名パスワードフローを使用する既存のインテグレーションがある場合は、よりセキュアな OAuth 2.0 フローに更新します。ヘッドレスログインプロセスを安全に設定するために使用する、認証コードとログイン情報フローをブロックすることもできます。PKCE 拡張機能を使用しない特定のフローをブロックすることもできます。
• 以前に承認されたアプリケーションの OAuth 2.0 SAML ベアラーアサーションフロー
  OAuth 2.0 SAML ベアラーアサーションフローでは、クライアントは接続アプリケーション経由で以前の認証を使用 (署名済み SAML 2.0 アサーションを指定) して、OAuth アクセストークンを要求できます。SAML アサーションに適用されるデジタル署名で、承認されたアプリケーションが認証されます。SAML アサーションは、ID プロバイダーが提供し、サービスプロバイダーが使用する XML セキュリティトークンです。サービスプロバイダーは、セキュリティ関連の目的でその内容を使用してアサーションの件名を識別します。
• API にアクセスするための SAML アサーションフロー
  SAML アサーションフローは、SAML を使用して Salesforce にアクセスしていて、同じ方法で API にアクセスする必要のある組織にとって、代替フローとなります。クライアントは SAML アサーションを使用して、Web シングルサインオン (Web SSO) 用に Salesforce を統合する場合と同じ方法で API を統合できます。このアサーションフローは、接続アプリケーションなしで使用できます。
• OAuth 2.0 認証エラー
  OAuth 認証中にエラーが発生することがあります。たとえば、ユーザーが接続アプリケーションへのアクセスを拒否したり、要求パラメーターに誤りがあったりした場合などです。エラーが発生すると、認証サーバーはエラーコードと共にエラーをコールバック URL に送信します。
• OAuth 1.0.A フロー
  組織で OAuth 1.0.A プロトコルを使用している場合は、この認証フローを使用してクライアントを統合します (接続アプリケーション経由で Salesforce API を使用)。
• OAuth 1.0.A 認証エラーコード
  認証中にエラーが発生することがあります。たとえば、コールバック URL が無効な場合などです。OAuth 1.0.A フロー中にエラーが発生すると、Salesforce はエラーコードを返します。