前篇ではOAuth2の基本概念と動作を見てきました。今回はDjango OAuth Toolkit（DOT）を活用してOAuth2認証サーバーを構成する方法について主に取り上げます。
1. Django OAuth Toolkitのインストール
OAuth2サーバーを実装するには、まずDjango OAuth Toolkit（DOT）をインストールする必要があります。簡単なコマンドでインストールできます：
bash
pip install django-oauth-toolkit
インストールが完了したら、INSTALLED_APPSにoauth2_providerを追加し、マイグレーションを実行します。
マイグレーション後、Django AdminページでDOTが提供する追加メニューを確認できます。
2. Adminで新たに追加されたメニューの確認
DOTをインストールすると、Django Adminに以下の5つのメニューが追加されます：
1) アクセストークン
- 発行されたアクセストークンを管理します。
- 各トークンの有効期限、関連クライアントアプリケーション、ユーザー情報を確認できます。
- アクセストークンは認証されたクライアントが保護されたリソースにアクセスするために使用されるキーです。
2) リフレッシュトークン
- リフレッシュトークンを管理します。
- アクセストークンが期限切れになったときに、新しいアクセストークンを発行するために使用されます。
- これによりユーザーは再認証なしで継続的な作業を行うことができます。
3) アプリケーション
- OAuth2クライアントアプリケーションを登録し管理します。
- アプリケーションは認証サーバーと通信するために登録する必要があり、さまざまな設定フィールドが提供されます。
4) グラント
- 認可コード（Authorization Code）を管理します。
- 認可コードはクライアントアプリケーションがアクセストークンを要求するために必要な一時的なキーです。
5) IDトークン
- 発行されたIDトークンを管理します。
- IDトークンはOAuth2とOpenID Connect（OIDC）を組み合わせる際に使用され、ユーザー認証情報およびクライアントアプリケーション情報が含まれます。
- クライアントがOpenID Connectプロトコルを活用してユーザー情報を取得する際に使用されます。
3. アプリケーションメニューの詳細説明
OAuth2サーバーの核心はクライアントアプリケーションの登録です。Applicationメニューでは以下のフィールドを設定できます：
1) 名前
- アプリケーションの名前です。
- 管理者が容易に識別できるように明確に記述してください。
2) クライアントID
- アプリケーションのユニークな識別子です。
- OAuth2サーバーがクライアントを識別するために使用され、自動的に生成されます。
3) クライアントシークレット
- クライアント認証時に使用する秘密キーです。
- サーバーベースのアプリケーション（Confidential）のみに適用され、安全に保管する必要があります。
4) クライアントタイプ
- クライアントアプリケーションのタイプです。
- Confidential: 秘密キーを安全に保存できるサーバーベースのアプリケーション。
- Public: 秘密キーを保存できないモバイルアプリまたはSPA（シングルページアプリケーション）。
5) 認可グラントタイプ
- クライアントアプリケーションが使用する認証方式です。主なオプション：
- Authorization Code: 最も一般的でセキュリティの高い方式。
- Password: ユーザーのID/パスワードを直接入力して認証。
- Client Credentials: サーバー間通信に適している。
6) リダイレクトURI
- 認証成功後にAuthorization CodeまたはAccess Tokenが渡されるクライアントアプリケーションのURLです。
- 重要: クライアント側の設定と必ず一致する必要があります。
- URLが不一致の場合、OAuth2サーバーは認可コードまたはトークンを渡しません。
- セキュリティのためにHTTPSを使用することが推奨されます。
7) アルゴリズム
- トークン暗号化に使用するアルゴリズムを指定します。
- デフォルトは
RS256で、これはRSAベースの署名アルゴリズムです。 - RS256: 非対称暗号化を使用し、公開キーで署名を検証します。
- 必要に応じて他のアルゴリズムに変更可能です。
8) 認可バイパス
- Trueに設定すると、ユーザーの承認なしにクライアントアプリケーションに自動的に権限が付与されます。
- 内部システムや信頼されたアプリケーションで有用です。
4. まとめと次のステップ
今回はDjango OAuth Toolkit（DOT）のAdminメニューと特にApplicationフィールドを中心にOAuth2サーバーを構成する方法を見てきました。これによりクライアントアプリケーション登録プロセスと各フィールドの役割を理解できました。
次回の記事では、今回の投稿で言及したClient Typeについてさらに深く考察します。特に、ConfidentialとPublicタイプを比較し、これら二つのタイプがOAuth2でどのように使用されるか詳しく説明する予定です。また、次の内容を扱う予定です：
- Client TypeとPKCEの関係：PKCE（Proof Key for Code Exchange）がなぜPublicクライアントで重要なのか。
- Client Secretの役割：Confidentialクライアントで秘密キーがどのように使用されるのか。
- Authorization Code方式のフローとPKCE：OAuth2で最も標準的に使用されるGrant Typeの核心に迫ります。
Authorization Code方式のフローを明確に理解するためには、PKCEとClient Typeの相互作用を正しく把握することが不可欠です。
次回の投稿でこのテーマについて深掘りしていきます。
Add a New Comment