Contents
前提知識としての「認証」と「認可」の違い
■認証（Authentication）とは何か？
→利用者が「誰であるか（identity）」を確認すること（＝Identity Management）
例１：ホテルのチェックイン
例２：ユーザ名とパスワードによるログイン
■認可（Authorization）とは何か？
→リソースへのアクセス権限を与えること（＝Access Management）
例：チェックインした顧客に対する、部屋の鍵の付与
例：ログインしたユーザに対する、動画の閲覧権限の付与
| 認証（Authentication） | 認可（Authorization） | |
| 定義 | 利用者が「誰であるか（identity）」を確認すること | リソースへのアクセス権限を与えること |
| 別名 | Identity Management | Access Management |
| 例１ | ホテルのチェックイン | 部屋の鍵の付与 |
| 例２ | ユーザ名とパスワードによるログイン | 動画の閲覧権限の付与 |
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. | Name | Description |
| 1 | Web サーバフロー | （client_secretをセキュアに保存できる）外部WebアプリケーションをSalesforce APIと統合する場合に利用 |
| 2 | ユーザエージェントフロー | client_secretをセキュアに保存できない外部WebアプリケーションをSalesforceと統合する場合に利用 |
| 3 | ユーザ名パスワードフロー | ユーザーが積極的に認証を行うことなく動作するアプリケーションで利用される |
| 4 | SAML ベアラーアサーションフロー | 電子署名付きのSAML2.0アサーションがOAuthアクセストークンの取得に利用される |
| 5 | JWT ベアラーフロー | JWT（JSON Web Token）がOAuthアクセストークンの取得に利用される |
| 6 | SAML アサーションフロー | 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 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」
■ 分かりやすい教材（テキスト・ブログ）
「yhayashi30.org – SAML認証フロー整理」
「yhayashi30.org – SalesforceにおけるOAuth2.0/OpenID Connect」
■OAuth一般（問い：OAuthは認可のプロトコルであるにもかかわらず、OAuth認証が巷に溢れているのはなぜなのか？）
「【連載】世界一わかりみの深いOAuth入門 〜 その1:OAuthってなに？ 〜」
「世界一わかりみの深いOAuth入門 〜認可の基礎から応用まで〜」（※↑の動画ver.）