OAuth 2.0 の学習をしていると、更新トークンフローについて次のような問題に出会うことがあります。
更新トークンフローを適用できる OAuth フローはどれか？
Salesforce の文脈では、代表的には次のように整理されます。
| フロー | 更新トークンフローを使えるか |
|---|---|
| Webサーバーフロー | 使える |
| ユーザーエージェントフロー | 使える |
| JWTベアラートークンフロー | 使えない |
| ユーザー名・パスワードフロー | 使えない |
最初は少しわかりにくいですが、判断基準はシンプルです。
そのフローで
refresh_tokenが発行されるか？
更新トークンフローは、すでに持っている refresh_token を使って、新しい access_token を取得するためのフローです。
そのため、そもそも refresh_token が発行されないフローでは、更新トークンフローは使えません。
更新トークンフローとは
更新トークンフローは、期限切れになった access_token を、refresh_token を使って再発行する仕組みです。
access_token は API を呼び出すためのトークンです。ただし、セキュリティ上の理由から有効期限は短めに設定されます。
一方で、毎回ユーザーにログインしてもらうと使い勝手が悪くなります。そこで使われるのが refresh_token です。
流れとしては、次のようになります。
- 初回認証で
access_tokenとrefresh_tokenを取得する -
access_tokenを使って API を呼び出す -
access_tokenが期限切れになる -
refresh_tokenを使って新しいaccess_tokenを取得する - 新しい
access_tokenで API 呼び出しを継続する
ここで重要なのは、更新トークンフローは「最初のログインに使うフロー」ではないという点です。
最初に別の OAuth フローで refresh_token を取得しておき、その後 access_token が期限切れになったタイミングで使います。
Webサーバーフローで使える理由
Webサーバーフローは、ユーザーがログインし、アプリケーションへのアクセスを許可する標準的な OAuth フローです。
Salesforce では、適切なスコープを指定することで、アプリケーションは access_token と一緒に refresh_token を取得できます。
そのため、アクセストークンが期限切れになった後も、次のように再発行できます。
refresh_token
-> 新しい access_token
つまり、Webサーバーフローは refresh_token を取得できるため、更新トークンフローの対象になります。
ユーザーエージェントフローで使える理由
ユーザーエージェントフローも、ユーザーのログインと認可を前提にしたフローです。
Salesforce の更新トークンフローは、Webサーバーフローまたはユーザーエージェントフローで発行されたアクセストークンを更新するものとして説明されています。
そのため、模擬問題や試験対策の文脈では、ユーザーエージェントフローも更新トークンフローの対象として扱います。
ただし、ユーザーエージェントフローはアクセストークンがブラウザやモバイルアプリ側に露出しやすい方式です。
現在の実装では、セキュリティ上の理由から Webサーバーフロー + PKCE を検討する場面が多くなっています。
JWTベアラートークンフローで使えない理由
JWTベアラートークンフローは、refresh_token でアクセストークンを更新するフローではありません。
このフローでは、クライアントが証明書で署名した JWT を作成し、それを Salesforce のトークンエンドポイントに送信します。
Salesforce は JWT の署名や内容を検証し、問題がなければ access_token を発行します。
つまり、アクセストークンを再取得する方法はこうです。
新しい署名付きJWTを作る
-> Salesforceに送る
-> access_token を取得する
refresh_token を使っているわけではありません。
そのため、JWTベアラートークンフローでは更新トークンフローを使えません。
ここでのポイントは、「アクセストークンを再取得できない」という意味ではないことです。
JWTベアラートークンフローでは、アクセストークンの再取得方法が refresh_token ではなく、署名付き JWT になっているだけです。
ユーザー名・パスワードフローで使えない理由
ユーザー名・パスワードフローは、クライアントがユーザー名とパスワードを直接送信して access_token を取得するフローです。
Salesforce のユーザー名・パスワードフローは、refresh_token をサポートしません。
そのため、アクセストークンを再取得したい場合は、再びユーザー名とパスワードを使ってトークンを取得する形になります。
refresh_token を使う
のではなく、
ユーザー名・パスワードを使う
という考え方です。
ただし、この方式はユーザーの認証情報をアプリケーション側で扱うため、セキュリティ上のリスクが高いです。
Salesforce でも、ユーザー名・パスワードフローは特別なシナリオ向けであり、現在は避けるべきフローとして扱われています。
まとめ
更新トークンフローが使えるかどうかは、次の基準で考えるとわかりやすいです。
refresh_tokenが発行されるフローかどうか
改めて整理すると、次のようになります。
| フロー | 更新トークンフロー | 理由 |
|---|---|---|
| Webサーバーフロー | 使える |
refresh_token を取得できる |
| ユーザーエージェントフロー | 使える | Salesforce の更新トークンフローの対象 |
| JWTベアラートークンフロー | 使えない | 署名付き JWT で access_token を取得する |
| ユーザー名・パスワードフロー | 使えない |
refresh_token をサポートしない |
試験対策としては、次のように覚えるとよさそうです。
更新トークンフローは、refresh_token が発行された後に使うフロー。
JWTベアラーは JWT で再取得する。
ユーザー名・パスワードは認証情報で再取得する。
「アクセストークンを再取得できるか」ではなく、「refresh_token を使って再取得する設計か」で見ると、整理しやすくなります。