Salesforce OAuth 2.0: 技術アーキテクトのための徹底解説

日付:

背景と応用シナリオ

現代のエンタープライズアーキテクチャにおいて、システム間の連携は不可欠です。特に Salesforce プラットフォームは、多くの企業にとって顧客データの中心であり、外部アプリケーションとの安全なデータ交換が求められます。この「安全なデータ交換」を実現するための業界標準プロトコルが OAuth 2.0 (オーオース 2.0) です。

OAuth 2.0 は、ユーザーのパスワードを外部アプリケーションに直接渡すことなく、特定のリソースへの限定的なアクセス権を委譲（Delegation）するための認可フレームワークです。これにより、ユーザーは自分の Salesforce 認証情報を危険にさらすことなく、サードパーティアプリケーションに Salesforce データへのアクセスを許可できます。

Salesforce の技術アーキテクトとして、OAuth 2.0 を理解することは、安全でスケーラブルなインテグレーションソリューションを設計するための基礎となります。具体的な応用シナリオは多岐にわたります。

  • ウェブアプリケーション連携： 外部のウェブアプリケーション（例：顧客サポートポータル、BI ダッシュボード）が、ログインしているユーザーのコンテキストで Salesforce の取引先や商談データを表示・更新する。
  • モバイルアプリケーション： カスタムモバイルアプリが、Salesforce をバックエンドとして利用し、ユーザーの ToDo や活動履歴を取得する。
  • サーバー間連携： 夜間のバッチ処理で、外部の ERP システムが Salesforce の商品マスタや在庫データを同期する。この場合、ユーザーの介在は不要です。

これらのシナリオを安全かつ効率的に実現するために、Salesforce は OAuth 2.0 の複数のフローを提供しており、アーキテクトはユースケースに最適なフローを選択する責務を負います。

原理説明

OAuth 2.0 の仕組みを理解するために、まず主要な役割とコンセプトを把握することが重要です。

OAuth 2.0 の主要な役割

OAuth 2.0 のフローには、通常4つの役割が登場します。

1. Resource Owner (リソースオーナー):
保護されたリソース（例：Salesforce の取引先データ）の所有者であり、通常はエンドユーザーです。リソースへのアクセスを許可する権限を持ちます。

2. Client (クライアント):
Resource Owner のリソースにアクセスしようとするアプリケーション（例：外部のウェブアプリ、モバイルアプリ）です。Salesforce の世界では、これは接続アプリケーション (Connected App) として設定されます。

3. Authorization Server (認可サーバー):
Resource Owner を認証し、その同意を得た上で Client に Access Token (アクセストークン) を発行するサーバーです。Salesforce の場合、`login.salesforce.com` や My Domain の URL がこの役割を担います。

4. Resource Server (リソースサーバー):
保護されたリソースをホストするサーバーです。Client からの Access Token を検証し、リソースへのアクセスを許可します。Salesforce の各種 API エンドポイント（例：`/services/data/vXX.X/`）がこれに該当します。

主要なトークン

Access Token (アクセストークン):
リソースサーバーへの API リクエストを認可するために使用される、短い有効期間を持つ文字列です。API を呼び出す際、HTTP ヘッダーに `Authorization: Bearer [Access Token]` の形式で含めます。

Refresh Token (リフレッシュトークン):
Access Token が失効した際に、ユーザーの再認証なしで新しい Access Token を取得するために使用される、長い有効期間を持つトークンです。すべてのフローで発行されるわけではなく、セキュリティ上の観点から取り扱いには細心の注意が必要です。

Salesforce での主要な OAuth 2.0 フロー

Salesforce は、様々なユースケースに対応するために複数の Grant Type (グラントタイプ)、すなわち認可フローをサポートしています。ここでは代表的なものを紹介します。

1. OAuth 2.0 Web Server Flow (ウェブサーバーフロー):
サーバーサイドで動作するウェブアプリケーション向けの最も標準的で安全なフローです。Client の認証情報である Client Secret (クライアントシークレット) をサーバー側で安全に保持できることが前提です。ユーザーの同意を得た後、認可コードを介して Access Token と Refresh Token を取得します。

2. OAuth 2.0 User-Agent Flow (ユーザーエージェントフロー):
JavaScript を使用するシングルページアプリケーション (SPA) や、デスクトップアプリケーションなど、Client Secret を安全に保持できないクライアント向けのフローです。Access Token は直接ブラウザに返されますが、セキュリティ上の理由から Refresh Token は発行されません。

3. OAuth 2.0 JWT Bearer Flow (JWT ベアラーフロー):
ユーザーの操作を介さずに、サーバー間で事前に承認されたアクセスを行うためのフローです。クライアントはデジタル署名された JSON Web Token (JWT) を使用して自身を認証し、Access Token を取得します。データ同期などのバッチ処理に最適です。

示例代码

ここでは、最も一般的に使用される OAuth 2.0 Web Server Flow の実装手順を、Salesforce 公式ドキュメントに基づいたリクエスト例と共に解説します。このフローは、ユーザーのブラウザを介したリダイレクトを伴う2つの主要なステップで構成されます。

前提として、Salesforce 側で接続アプリケーション (Connected App) が作成され、Consumer Key (Client ID) と Consumer Secret (Client Secret) が発行されているものとします。

ステップ1: ユーザーを認可エンドポイントへリダイレクト

アプリケーションは、まずユーザーを Salesforce の認可エンドポイントにリダイレクトします。ユーザーはそこで Salesforce にログインし、アプリケーションからのアクセス許可を求められます。

以下は、ユーザーをリダイレクトさせるための URL の構築例です。

GET https://MyDomainName.my.salesforce.com/services/oauth2/authorize?response_type=code&client_id=3MVG9...&redirect_uri=https://www.myapplication.com/callback&scope=api%20refresh_token

パラメータ解説

  • `https://MyDomainName.my.salesforce.com/services/oauth2/authorize`: Salesforce の認可エンドポイント。`MyDomainName` は組織の My Domain に置き換えます。
  • `response_type=code`: Web Server Flow を使用することを示し、認可サーバーに認可コード (Authorization Code) を要求します。
  • `client_id`: 接続アプリケーションの Consumer Key。アプリケーションを識別します。
  • `redirect_uri`: ユーザーが認可を完了した後にリダイレクトされる URL。接続アプリケーションの設定で指定したコールバック URL と完全に一致する必要があります。URL エンコードされている必要があります。
  • `scope`: アプリケーションが要求する権限の範囲。スペースで区切ります (URL エンコード後は `%20`)。`api` は API アクセス、`refresh_token` は Refresh Token の発行を要求します。

ステップ2: 認可コードをアクセストークンと交換

ユーザーがアクセスを許可すると、Salesforce は `redirect_uri` に指定された URL へユーザーをリダイレクトさせます。その際、URL のクエリパラメータとして一時的な `code` (認可コード) が付与されます。

アプリケーションのサーバーは、この認可コードを受け取り、それを使って Salesforce のトークンエンドポイントに POST リクエストを送信し、Access Token と Refresh Token を取得します。

以下は、cURL を使用したトークンリクエストの例です。

POST /services/oauth2/token HTTP/1.1
Host: MyDomainName.my.salesforce.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=aPrx...%3D%3D&
client_id=3MVG9...&
client_secret=B64...&
redirect_uri=https://www.myapplication.com/callback

パラメータ解説

  • `/services/oauth2/token`: Salesforce のトークンエンドポイント。
  • `grant_type=authorization_code`: 認可コードを使用してトークンを要求していることを示します。
  • `code`: ステップ1で取得した認可コード。このコードは一度しか使用できず、有効期間も非常に短いです。
  • `client_id`: 接続アプリケーションの Consumer Key。
  • `client_secret`: 接続アプリケーションの Consumer Secret。この値は絶対にクライアントサイド（ブラウザなど）に含めてはならず、サーバーサイドで厳重に管理する必要があります。
  • `redirect_uri`: ステップ1で使用したものと完全に同じコールバック URL。リクエストの正当性を検証するために使用されます。

このリクエストが成功すると、Salesforce は以下のような JSON レスポンスを返します。

{
    "access_token": "00D...!",
    "refresh_token": "5A...!",
    "signature": "...",
    "scope": "api refresh_token",
    "instance_url": "https://MyDomainName.my.salesforce.com",
    "id": "https://login.salesforce.com/id/00D...",
    "token_type": "Bearer",
    "issued_at": "167..."
}

アプリケーションは、このレスポンスから `access_token` を抽出し、以降の Salesforce API へのリクエスト時に HTTP の `Authorization` ヘッダーに含めて使用します。

注意事項

OAuth 2.0 を実装する際には、セキュリティと安定性を確保するためにいくつかの重要な点に注意する必要があります。

権限とスコープ (Permissions and Scopes)

要求する `scope` は、アプリケーションが必要とする最小限の権限に留めるべきです（最小権限の原則）。例えば、ユーザー情報のみが必要な場合は `openid` を、API アクセスが必要な場合は `api` を指定します。不必要に広範な権限を要求すると、ユーザーに不信感を与え、認可を拒否される可能性があります。また、接続アプリケーションの設定で許可されたスコープしか要求できません。

API 制限 (API Limits)

OAuth 2.0 フローを経て取得した Access Token を使用した API コールは、すべて Salesforce 組織の API 制限（例: 24時間あたりの合計 API リクエスト数）の対象となります。アーキテクトは、インテグレーションが API 制限に与える影響を評価し、必要に応じて効率的な API 利用（複合リクエストなど）を検討する必要があります。

エラー処理 (Error Handling)

OAuth フローの各ステップでエラーが発生する可能性があります。例えば、ユーザーがアクセスを拒否した場合、`redirect_uri` に `error=access_denied` といったパラメータが付与されて戻ってきます。また、トークンリクエストが失敗した場合（例: `invalid_grant`）、アプリケーションはこれを適切に処理し、ユーザーに再認証を促すなどのフォールバック処理を実装する必要があります。

セキュリティに関する考慮事項

  • Client Secret の保護: Web Server Flow や JWT Bearer Flow で使用する Client Secret や秘密鍵は、アプリケーションの最も重要な認証情報です。これらが漏洩すると、第三者がアプリケーションになりすますことが可能になります。環境変数やセキュアなシークレット管理サービスを利用し、ソースコードにハードコーディングすることは絶対に避けてください。
  • Redirect URI の完全一致: Salesforce の認可サーバーは、リクエストで指定された `redirect_uri` が、接続アプリケーションに登録されたコールバック URL と完全に一致するかを検証します。これは、認可コードを悪意のあるサイトに横取りされるのを防ぐための重要なセキュリティ対策です。
  • Refresh Token の安全な保管: Refresh Token は長期間有効であり、新しい Access Token を無制限に取得できる強力なトークンです。データベースに保存する際は、必ず暗号化してください。また、ユーザーがアプリケーション連携を解除した際には、API を介して Refresh Token を無効化 (Revoke) する処理を実装することが推奨されます。

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

OAuth 2.0 は、Salesforce と外部アプリケーションを安全に連携させるための根幹をなす技術です。技術アーキテクトとして、各フローの特性とトレードオフを深く理解し、プロジェクトの要件に最適なものを選択することが求められます。

フロー選択のベストプラクティス

  • サーバーサイドのウェブアプリケーションの場合: 常に Web Server Flow を選択してください。Client Secret を安全に管理でき、Refresh Token を利用できるため、最も安全で持続的な連携が可能です。
  • クライアントサイドの SPA やモバイルアプリの場合: Client Secret を保護できないため、User-Agent Flow を使用します。ただし、最近ではより安全な Authorization Code with PKCE Flow が推奨されています。このフローは User-Agent Flow の脆弱性を補うものです。
  • サーバー間のシステム連携の場合: ユーザーの介在が不要な場合は、JWT Bearer Flow が最適です。証明書ベースの認証により、高いセキュリティレベルで自動化されたプロセスを実現できます。

最終的に、優れたインテグレーション設計とは、機能要件を満たすだけでなく、セキュリティ、スケーラビリティ、そして保守性を高いレベルで両立させることです。OAuth 2.0 の原則を正しく適用し、Salesforce が提供する機能を最大限に活用することで、堅牢で信頼性の高いソリューションを構築することができるでしょう。

コメント

コメントを投稿