SalesforceにおけるOAuth認証について

前提知識としての「認証」と「認可」の違い

■認証(Authentication)とは何か?

→利用者が「誰であるか(identity)」を確認すること(=Identity Management)

例1:ホテルのチェックイン

例2:ユーザ名とパスワードによるログイン

■認可(Authorization)とは何か?

→リソースへのアクセス権限を与えること(=Access Management)

例:チェックインした顧客に対する、部屋の鍵の付与

例:ログインしたユーザに対する、動画の閲覧権限の付与

認証(Authentication)認可(Authorization)
定義利用者が「誰であるか(identity)」を確認すること リソースへのアクセス権限を与えること
別名Identity ManagementAccess Management
例1ホテルのチェックイン部屋の鍵の付与
例2ユーザ名とパスワードによるログイン 動画の閲覧権限の付与

OAuthとは何か?

■認可のプロトコルとしてのOAuth

OAuthとは「認可(Authorization)」のプロトコルです。

OAuthにより、ユーザはリソースへのアクセス権限を別のシステムへと権限移譲することが可能です。

例えば、Salesforceから別システムAに対してOAuthを通して「ユーザの作成権限」を認可した場合、APIなどを経由して別システムAからSalesforceのユーザを作成することが可能となります。この際、別システムにはユーザのID・パスワードを通知する必要がありません。

■抽象化されたOAuthの流れ

OAuthによる認識・認可のざっくりした流れは以下の通り。

例えば、外部システムからSalesforceのAPIを叩いて情報を取得する場合、外部システム(クライアント)がユーザ(リソースオーナー)にログインでの認証・確認画面での認可を求め、OKが出た場合はSalesforceのIdPに認可コードを送信してアクセストークンを取得し、そのアクセストークンを利用してSalesforceのAPIクライアントを叩くという流れになります。

OAuthにおける接続アプリケーション(Connected App)

SalesforceがIdP(≒リソースサーバー)となるOAuth認証においては、事前にクライアントアプリケーション側に「Client ID」や「Client Secret」の情報を共有しておく必要がありますが、それらは「接続アプリケーション」で生成することが可能です。

コールバックURLやスコープ(=OAuth範囲)についてもここで定義します。

SalesforceのOAuth認証フロー

以下の通り、認証の方法に応じて様々な種類があります。

この記事では「Webサーバーフロー」・「ユーザエージェントフロー」・「(トークン失効時の)更新トークンプロセス」・「JWTベアラーフロー」について、それぞれ個別にフローを図示化してみたいと思います。

No.NameDescription
1Web サーバフロー(client_secretをセキュアに保存できる)外部WebアプリケーションをSalesforce APIと統合する場合に利用
2ユーザエージェントフロー client_secretをセキュアに保存できない外部WebアプリケーションをSalesforceと統合する場合に利用
3ユーザ名パスワードフローユーザーが積極的に認証を行うことなく動作するアプリケーションで利用される
4SAML ベアラーアサーションフロー電子署名付きのSAML2.0アサーションがOAuthアクセストークンの取得に利用される
5JWT ベアラーフローJWT(JSON Web Token)がOAuthアクセストークンの取得に利用される
6SAML アサーションフローSAMLアサーションを使用して、Webシングルサインオン (Web SSO) 用にSalesforceを統合する場合と同じ方法で APIを統合できる。
※これは接続アプリケーションなしで利用できる
7更新トークンフローOAuth 2.0 Web サーバフローまたは OAuth 2.0 ユーザエージェントフローによって発行されたアクセストークンを更新する
8デバイスフローIoT デバイスなどをSalesforceに統合する際に、より高度な入力機能を持つデバイス (デスクトップ、モバイルデバイスなど)を認証に利用する
9アセットトークンフローIoTデバイスをSalesforce APIに統合する場合に利用

OAuth 2.0の認可コードフロー

さきほど、以下のような「抽象化されたOAuthの流れ」を確認しましたが、厳密に見た場合、「リソースオーナー(ユーザ)」から「認可コード」がレスポンスとして返ってくるというのは勿論あり得ません。

OAuth 2.0の一般的な認可コードフローの流れをここで示しておきたいと思います。

Webサーバフロー

↓必須パラメータ記載Ver.

ユーザエージェントフロー

↓必須パラメータ記載Ver.

更新トークンプロセス

↓必須パラメータ記載Ver.

JWTベアラーフロー

OAuth関連リンク集

■基本教材

「Identity実装ガイド」

「シングルサインオン実装ガイド」

「ユーザの識別およびアクセス権の管理」

■ 分かりやすい教材(動画)

「Identity and Access Management for Beginners」

OAuth With Salesforce Demystified(1)」

「OAuth with Salesforce – Demystified」(※↑のupdate ver.)

「簡単な設定のみでシングルサインオンを実現できる『Salesforce 認証』」

「Identity and Access Management in Salesforce – Apex Hours」

■ 分かりやすい教材(テキスト・ブログ)

「Salesforceのシングルサインオンをまとめてみる」

「yhayashi30.org – SAML認証フロー整理」

「yhayashi30.org – SalesforceにおけるOAuth2.0/OpenID Connect」

■OAuth一般(問い:OAuthは認可のプロトコルであるにもかかわらず、OAuth認証が巷に溢れているのはなぜなのか?

「OAuth認証とは何か?なぜダメなのか – 2020冬」

「OAuthと認証と認可とOpenIDConnect」

「【連載】世界一わかりみの深いOAuth入門 〜 その1:OAuthってなに? 〜」

「世界一わかりみの深いOAuth入門 〜認可の基礎から応用まで〜」(※↑の動画ver.)

『【電子版】OAuth、OAuth認証、OpenID Connectの違いを整理して理解できる本』

Salesforce

Posted by regardie