Salesforce OAuth 2.0 ガイド：セキュアなAPI連携のための実践的解説

執筆者：Salesforce 統合エンジニア

背景と適用シナリオ

現代のビジネス環境において、Salesforceは単なるCRMプラットフォームではなく、企業のデジタルトランスフォーメーションを支えるエコシステムの中心となっています。外部のWebアプリケーション、モバイルアプリ、またはバックエンドシステムとSalesforceを連携させることは、業務効率の向上や新たな顧客体験の創出に不可欠です。しかし、これらのシステム連携を実現する上で最も重要な課題の一つが「セキュリティ」です。

外部アプリケーションがSalesforceのデータにアクセスする際、ユーザーの認証情報を直接共有するのは非常に危険です。パスワードが漏洩した場合、甚大な被害につながる可能性があります。ここで登場するのが OAuth (Open Authorization) 2.0 です。OAuth 2.0 は、ユーザーの認証情報を共有することなく、サードパーティアプリケーションに対して特定のリソースへの限定的なアクセス権を付与するための業界標準プロトコルです。これは「委任された認可（Delegated Authorization）」のフレームワークとして機能します。

Salesforce統合エンジニアとして、私が携わるプロジェクトでは以下のようなシナリオでOAuth 2.0が頻繁に利用されます。

Webアプリケーション連携： 顧客が利用する外部のWebポータルから、Salesforceに保存されている自身の契約情報やケース履歴を安全に閲覧・更新する。
モバイルアプリケーション連携： 営業担当者が外出先で使うカスタムモバイルアプリから、Salesforceの商談情報や取引先責任者データにアクセスする。
サーバー間連携 (Server-to-Server Integration)： 夜間バッチ処理で、外部のERPシステムからSalesforceへ最新の在庫データを自動的に同期する。このシナリオではユーザーの介在は不要です。

これらのシナリオにおいて、OAuth 2.0は、安全かつスケーラブルな連携アーキテクチャを構築するための基礎となります。本記事では、SalesforceにおけるOAuth 2.0の基本原理から、具体的なフロー、そして実装上の注意点までを、統合エンジニアの視点から詳しく解説します。

原理説明

OAuth 2.0を理解するためには、まず主要な登場人物（ロール）と概念を把握する必要があります。

OAuth 2.0 の主要なロール

Resource Owner (リソースオーナー): 保護されたリソース（例：Salesforce上の取引先データ）の所有者。通常はエンドユーザー本人です。
Client (クライアント): Resource Ownerの代わりにリソースサーバー上のリソースにアクセスしようとするアプリケーション。Salesforceの世界では、これは接続アプリケーション (Connected App) に相当します。
Authorization Server (認可サーバー): Resource Ownerを認証し、その同意を得た上で、Clientに対してアクセストークンを発行するサーバー。Salesforceプラットフォーム自体がこの役割を担います。
Resource Server (リソースサーバー): 保護されたリソースをホストしているサーバー。Clientからのアクセストークンを検証し、リクエストされたリソースへのアクセスを許可します。これもSalesforceプラットフォームが担います。

重要な概念

Access Token (アクセストークン): クライアントがリソースサーバーにアクセスするために使用する、一時的な資格情報です。有効期間が短く設定されており、セキュリティリスクを低減します。
Refresh Token (リフレッシュトークン): アクセストークンの有効期限が切れた際に、新しいアクセストークンを再取得するために使用されるトークンです。リフレッシュトークンを使用することで、ユーザーは毎回ログイン操作を行う必要がなくなります。
Scopes (スコープ): クライアントが要求するアクセス権の範囲を定義します。例えば、「`api`」スコープはAPI経由でのデータアクセスを許可し、「`refresh_token`」スコープはリフレッシュトークンの取得を許可します。最小権限の原則に従い、必要なスコープのみを要求することがベストプラクティスです。

Salesforceがサポートする主要なOAuth 2.0フロー

Salesforceは、様々なユースケースに対応するために複数のOAuth 2.0フロー（グラントタイプとも呼ばれます）を提供しています。統合エンジニアとして、シナリオに応じて最適なフローを選択することが極めて重要です。

1. Authorization Code Grant Flow (認可コードグラントフロー) / Web Server Flow (ウェブサーバーフロー)

これは、サーバーサイドで動作するWebアプリケーションにとって最も安全で一般的なフローです。ユーザーがブラウザを介して操作を行い、クライアント（Webアプリ）と認可サーバー（Salesforce）が直接やり取りします。全体の流れは以下の通りです。

ユーザーがWebアプリ上の「Salesforceでログイン」ボタンをクリックします。
WebアプリはユーザーをSalesforceの認可エンドポイントにリダイレクトします。このとき、`client_id`や`scope`などのパラメータを渡します。
ユーザーはSalesforceのログイン画面で認証を行い、アプリケーションへのアクセス許可を承認します。
Salesforceは、Webアプリに設定されたコールバックURLにユーザーをリダイレクトし、一時的な「認可コード」を渡します。
Webアプリのバックエンドは、受け取った認可コードと自身の`client_secret`を使って、Salesforceのトークンエンドポイントにリクエストを送信します。
Salesforceは認可コードと`client_secret`を検証し、問題がなければアクセストークンとリフレッシュトークンを返却します。

このフローの利点は、アクセストークンがユーザーのブラウザを経由せず、サーバー間で直接交換されるため、セキュリティが高い点にあります。

2. JWT (JSON Web Token) Bearer Flow (JWTベアラーフロー)

これは、サーバー間連携など、ユーザーの介在なしにシステムがSalesforce APIにアクセスする必要がある場合に最適なフローです。事前にSalesforceとクライアント（外部システム）の間で信頼関係を確立しておく必要があります。

クライアントは、自身の情報、対象ユーザー、有効期限などを含むクレームセットを作成します。
このクレームセットを、事前に取得した秘密鍵（X509証明書）で署名し、JWT (JSON Web Token) を生成します。
クライアントは生成したJWTをSalesforceのトークンエンドポイントに送信します。
Salesforceは、接続アプリケーションに登録された公開鍵を使ってJWTの署名を検証します。
検証に成功し、かつ管理者が事前にユーザーのアクセスを許可している場合、Salesforceはアクセストークンを発行します。

このフローでは、ユーザーのパスワードを扱う必要がなく、またリフレッシュトークンの管理も不要なため、自動化されたプロセスに非常に適しています。

3. Username-Password Flow (ユーザー名パスワードフロー)

このフローでは、クライアントがユーザーのSalesforceユーザー名とパスワードを直接収集し、それらを使ってアクセストークンを取得します。しかし、この方法はセキュリティリスクが非常に高いため、強く非推奨とされています。アプリケーションがユーザーの認証情報を保持する必要があり、パスワード漏洩のリスクが伴います。他のフローが利用できない、非常に限定されたレガシーシステムや、クライアントが完全に信頼できる内部システムでのみ検討されるべきです。統合エンジニアとしては、可能な限りこのフローを避けるべきです。

示例代码

ここでは、サーバー間連携で最も強力なJWTベアラーフローをApexで実装する例を示します。外部システムがSalesforceに接続する場合もロジックは同じです。まず、JWTを生成し、それを使ってアクセストークンを要求します。

このコードは、指定されたユーザーとして認証するためのJWTを生成し、SalesforceのトークンエンドポイントにPOSTリクエストを送信してアクセストークンを取得するものです。

// Auth.JWT クラスのインスタンスを作成
Auth.JWT jwt = new Auth.JWT();

// issuer (発行者) を設定。これは接続アプリケーションのコンシューマキー (Client ID)
jwt.setIss('3MVG99OxTyEMCQ3gN_p4aP0E6334v9_C3G5a5I.2bQpuA5fYx3j2qQ8sYGfey12aG28fSr3NohtVf3j.d2BF8');

// audience (対象者) を設定。本番環境の場合は https://login.salesforce.com、Sandboxの場合は https://test.salesforce.com
jwt.setAud('https://login.salesforce.com');

// subject (主題) を設定。これはAPIにアクセスしたいユーザーのSalesforceユーザー名
jwt.setSub('user@example.com');

// 追加のクレームを設定。ここでは有効期限を現在時刻から5分後に設定
jwt.setAdditionalClaims(new Map<String, Object>{'exp' => String.valueOf((DateTime.now().getTime() / 1000) + 300)});

// 接続アプリケーションにアップロードした証明書の開発者名 (API Name) を指定して、JWTに署名
// これは [設定] > [セキュリティ] > [証明書と鍵の管理] で確認できます
Auth.JWS jws = new Auth.JWS(jwt, 'MySelfSignedCert');

// JWS (JSON Web Signature) をコンパクトなシリアル化形式で取得
String token = jws.getCompactSerialization();

// Auth.OAuth2 クラスを使ってトークンを要求する準備
Auth.OAuth2 oauth = new Auth.OAuth2();
oauth.setJwt(token);
oauth.setTokenEndpoint('https://login.salesforce.com/services/oauth2/token');

// トークンを要求し、アクセストークンを取得
String accessToken = oauth.getAccessToken();

// 取得したアクセストークンを使用してAPIコールを実行
if (accessToken != null) {
    HttpRequest req = new HttpRequest();
    // 例として、取引先責任者のクエリを実行
    req.setEndpoint(URL.getOrgDomainUrl().toExternalForm() + '/services/data/v58.0/query?q=SELECT+Id,Name+FROM+Contact+LIMIT+1');
    req.setMethod('GET');
    // Authorization ヘッダーにアクセストークンを設定
    req.setHeader('Authorization', 'Bearer ' + accessToken);

    Http http = new Http();
    HTTPResponse res = http.send(req);
    System.debug('Response Body: ' + res.getBody());
}

注意事項

OAuth 2.0を実装する際には、いくつかの重要な点に注意する必要があります。これらを怠ると、セキュリティホールや予期せぬエラーの原因となります。

1. 接続アプリケーション (Connected App) の設定

コールバックURL (Callback URL): 認可コードフローを使用する場合、Salesforceが認可コードを送信する先のURLを正確に設定する必要があります。これにより、悪意のあるサイトへのリダイレクトを防ぎます。
OAuthスコープの選択: 必要な権限のみをスコープとして選択してください。例えば、データを読み取るだけであれば`api`スコープで十分です。ユーザーの代わりにオフラインでアクセスする必要がある場合にのみ`refresh_token`スコープを追加します。
証明書のアップロード (JWTベアラーフロー): JWTベアラーフローを使用する場合、クライアント側で生成した証明書の公開鍵を接続アプリケーションにアップロードする必要があります。これにより、Salesforceはクライアントから送られてくるJWTの署名を検証できます。
ユーザーの事前承認: JWTベアラーフローでは、管理者がプロファイルまたは権限セットを使用して、この接続アプリケーションの利用をユーザーに事前に許可しておく必要があります。「管理者が承認したユーザは事前承認済み」ポリシーを設定します。

2. トークンの安全な管理

トークンの保管: 取得したアクセストークンやリフレッシュトークンは、サーバーサイドの安全な場所に保管してください。データベースに保存する場合は、必ず暗号化する必要があります。クライアントサイド（ブラウザなど）にリフレッシュトークンを保存することは絶対に避けてください。
リフレッシュトークンポリシー: Salesforceではリフレッシュトークンのポリシーを設定できます。「リフレッシュトークンが使用されるまで有効」または「リフレッシュトークンをすぐに無効化」など、セキュリティ要件に応じて適切なポリシーを選択してください。

3. API制限とエラーハンドリング

APIコール制限: Salesforceには組織ごと、ユーザーごとにAPIリクエスト数の制限があります。トークン取得のリクエストもこの制限に含まれるため、効率的なトークン管理が重要です。アクセストークンは有効期間内は再利用し、無駄なトークン取得リクエストを避けるべきです。
エラーレスポンスの処理: トークン取得に失敗した場合、Salesforceは`error`と`error_description`を含むJSONレスポンスを返します。例えば、`invalid_grant`（無効な認可コードやJWT）、`invalid_client_id`（無効なクライアントID）などのエラーコードを適切にハンドリングし、ログに記録する仕組みを実装することが重要です。

まとめとベストプラクティス

OAuth 2.0は、Salesforceと外部システムを安全に連携させるための根幹をなす技術です。統合エンジニアとして、その仕組みを深く理解し、プロジェクトの要件に最適なフローを選択することが、堅牢でスケーラブルなソリューションを構築する鍵となります。

以下に、本記事で解説した内容に基づくベストプラクティスをまとめます。

適切なフローを選択する: ユーザーが介在するWebアプリケーションには「認可コードフロー」を、サーバー間の自動連携には「JWTベアラーフロー」を選択します。「ユーザー名パスワードフロー」は原則として使用を避けてください。
最小権限の原則を遵守する: 接続アプリケーションのスコープは、アプリケーションが必要とする最小限の権限に限定します。不要な権限を要求しないことで、万が一トークンが漏洩した際のリスクを低減できます。
全てのシークレットを安全に管理する: `client_secret`、秘密鍵、そして取得したトークンは、システムの最も重要な機密情報として扱ってください。環境変数や暗号化されたVaultサービスなどを利用し、コード内にハードコーディングすることは絶対に避けるべきです。
リフレッシュトークンのライフサイクルを考慮する: リフレッシュトークンは長期間有効なため、特に慎重な管理が求められます。トークンローテーションなどの仕組みを導入し、セキュリティをさらに強化することを検討してください。

SalesforceのAPI連携は、OAuth 2.0という強固な基盤の上に成り立っています。このフレームワークを正しく活用することで、私たちはビジネスの可能性を無限に広げる、安全で信頼性の高い統合ソリューションを提供できるのです。

にゃんこのSalesforce日記

このブログを検索