Proof Key for Code Exchange (PKCE) を使用する認可コードフロー

概要

主なポイント

OAuth 2.0 のグラントタイプである、Proof Key for Code Exchange (PKCE) を使用する認可コードフローについて説明します。
ネイティブアプリやシングルページアプリなど、クライアントシークレットを保存できないアプリケーションでは、このグラントタイプを使用します。
Auth0 SDK を使用したさまざまな実装方法を確認します。

(例: ネイティブアプリケーションやシングルページアプリケーション) がを要求する場合、認可コードフローだけでは軽減できない追加のセキュリティ上の懸念が生じます。その理由は次のとおりです。 ネイティブアプリ

を安全に保存できません。アプリを逆コンパイルすると、アプリに紐づき、すべてのユーザーとデバイスで共通のが明らかになります。
認可コードの傍受攻撃や注入攻撃に対して脆弱です。クライアントシークレットがなければ、認可コードを傍受した攻撃者はそれをトークンに交換できます。
リダイレクトを受け取るためにカスタム URL スキーム (例: MyApp://) を使用することがあり、その結果、悪意のあるアプリケーションがをあなたのから受け取ってしまう可能性があります。このリスクがあるため、Auth0 はカスタム URI スキームの使用を強く非推奨としています。詳しくは、アプリケーションのなりすましを防ぐための対策を参照してください。

シングルページアプリ

ソースコード全体がブラウザから参照できるため、クライアントシークレットを安全に保存できません。

このような状況に対応するため、では、Proof Key for Code Exchange (PKCE) を使用する認可コードフローのバージョンが提供されています (OAuth 2.0 RFC 7636 で定義) 。 PKCE で強化された認可コードフローでは、呼び出し元のアプリケーションが作成し、で検証できるシークレットが導入されます。このシークレットは Code Verifier と呼ばれます。さらに、呼び出し元のアプリは Code Verifier を変換した値である Code Challenge を作成し、この値を HTTPS 経由で送信して Authorization Code を取得します。これにより、悪意のある攻撃者が傍受できるのは Authorization Code のみとなり、Code Verifier がなければそれをトークンに交換できません。

仕組み

PKCE で強化された認可コードフローは、標準の認可コードフローをベースにしているため、手順はほぼ同じです。

ユーザーがアプリケーション内の ログイン をクリックします。
Auth0 の SDK は、暗号学的にランダムな code_verifier を生成し、それをもとに code_challenge を生成します。
Auth0 の SDK は、code_challenge とともにユーザーを Auth0 の認可サーバー (/authorize エンドポイント) にリダイレクトします。
Auth0 の認可サーバーは、ユーザーをログインと認可のプロンプトにリダイレクトします。
ユーザーは設定されているログインオプションのいずれかを使って認証し、Auth0 がアプリケーションに付与する権限が一覧表示された同意ページが表示されることがあります。
Auth0 の認可サーバーは code_challenge を保存し、1 回限り使用可能な認可 code とともにユーザーをアプリケーションへリダイレクトします。
Auth0 の SDK は、この code と code_verifier (手順 2 で生成) を Auth0 の認可サーバー (/oauth/token エンドポイント) に送信します。
Auth0 の認可サーバーは code_challenge と code_verifier を検証します。
Auth0 の認可サーバーは、IDトークンとアクセストークン (必要に応じてリフレッシュトークンも) を返します。
アプリケーションはアクセストークンを使用して API を呼び出し、ユーザーに関する情報にアクセスできます。
API は要求されたデータを返します。

Refresh Token Rotation を有効にしている場合は、リクエストのたびに新しいリフレッシュトークンが生成され、アクセストークンとともに発行されます。リフレッシュトークンが交換されると、直前のリフレッシュトークンは無効になりますが、その関連情報は認可サーバーに保持されます。

実装方法

PKCE を使用する認可コードフローを実装する最も簡単な方法は、Native Quickstarts または Single-Page Quickstarts に従うことです。アプリケーションの種類に応じて、モバイルアプリ向けまたはシングルページアプリ向けの SDK を使用することもできます。 モバイル

シングルページ

ブラウザーにおけるユーザープライバシー制御の最近の進展により、サードパーティ Cookie へのアクセスが制限され、ユーザー体験に悪影響が生じています。そのため、ブラウザーベースのフローでは Refresh Token Rotation を使用する必要があります。これにより、SPA でリフレッシュトークンを安全に使用できるだけでなく、ITP などのブラウザープライバシー技術による UX の中断を避けながら、エンドユーザーがリソースにシームレスにアクセスできるようになります。

チュートリアルに従って API エンドポイントを使用し、Add Login Using the 認可コードフロー with PKCE または Call Your API Using the 認可コードフロー with PKCE を実装できます。

概要

​仕組み

​実装方法

​詳細情報

仕組み

実装方法

詳細情報