Salesforce APIの認証の仕組みとそのやり方

Salesforce APIを活用して外部システムとのデータ連携を実現する際に、必ず理解しておく必要があるのが「認証」の仕組みです。

適切な認証方法を選択し、正しく実装することで、セキュアで効率的なAPI連携を構築することができます。

本記事では、Salesforceの導入サポート、開発・連携を行う(株)FDCのエンジニアチームが、Salesforce APIの認証の基本的な仕組みから具体的な実装方法まで、初心者の方にもわかりやすく解説していきます。

Salesforce APIにおける認証の重要性
1. 認証と認可の違い
接続アプリケーション（Connected Apps）とは
1. 接続アプリケーションの役割
2. 接続アプリケーションの作成手順
OAuth 2.0認証フローの種類と選び方
アクセストークンとリフレッシュトークンの仕組み
REST APIとSOAP APIの認証方法の違い
1. REST APIの認証
2. SOAP APIの認証
API認証実装時のセキュリティベストプラクティス
認証エラーのトラブルシューティング
1. よくある認証エラーと対処法
2. デバッグのポイント
2025年以降の認証に関する重要な変更点
まとめ：Salesforce API認証の実装支援について

Salesforce APIにおける認証の重要性

Salesforce APIを利用する際、認証は外部アプリケーションがSalesforceのデータやリソースに安全にアクセスするための最も重要なセキュリティ機能です。認証がなければ、誰でも自由にSalesforceのデータにアクセスできてしまい、情報漏洩や不正操作のリスクが高まります。

Salesforceでは、API経由でデータにアクセスする際に、必ず認証プロセスを経る必要があります。これにより、正規のユーザーやアプリケーションのみがアクセスできるよう保護されています。

認証と認可の違い

API連携を理解する上で、「認証」と「認可」の違いを明確にしておくことが重要です。

項目	認証（Authentication）	認可（Authorization）
目的	「誰であるか」を確認する	「何ができるか」を確認する
具体例	ユーザー名とパスワードでログイン	特定のオブジェクトへのアクセス権限
実装	OAuthフローによる本人確認	スコープやアクセス権限の設定

Salesforceでは、この両方のプロセスを組み合わせることで、セキュアなAPI連携を実現しています。

接続アプリケーション（Connected Apps）とは

Salesforce APIの認証を実装する際、まず理解しておくべきなのが「接続アプリケーション」です。接続アプリケーションは、外部アプリケーションとSalesforceを統合するためのフレームワークで、APIや標準プロトコル（OAuth、SAML、OpenID Connectなど）を使用して認証・認可を管理します。

接続アプリケーションの役割

接続アプリケーションは、外部クライアントアプリケーションに代わってREST APIリソースへのアクセスを要求します。OAuth 2.0プロトコルを使用して統合される接続アプリケーションは、トークンの交換を通じてセキュアなデータ共有を実現します。

外部アプリケーションの認証情報を一元管理
OAuth 2.0による安全な認証フローを提供
アクセス範囲（スコープ）の制限が可能
接続の監視と管理が容易

接続アプリケーションの作成手順

Salesforceで接続アプリケーションを作成する基本的な手順は以下の通りです。

Salesforceの[設定]から[アプリケーションマネージャー]を開く
[新規接続アプリケーション]をクリック
基本情報（アプリケーション名、API名、連絡先メールなど）を入力
[OAuth設定の有効化]にチェックを入れる
コールバックURLを設定
必要なOAuthスコープを選択
保存して完了

なお、2025年9月以降、組織に正式にインストールされていない接続アプリケーションの新規利用が制限されるようになりました。そのため、接続アプリケーションを使用する際は、必ず組織にインストールする必要があります。

OAuth 2.0認証フローの種類と選び方

Salesforceでは、様々なユースケースに対応するために複数のOAuth 2.0認証フローを提供しています。それぞれのフローには特徴があり、利用シーンに応じて適切なフローを選択することが重要です。

主要な認証フロー一覧

認証フロー	用途	特徴
Web サーバーフロー	Webアプリケーション	最も一般的で安全なフロー。認証コードとアクセストークンを使用
ユーザーエージェントフロー	モバイル・SPAアプリ	クライアント側で完結。現在は非推奨でセキュリティリスクあり
JWT ベアラーフロー	サーバー間連携	ユーザー操作不要。自動化されたバッチ処理などに最適
クライアントクレデンシャルフロー	サーバー間連携	アプリケーション自体の認証に使用
リフレッシュトークンフロー	トークン更新	有効期限が切れたアクセストークンを再取得

Web サーバーフロー（推奨）

Web サーバーフローは、OAuth 2.0認証コード許可種別を実装したフローで、外部Webアプリケーションを統合する際に最も推奨される方法です。このフローでは、以下の手順で認証が行われます。

クライアントアプリケーションが認証リクエストを送信
ユーザーがSalesforceにログインして承認
Salesforceが認証コードを発行
クライアントアプリが認証コードをアクセストークンに交換
アクセストークンを使用してAPI呼び出しを実行

Web サーバーフローの利点は、クライアントシークレットをサーバー側で安全に保管できる点です。また、リフレッシュトークンも同時に発行されるため、長期間のアクセスが可能になります。

JWT ベアラーフロー

OAuth 2.0 JWT ベアラーフローは、ユーザーの介在を必要としないサーバー間連携において非常に有効な認証方式です。このフローでは、クライアントがJSON Web Token（JWT）をSalesforce OAuthトークンエンドポイントにPOSTし、アクセストークンを取得します。

JWT ベアラーフローの特徴は以下の通りです。

ユーザー操作が不要で完全自動化が可能
パスワードを直接扱わないため高セキュリティ
デジタル署名による厳格な認証
バッチ処理やスケジュール実行に最適

実装には証明書の作成と接続アプリケーションへの設定が必要ですが、一度設定すれば安全で堅牢なサーバー間連携を実現できます。

アクセストークンとリフレッシュトークンの仕組み

OAuth 2.0認証では、「アクセストークン」と「リフレッシュトークン」という2種類のトークンが重要な役割を果たします。これらのトークンを正しく理解し、適切に管理することがAPI連携の成功の鍵となります。

アクセストークンの役割と有効期限

アクセストークンは、Salesforce APIリソースへのアクセスを許可する一時的な認証情報です。このトークンをAPIリクエストのAuthorizationヘッダーに含めることで、Salesforceのデータにアクセスできます。

アクセストークンの主な特徴は以下の通りです。

有効期間は通常数分から数時間（デフォルト設定では2時間）
セッション設定で有効期限をカスタマイズ可能
期限切れのトークンを使用するとエラーが発生
Bearer認証方式でHTTPヘッダーに含めて使用

アクセストークンの有効期限は、Salesforceの[設定]→[セキュリティのコントロール]→[セッションの設定]から管理できます。

リフレッシュトークンによるトークン更新

リフレッシュトークンは、期限切れのアクセストークンを新しいトークンに更新するための長期的な認証情報です。OAuth 2.0更新トークンフローを使用することで、ユーザーに再度ログインを求めることなく、新しいアクセストークンを取得できます。

リフレッシュトークンの特徴は以下の通りです。

アクセストークンより長期間有効（ユーザーが明示的に無効化するまで有効）
Web サーバーフローでのみ発行される
トークンエンドポイントにPOSTして新しいアクセストークンを取得
セキュリティ上、サーバー側で安全に保管する必要がある

トークン更新の実装例

リフレッシュトークンを使用してアクセストークンを更新する際は、以下のようなHTTP POSTリクエストを送信します。

エンドポイント：https://login.salesforce.com/services/oauth2/token
grant_type：refresh_token
refresh_token：保存しているリフレッシュトークン
client_id：接続アプリケーションのコンシューマキー
client_secret：接続アプリケーションのコンシューマシークレット

レスポンスとして新しいアクセストークンが返されるため、これを使用してAPIアクセスを継続できます。なお、Salesforceの仕様として、ユーザーセッションが有効な間は同じアクセストークンが返されるという独特な動作をする点に注意が必要です。

REST APIとSOAP APIの認証方法の違い

SalesforceにはREST APIとSOAP APIという2つの主要なAPI形式が存在し、それぞれ認証方法に違いがあります。用途に応じて適切なAPIを選択することが重要です。

REST APIの認証

REST APIは、軽量で柔軟性に優れたAPIで、モバイルアプリケーションやWeb 2.0プロジェクトなどの最新のアプリケーション開発に適しています。認証方式としては以下をサポートしています。

OAuth 2.0（推奨）：様々な認証フローに対応
セッションID：SOAPログイン後のセッションIDを利用
JSON形式またはXML形式でデータをやり取り
HTTPメソッド（GET、POST、PUT、DELETEなど）を使用

SOAP APIの認証

SOAP APIは、XML形式でリクエストとレスポンスをやり取りするAPIで、より複雑な処理や厳格なセキュリティ要件が求められる場合に適しています。認証方式としては以下をサポートしています。

login()メソッド：ユーザー名とパスワードで認証（Summer ’27で廃止予定）
OAuth 2.0：セキュアな認証方式（今後はこちらが推奨）
セッションID：認証後のセッション管理
WSDLファイルによる厳密な型定義

重要な注意点として、SOAP API login()メソッドは2027年のSummer ’27リリースで廃止される予定です。そのため、新規開発ではOAuth 2.0を使用することが強く推奨されています。

比較項目	REST API	SOAP API
データ形式	JSON / XML	XML
推奨認証	OAuth 2.0	OAuth 2.0（login()は廃止予定）
適用シーン	モバイル、Web2.0、軽量処理	複雑な処理、厳格なセキュリティ
柔軟性	高い	標準

API認証実装時のセキュリティベストプラクティス

Salesforce APIの認証を実装する際は、セキュリティを最優先に考慮する必要があります。以下のベストプラクティスに従うことで、安全なAPI連携を実現できます。

トークンの安全な管理

アクセストークンとリフレッシュトークンは暗号化して保存する
トークンをクライアント側（ブラウザやモバイルアプリ）に露出させない
環境変数や専用のシークレット管理サービスを使用する
定期的にトークンをローテーション（更新）する

接続アプリケーションの設定

必要最小限のOAuthスコープのみを付与する
IPアドレス制限を設定して不正アクセスを防ぐ
組織にインストールして正式に承認された接続アプリのみを使用する
定期的に未使用の接続アプリケーションを確認・削除する

通信のセキュリティ

必ずHTTPS（TLS/SSL）を使用してAPIリクエストを送信する
証明書の検証を必ず実施する
PKCE（Proof Key for Code Exchange）を使用してセキュリティを強化する
ユーザーエージェントフローなど非推奨のフローは使用しない

監視とログ管理

API使用状況を定期的に監視する
異常なアクセスパターンを検知する仕組みを構築する
エラーログを適切に記録し、セキュリティインシデントに備える
Salesforceの[設定]→[私の個人設定]→[リモートアクセス]で接続状況を確認する

認証エラーのトラブルシューティング

API認証の実装時には、様々なエラーに遭遇することがあります。よくあるエラーとその対処方法を理解しておくことで、スムーズな開発が可能になります。

よくある認証エラーと対処法

エラー	原因	対処法
invalid_grant	認証コードやトークンが無効	新しい認証コードを取得し直す
invalid_client	クライアントIDまたはシークレットが間違っている	接続アプリケーションの設定を確認
unauthorized_client	接続アプリが組織にインストールされていない	接続アプリケーションをインストール
redirect_uri_mismatch	コールバックURLが一致しない	接続アプリのコールバックURL設定を確認