Overview
重要なコンセプト
- OAuth 2.0の付与タイプ、Proof Key for Code Exchange（PKCE）での認可コードフローの詳細を確認する
- ネイティブアプリやシングルページアプリなど、クライアントシークレットを保管できないアプリケーションにこの付与タイプを使用する
- Auth0 SDKを使った各種の実装方法を確認する
- アプリが を安全に保管できません。アプリを逆コンパイルすると、クライアントシークレットが暴露されます。クライアントシークレットはアプリにバインドされるものであり、すべてのユーザーとデバイスについても同様です。
- カスタムURLスキームを利用して、リダイレクト（「MyApp://」など）をキャプチャできる可能性があるため、悪意のあるアプリケーションが を から取得できる可能性があります。
- ブラウザーがソース全体を使用できるため、クライアントシークレットを安全に保管できません。
仕組み
PKCEで拡張された認可コードフローは標準の認可コードフローに基づいているため、手順は非常に似ています。
- ユーザーがアプリケーション内で ［Login（ログイン）］ をクリックします
- Auth0のSDKは暗号的にランダムな
code_verifierを作成し、そこからcode_challengeを生成します。 - Auth0のSDKは
code_challengeとともにユーザーをAuth0の認証サーバー（/authorizeエンドポイント）にリダイレクトします。 - Auth0の認可サーバーがユーザーをログインにリダイレクトして、認可を促します。
- ユーザーが構成されたログインオプションの1つを使用して認証を行い、Auth0がアプリケーションに付与する許可をリストした同意ページが表示されることもあります。
- Auth0の認可サーバーは
code_challengeを保存し、1回限り使用できる認可コードでユーザーをアプリケーションにリダイレクトします。 - Auth0のSDKは、この
コードとcode_verifier（手順2で作成）をAuth0の認可サーバー（/oauth/tokenエンドポイント）に送信します。 - Auth0の認可サーバーは
code_challengeとcode_verifierを検証します。 - Auth0の認可サーバーが、IDトークンとアクセストークン（リフレッシュトークンは任意）で応答します。
- アプリケーションがアクセストークンを使ってAPIを呼び出し、ユーザーについての情報にアクセスします。
- APIが要求データで応答します。
Refresh Token Rotation（リフレッシュトークンのローテーション）を有効にすると、要求のたびに新しいリフレッシュトークンが生成され、アクセストークンと共に発行されます。リフレッシュトークンが交換されると、前のリフレッシュトークンは失効しますが、関係についての情報は認可サーバーによって維持されます。
実装方法
PKCEで認可コードフローを最も簡単に実装するには、「ネイティブクイックスタート」または「シングルページクイックスタート」に従うことです。 アプリケーションタイプによっては、モバイルやシングルページアプリのSDKを使用することもできます。 モバイル シングルページアプリ近年、ブラウザーのユーザープライバシー制御機能が発達し、サードパーティクッキーがブロックされることでユーザーエクスペリエンスに悪影響を与えています。そのため、ブラウザーベースのフローは、リフレッシュトークンのローテーションを使用しなければなりません。これにより、SPAで安全にリフレッシュトークンが使用できる一方で、ブラウザーにあるITPなどのプライバシー保護技術にUXを阻害されることなく、エンドユーザーがリソースにシームレスにアクセスできます。