2020.08.11
Salesforceで適切なOAuthフローを選べるようするには
ポスト
はじめに
OAuthのことを勉強してみたけど、なんかいっぱいあって結局よくわからなかった・・・
こんな人が自分以外にもいると信じて今この記事を書いています。
今回の記事は、いくつか種類があるOAuthフローの中でどれを利用すればいいかをテーマにしています。
そのため、OAuthについて学び始めた方が対象です。
また、Identity and Access Manegementデザイナーの試験では、 OAuthにまつわる内容の比重も高いので、資格取得を考えている方にもオススメします。
OAuthをよく知らない方もご安心ください、テラスカイの過去のブログ記事から学び始めることができます。
（テラスカイが誇るTAが書いた記事です！ぜひ読んでみてください！）
SalesforceだけでSSO（OAuth2.0）を試す：事前準備編
SalesforceだけでSSO（OAuth2.0）を試す：実装編
※本記事ではOAuthはOAuth2.0を指します。
SalesforceのOAuth事情
さっそくですが、Salesforceでの主要なOAuthフローを挙げてみます。
- Web サーバフロー（認可コードフロー）
- ユーザエージェントフロー（インプリジットフロー）
- JWT ベアラーフロー
- SAML アサーションフロー
- ユーザ名パスワードフロー
※Salesforceは、クライアントクレデンシャルズフローはサポートしていません。
ざっくりとした説明ですが、OAuthでは大体何かとアクセストークンを交換します。
この何かが各フローによって異なってきます。
では、これだけの種類があるなら、どれを使えばいいのでしょうか・・・？
私は何も知らなかった頃、一番簡単にできそうという理由で、ユーザ名/パスワードをアクセストークンと交換していました。
（今では理解していますが、これは極力やってはいけないことですね！）
そこで、各フローの選定について、いくつかポイントを挙げてみました。
消去法で考えていくとわかりやすいかなと個人的には考えています。
ポイント1：ユーザ名パスワードフローのことはもはや忘れてしまう
さっそく、一つなくなりましたね（笑）
ユーザの認証情報を送信することになるので、ユーザ名パスワードフローの利用は非推奨です。
すでにユーザの認証情報を保有してしまっているようなクライアント向けのフローですが、 可能であればすぐに認可コードフローへ置き換えることが推奨されています。
ポイント2：SalesforceをサービスプロバイダとしてSAMLでのSSOを設定しているかどうか
SAMLでのSSOを設定していれば、それに利用するSAMLアサーション（特別なXML）とアクセストークンを交換できます。
有効なアサーションであれば、誰でもアクセストークンを取得できるため、 アサーションの取り扱いには注意が必要になります。
ポイント3：ユーザがその場にいるかどうか
ユーザがその場にいないようなサーバ間の会話ではJWT ベアラーフローを使用します。
クライアントクレデンシャルズフローを利用するケースと同じです。
JWT ベアラーフローではJWT（特別なJSON文字列）とアクセストークンを交換します。
こちらもSAMLフローと同様にアサーションの取り扱いには気をつけましょう。
ポイント4：クライアントはユーザエージェント（ブラウザ）で実行されるアプリケーションかどうか
最後に、ユーザがその場にいる場合です。
クライアントがいわゆるWebアプリケーションの場合はWeb サーバフローを利用します。
Web サーバフローでは認可リクエストのレスポンスで付与される認可コードとアクセストークンを交換します。
交換はWebアプリケーションのバックエンドと認可サーバの会話になるため、
ブラウザにアクセストークンを知られない利点があります。
クライアントがJavaScriptアプリケーションのようなブラウザで実行されるものである場合は、ユーザエージェントフローを利用します。
このフローでは、認可リクエストのレスポンスでアクセストークンが付与されます。（何かとの交換はしない）
しかし、ブラウザからアクセストークンを隠せない点に注意が必要です。
このフローを検討する際に、併せてWeb サーバフローで置き換えられないかも検討しましょう。
さいごに
今回はSalesforceでサポートされている主要なOAuthのフローについて、 どのような場合にどのフローを選ぶとよいのかを簡単に説明してみました。
「『Salesforce OAuth』で検索しても、自分が求めるものが見つからない」という方にとって、少しでも助けになれば幸いです。
