> ## Documentation Index
> Fetch the complete documentation index at: https://developers.authlete.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 最適な OAuth 2.0 フローの選び方

> OAuth 2.0フローの中から最適な選択方法についての記事。

<Note>
  This page is for **Authlete 2.x**. For current (3.0) documentation, see [this page](/ja/guides/getting-started-with-implementation/how-to-choose-the-best-oauth-2-0-flow).
</Note>

# 最適な OAuth 2.0 フローの選び方

##  要約

基本的に、認可コードフロー（＋ PKCE）の利用をご検討ください。どうしても認可コードフローが使えない場合、各種フローの性質をよく理解した上で、他の方法をご検討ください。

## 詳細

RFC6749 にて定義されているフロー（認可タイプ）は、下記の5種になります。 各フロー毎に、認可エンドポイントまたはトークンエンドポイントからクライアントアプリに対して発行されるものが異なります 。

| **フロー**                 | 認可エンドポイント | **トークンエンドポイント**     |
| ----------------------- | --------- | ------------------- |
| 認可コード                   | 認可コード     | アクセストークン、リフレッシュトークン |
| インプリシット                 | アクセストークン  | -                   |
| リソースオーナー・パスワード・クレデンシャルズ | -         | アクセストークン、リフレッシュトークン |
| クライアント・クレデンシャルズ         | -         | アクセストークン            |
| リフレッシュトークン              | -         | アクセストークン、リフレッシュトークン |

### 認可コードフロー

認可エンドポイントから短命の認可コードを発行し、トークンエンドポイントにて発行した認可コードと引き換えでアクセストークンを発行するフローです。OAuth 2.0 の基本のフローとなります。\
スマホアプリのようにクライアントシークレット等の機密情報を安全に保持できないクライアント（＝パブリッククライアント）から直接トークンを要求する場合、上記の認可コードフローに加え、PKCE（Proof Key for Code Exchange）を使うことが必要となります。

### インプリシット

認可エンドポイントから直接アクセストークンを発行するフローです。上記の認可コードフローと異なり、リフレッシュトークンは発行されません。シングルページアプリケーション（SPA）からトークンを要求する場合などを想定して作られた仕様ですが、現在、SPA の場合も 認可コードフロー＋PKCE が推奨されております。

### リソースオーナー・パスワード・クレデンシャルズ

リソースオーナー（＝エンドユーザー）の ID と PW を受け取り、アクセストークンを発行するフローです。クライアントアプリにリソースオーナーの ID/PW がわたってしまうため、基本的には使いません。OAuth 2.0 導入時のシステム移行期等でのみ利用されるフローです。

### クライアント・クレデンシャルズ

クライアントの認証のみで、アクセストークンを発行するフローになります。クライアントとリソースオーナーが同一の場合に使われるフローです。

### リフレッシュトークン

リフレッシュトークンを提示し、アクセストークンの再発行を受けるフローになります。