認証
ユーザー管理
カスタマイズ
プラットフォーム概要
主な概念
- OAuth 2.0 のグラントタイプである、PKCE を使用した Authorization Code フローについて学びます。
- Native アプリやシングルページアプリのように、Client Secret を保存できないアプリケーションには、このグラントタイプを使用します。
- Auth0 SDK を使用したさまざまな実装方法を確認します。
- を安全に保存できません。アプリを逆コンパイルすると、アプリにひも付けられていて、すべてのユーザーとデバイスで共通の が明らかになります。
- 認可コードの傍受攻撃や注入攻撃に対して脆弱です。Client Secret がなければ、認可コードを傍受した攻撃者はそれをトークンと交換できます。
- リダイレクトを受け取るためにカスタム URL スキーム (例: MyApp://) を使用することがあり、その場合、悪意のあるアプリケーションが使用中のをから受け取れてしまう可能性があります。このリスクがあるため、Auth0 はカスタム URI スキームの使用を強く非推奨としています。詳しくは、アプリケーションのなりすまし対策 を参照してください。
- ソースコード全体をブラウザから参照できるため、Client Secret を安全に保存できません。
仕組み
- ユーザーがアプリケーション内で ログイン をクリックします。
- 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のローテーション が有効になっている場合、リクエストのたびに新しいリフレッシュトークンが生成され、アクセストークンとあわせて発行されます。リフレッシュトークンが交換されると、以前のリフレッシュトークンは無効化されますが、その関係に関する情報は認可サーバーに保持されます。
実装方法
近年、ブラウザのユーザープライバシー制御の強化により、サードパーティ Cookie へのアクセスが妨げられ、ユーザー体験に悪影響が生じています。そのため、ブラウザベースのフローでは Refresh Tokenのローテーション を使用する必要があります。これにより、SPA でリフレッシュトークンを安全に使用できるようになり、ITP のようなブラウザのプライバシー技術による UX の中断を回避しつつ、エンドユーザーはリソースにシームレスにアクセスできます。