> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-docs-event-stream-action-templates.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Proof Key for Code Exchange（PKCE）を使った認可コードフロー
> Proof Key for Code Exchange（PKCE）を使った認可コードフローの仕組みと、ネイティブやモバイルアプリで使用する根拠について説明します。
重要なコンセプト
* OAuth 2.0の付与タイプ、Proof Key for Code Exchange（PKCE）での認可コードフローの詳細を確認する
* ネイティブアプリやシングルページアプリなど、クライアントシークレットを保管できないアプリケーションにこの付与タイプを使用する
* Auth0 SDKを使った各種の実装方法を確認する
パブリッククライアント（例：ネイティブおよびシングルページアプリケーション）がアクセストークンを要求した際に、認可コードフローだけでは軽減しきれないセキュリティ上の懸念が提起されていました。これは以下の理由によるものです。
**ネイティブアプリ**
* アプリが クライアントシークレットを安全に保管できません。アプリを逆コンパイルすると、クライアントシークレットが暴露されます。クライアントシークレットはアプリにバインドされるものであり、すべてのユーザーとデバイスについても同様です。
* カスタムURLスキームを利用して、リダイレクト（「MyApp\://」など）をキャプチャできる可能性があるため、悪意のあるアプリケーションが 認可コード を 認可サーバーから取得できる可能性があります。
**シングルページアプリ**
* ブラウザーがソース全体を使用できるため、クライアントシークレットを安全に保管できません。
これらの状況を踏まえて、OAuth 2.0は認可コードフローにProof Key for Code Exchange（PKCE）を活用した1つのバージョンを提供しています（[OAuth 2.0 RFC 7636](https://tools.ietf.org/html/rfc7636)に定義）。
PKCEで拡張された認可コードフローではCode Verifierと呼ばれるシークレットを導入しました。このシークレットは、認可サーバーが検証したアプリケーションを呼び出すことによって作成されます。また、アプリを呼び出すと、Code VerifierからCode Challengeと呼ばれる変換値が作成され、この値がHTTPSで認可コードを取得するために送信されます。これで、悪意のある攻撃者が傍受できるのは認可コードだけとなり、Code Verifierがないため、それをトークンと交換できなくなります。
## 仕組み
PKCEで拡張された認可コードフローは[標準の認可コードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow)に基づいているため、手順は非常に似ています。
1. ユーザーがアプリケーション内で **［Login（ログイン）］** をクリックします
2. Auth0のSDKは暗号的にランダムな`code_verifier`を作成し、そこから`code_challenge`を生成します。
3. Auth0のSDKは`code_challenge`とともにユーザーをAuth0の認証サーバー（[`/authorize`エンドポイント](/docs/ja-jp/api/authentication#authorization-code-grant-pkce-)）にリダイレクトします。
4. Auth0の認可サーバーがユーザーをログインにリダイレクトして、認可を促します。
5. ユーザーが構成されたログインオプションの1つを使用して認証を行い、Auth0がアプリケーションに付与する許可をリストした同意ページが表示されることもあります。
6. Auth0の認可サーバーは`code_challenge`を保存し、1回限り使用できる認可`コード`でユーザーをアプリケーションにリダイレクトします。
7. Auth0のSDKは、この`コード`と`code_verifier`（手順2で作成）をAuth0の認可サーバー`（`[`/oauth/token`エンドポイント](/docs/ja-jp/api/authentication?http#authorization-code-flow-with-pkce44)）に送信します。
8. Auth0の認可サーバーは`code_challenge`と`code_verifier`を検証します。
9. Auth0の認可サーバーが、IDトークンとアクセストークン（リフレッシュトークンは任意）で応答します。
10. アプリケーションがアクセストークンを使ってAPIを呼び出し、ユーザーについての情報にアクセスします。
11. APIが要求データで応答します。
[Refresh Token Rotation（リフレッシュトークンのローテーション）](/docs/ja-jp/secure/tokens/refresh-tokens/refresh-token-rotation)を有効にすると、要求のたびに新しいリフレッシュトークンが生成され、アクセストークンと共に発行されます。リフレッシュトークンが交換されると、前のリフレッシュトークンは失効しますが、関係についての情報は認可サーバーによって維持されます。
## 実装方法
PKCEで認可コードフローを最も簡単に実装するには、「[ネイティブクイックスタート](/docs/ja-jp/quickstart/native)」または「[シングルページクイックスタート](/docs/ja-jp/quickstart/spa)」に従うことです。
アプリケーションタイプによっては、モバイルやシングルページアプリのSDKを使用することもできます。
**モバイル**
* [Auth0 Swift SDK](/docs/ja-jp/libraries/auth0-swift)
* [Auth0 Android SDK](/docs/ja-jp/libraries/auth0-android)
**シングルページアプリ**
* [Auth0 Single-Page App SDK](/docs/ja-jp/libraries/auth0-single-page-app-sdk)
* [Auth0 React SDK](/docs/ja-jp/libraries/auth0-react)
近年、ブラウザーのユーザープライバシー制御機能が発達し、サードパーティクッキーがブロックされることでユーザーエクスペリエンスに悪影響を与えています。そのため、ブラウザーベースのフローは、[リフレッシュトークンのローテーション](/docs/ja-jp/secure/tokens/refresh-tokens/refresh-token-rotation)を使用しなければなりません。これにより、SPAで安全にリフレッシュトークンが使用できる一方で、ブラウザーにあるITPなどのプライバシー保護技術にUXを阻害されることなく、エンドユーザーがリソースにシームレスにアクセスできます。
APIエンドポイントの使用方法に関するチュートリアルに従って、[PKCEによる認可コードフローを使用したログイン追加](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce/add-login-using-the-authorization-code-flow-with-pkce)、[PKCEによる認可コードフローを使用したAPI呼び出し](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce/call-your-api-using-the-authorization-code-flow-with-pkce)が可能です。
## もっと詳しく
* [Auth0ルール](/docs/ja-jp/customize/rules)
* [Auth0のフック](/docs/ja-jp/customize/hooks)
* [トークン](/docs/ja-jp/secure/tokens)
* [トークンのベストプラクティス](/docs/ja-jp/secure/tokens/token-best-practices)
* [どちらのOAuth 2.0フローを使用するべきですか？](/docs/ja-jp/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use)