2026.08.28 開発

Djangoのログイン機能：標準authの範囲とカスタムユーザー・allauth

Djangoでログイン機能を作るとき、最初に決めるのは何を書くかではなく、django.contrib.auth に何が入っているかの線引きです。ログイン、ログアウト、パスワード変更、パスワードリセットの一式はすでにビューとして存在し、URLを1行includeすれば動きます。一方で、ログイン試行の回数制限、ソーシャルログイン、多要素認証、メールアドレスの到達確認は標準に含まれません。この記事では、標準authで届く範囲、カスタムユーザーモデルを初回のmigrate前に切る理由、django-allauthへ広げる境界を、設定と修正箇所の粒度で整理しました。Django本体の位置づけとMVTの構造はDjangoとは？Python製Webフレームワークの特徴・MVT・始め方を入門解説で扱っています。

まとめ：標準authで足りる範囲とallauthへ移す境界

ログイン画面をゼロから書く理由は、ほとんどの案件にありません。Djangoはパスワードのハッシュ化、セッションの発行、リセット用トークンの生成まで持っており、自作するとその全部を自分で保守することになります。先に結論を並べます。

URLを1行includeすれば、ログインからパスワードリセットまで8本の画面が生えます。書くのはテンプレートだけです。
ログアウトはPOSTでのみ実行されます。aタグを踏ませる古い実装はDjango 5.0以降で動きません。
カスタムユーザーモデルは初回のmigrate前に決めます。後から替えると外部キーの張り替えが伴います。
標準に無いのは、ログイン試行の制限、ソーシャルログイン、多要素認証、メール到達の確認の4つです。
この4つが要件に入った時点でdjango-allauthに寄せます。自前で書き足す判断は割に合いません。

採用の線引きは最終章で条件付きで示します。まずは標準authが何をどこまで引き受けるのかを、URLとビューの単位で確かめていきます。

django.contrib.authが最初から用意するログイン機能の範囲

Djangoの認証は、ユーザーモデル、認証バックエンド、セッション、ビューの4層に分かれています。開発者が触るのは主にビューとテンプレートで、パスワードの検証とセッションの発行は下の層が引き受けます。

django.contrib.auth.urlsのincludeで生える8本のURL

ルーティングは1行で済みます。プロジェクトのurls.pyに次を足します。

from django.urls import include, path

urlpatterns = [
    path("accounts/", include("django.contrib.auth.urls")),
]

これで、ログイン、ログアウト、パスワード変更とその完了、パスワードリセットの申請と送信完了、リセットリンクの確認、リセット完了の8本がそろう構成です。URL名も login や password_reset として登録されるため、テンプレート側では名前で参照できます。ビューの実体はクラスベースで、LoginViewやPasswordResetViewとして提供されています。

用意されていないのはテンプレートです。LoginViewが探す既定のパスは registration/login.html で、テンプレートディレクトリにこの名前で置く必要があります。中身はフォームを1つ出すだけで足ります。ここを知らずにTemplateDoesNotExistに当たるのが、最初のつまずきどころです。

LogoutViewがPOST専用になった変更と修正が要る箇所

Django 5.0のリリースノートには、LogoutViewとlogout_then_login()でGETによるログアウトの対応を削除した旨が明記されています。公式ドキュメントの現在の記述も、POSTリクエストでユーザーをログアウトさせる、というものです。つまり、ヘッダーに置いたリンクでログアウトさせていた実装は、5.0へ上げた時点で機能しなくなります。

直し方は単純で、リンクを小さなフォームに置き換えます。CSRFトークンを含めるのを忘れないでください。古い記事のコードをそのまま写すと、この1点で詰まります。バージョンごとの差分はDjangoのEOLとサポート期限一覧【2026年8月】バージョン確認と移行判断で確認できます。

もう1つ、リダイレクト先の既定値にも注意が要ります。LOGIN_REDIRECT_URLの既定は accounts/profile/ で、これはDjangoが自動で用意する画面ではありません。設定しないままログインすると、存在しないURLへ飛ばされます。ログイン後の遷移先は必ず明示しておきます。

カスタムユーザーモデルを開始時に切る判断と継承先を決める要件基準

Djangoの標準Userモデルは、ユーザー名、メールアドレス、姓名、権限フラグを持ちます。要件がこの形に収まらないとき、たとえば社員番号で入る、メールアドレスだけで入る、部署や契約IDを持たせる、といった場合は自前のユーザーモデルに切り替えます。

AbstractUserとAbstractBaseUserの選び分けを要件から引く

継承元は2択です。標準Userと同じ列をそのまま使い、フィールドを足すだけならAbstractUserを継承します。差分が小さく、管理画面のUserAdminもほぼそのまま流用できます。

列の構成そのものを決め直すならAbstractBaseUserとPermissionsMixinを継承します。公式ドキュメントはAbstractBaseUserを、要件に準拠したカスタムユーザーモデルを組む最短経路と位置づけており、ハッシュ化されたパスワードとトークン方式のパスワードリセットはここが提供します。開発者が与えるのは、USERNAME_FIELD（識別に使う一意な列）、REQUIRED_FIELDS、そしてユーザー作成用のマネージャです。PermissionsMixinは、パーミッション機構に必要なフィールドとメソッドを付け足す抽象モデルです。

判断としては、ユーザー名を捨てるかどうかが分かれ目になります。ユーザー名を残すならAbstractUser、メールアドレスや社員番号を識別子にするならAbstractBaseUserです。迷ったらAbstractUserで始めても構いません。列の追加は後からでも安全に行えます。

途中でAUTH_USER_MODELを変えるときに発生する移行作業

公式ドキュメントは、プロジェクト開始時にカスタムユーザーモデルを設定するよう勧めています。理由は、Userテーブルが権限、セッション、管理画面の操作履歴、そしてアプリ側の外部キーから広く参照されるためです。

途中で切り替える場合は、モデルを新設し、AUTH_USER_MODELを差し替え、既存の外部キーをすべて新モデルへ向け直し、データを移し替える工程が必要です。既存テーブルが残っている状態でのマイグレーションは順序の制御が難しく、本番適用では前後の巻き戻し手順まで用意することが要件です。この操作の進め方はDjango migrateの実務｜makemigrationsからの流れと本番適用・巻き戻しで扱っています。初回のmigrateを走らせる前に決めておけば、この工程は丸ごと不要になります。

メールアドレスでのログインとパスワード検証を業務要件へ寄せる実装条件

日本の業務システムでは、ユーザー名ではなくメールアドレスでログインさせたい要件が多く出ます。標準のUserモデルはユーザー名が必須かつ一意なので、そのままでは実現できません。

USERNAME_FIELDをemailにするときに直す4か所

変更点は4つです。第一に、カスタムユーザーモデルでUSERNAME_FIELDにemailを指定し、email列にunique制約を付ける構成です。第二に、REQUIRED_FIELDSからemailを外します。この定数はcreatesuperuserがUSERNAME_FIELD以外に尋ねる項目の一覧なので、重複させると作成時にエラーになります。

第三に、ユーザー作成用のマネージャでcreate_userとcreate_superuserを書き換えます。標準のマネージャはusernameを引数に取るため、そのままでは動きません。第四に、管理画面のUserAdminを継承したクラスではlist_displayやfieldsetsからusernameを外す設定です。ここを忘れると管理画面が例外を投げます。管理画面側の設計はDjango管理画面の設計：admin標準の範囲とModelAdmin・権限の実装にまとめています。

既定のパスワード検証4種を社内規程の条件へ合わせる具体的な設定方法

AUTH_PASSWORD_VALIDATORSの既定は4種類です。ユーザー属性との類似を弾くUserAttributeSimilarityValidator、長さを見るMinimumLengthValidator、よく使われる語を弾くCommonPasswordValidator、数字だけを弾くNumericPasswordValidatorが並びます。MinimumLengthValidatorの既定は8文字で、min_lengthで変更できます。CommonPasswordValidatorは同梱された2万件の一覧と突き合わせる仕組みです。

社内規程が、英大文字・小文字・数字・記号のうち3種以上といった構成を求める場合、標準のバリデータには該当するものがありません。validate()とget_help_text()を持つクラスを1つ書いて、設定のリストに足します。規程を満たすためだけにフォーム側で正規表現を書くと、管理画面やパスワードリセット経由の変更に効かないので、バリデータとして登録するのが筋です。

ハッシュ方式をArgon2へ変える判断と既存パスワードの扱い

Djangoの既定ハッシュ方式はPBKDF2です。保存形式はアルゴリズム名、反復回数、ソルト、ハッシュ値をドル記号で連結した文字列で、どの方式で保存されたかが値の中に入っています。既定のPASSWORD_HASHERSにはArgon2、bcrypt、scryptも並んでおり、先頭に別の方式を置けば切り替わります。

切り替えても既存のパスワードは壊れません。ログイン時に古い方式で検証が通れば、新しい方式で保存し直されるためです。ただし追加ライブラリの導入と、ハッシュ計算のCPU負荷が増える点は見ておく必要があります。要件で方式が指定されていないなら、既定のまま進めて差し支えありません。

django-allauthでソーシャルログインとメール認証まで広げる

メールアドレスの到達確認、外部サービスのアカウントでの認証、多要素認証が要件に入ると、標準authの外側になります。ここを引き受けるのがdjango-allauthです。執筆時点の最新は65.19.1（2026年8月13日リリース）で、Python 3.10以上を要求します。

65系で設定名が変わったログイン方式とサインアップ項目の指定方法

allauthは設定名を刷新しており、日本語の解説記事に載っている旧名のままでは意図した動作になりません。現在の中心はACCOUNT_LOGIN_METHODSとACCOUNT_SIGNUP_FIELDSの2つです。

設定	既定値	意味
ACCOUNT_LOGIN_METHODS	username	ログインに使う識別子
ACCOUNT_SIGNUP_FIELDS	4項目（詳細は直後）	登録画面の入力項目
メール確認の設定名	optional	メール確認の扱い

表の4項目はusername・email・password1・password2で、メール確認の設定名はACCOUNT_EMAIL_VERIFICATIONです。メールアドレスでログインさせるなら、ACCOUNT_LOGIN_METHODSにemailを指定し、ACCOUNT_SIGNUP_FIELDSからusernameを外します。項目名の末尾にアスタリスクを付けたものが必須入力の指定です。電話番号や確認用の再入力欄も同じリストで扱えます。

メール確認の3モードを登録者の範囲と業務要件から選び分ける基準

ACCOUNT_EMAIL_VERIFICATIONは3値です。既定のoptionalは確認メールを送りますが、未確認でもログインを許します。mandatoryはメール確認を終えるまでログインさせません。noneは確認メール自体を送りません。

社外の利用者が自分で登録するサービスならmandatoryを選びます。到達しないアドレスで登録されると、パスワードリセットの導線ごと機能しなくなるためです。逆に、管理者がアカウントを作って配る社内システムならnoneで足ります。確認メールを送っても、受け取るのは管理者自身になるからです。optionalは、登録直後に使わせたいが連絡先も押さえておきたい消費者向けサービスの中間解になります。

ブルートフォース対策と多要素認証で標準に無い防御を足す実装判断

標準authは、パスワードを何回間違えても止めません。ログイン試行の回数制限はDjango本体の機能ではなく、外部のパッケージが担当します。allauthを入れているなら、ACCOUNT_RATE_LIMITSで賄えます。

allauthのレート制限の既定値と管理画面が保護対象にならない注意点

既定では、ログインが1分あたりIPごとに30回、失敗したログインが1分あたりIPごとに10回かつ5分あたり対象アカウントごとに5回に制限されます。パスワードリセットの申請は1分あたりIPごとに20回、対象アドレスごとに5回です。上限を超えると、その時間枠の残りはログインを拒否します。

見落としやすいのは適用範囲です。allauthの公式ドキュメントは、この制限がallauthのログインビューを守るものであって、Djangoの管理画面のログインをブルートフォースから守るものではないと明記しています。管理画面のURLを既定のまま公開している構成では、対策の穴がそのまま残ります。管理画面のパスを変える、社内ネットワークやVPNからのみ到達できるようにする、といった手当てを別に行ってください。標準で防ぎ切れない領域の整理はDjangoの脆弱性への対応｜セキュリティリリースの追い方と標準で防げない穴に寄せています。

多要素認証もallauth側の担当です。ワンタイムパスワードやリカバリーコードを扱うMFA向けのアプリが同梱されており、追加のパッケージを探さずに要件を満たせます。標準authだけで多要素を組もうとすると、コードの発行と検証、端末の登録、リカバリー手段の設計をすべて自作することになります。

標準authのまま出せる条件とallauth・自前実装へ移す条件

3択の分岐は、要件の4項目で決まります。ソーシャルログイン、メール到達の確認、多要素認証、ログイン試行の制限。このいずれも要らないなら、標準authのままで出して構いません。社内利用で、アカウントを管理者が発行し、パスワード変更とリセットだけがあればよい業務システムは、この条件にきれいに収まります。

4項目のうち1つでも要件に入るなら、その時点でdjango-allauthへ寄せます。1つだけだから自前で書く、という判断は割に合いません。ソーシャルログインを1つ足すだけでも、認可コードの交換、アカウントの紐付け、既存メールアドレスとの衝突処理、連携解除の扱いまで付いてくるためです。allauthは各プロバイダのアダプタとその周辺処理をまとめて持っています。

認証そのものを自前で実装するのは、外部の認証基盤に寄せる場合を除いて見送ります。パスワードの保存形式、ログイン成功時のセッションキー再生成、リセットトークンの有効期限と使い捨て、タイミング攻撃への配慮といった、間違えると事故に直結する処理を自分の責任範囲に取り込むことになるからです。既存の会員基盤や社内IDと突き合わせる必要があるなら、自作ではなく認証バックエンドを1つ書いて差し込む形にします。この層はDjangoが差し替え口を用意しています。

なお、ログイン状態をどこに保持するかは認証とは別の設定で決まります。保存先の選び方と複数台構成での注意点はDjangoのセッション設定：保存先5種の選び分けとRedis構成の判断で扱っています。

なお、フロントエンドをReactなどのSPAで分離している構成では、ここまでのHTML画面ではなくトークン方式の認証を使います。その実装はReactとDjangoを連携する方法｜REST API・CORS・JWT認証の実装手順で扱う内容です。会員データの設計から画面までまとめて任せたい場合は、会員管理システム開発で要件整理から対応しています。

よくある質問

Djangoのログイン機能は自分で作る必要がありますか？

必要ありません。django.contrib.authにログイン、ログアウト、パスワード変更、パスワードリセットのビューが揃っており、URLをincludeしてテンプレートを置けば動きます。自作するとパスワードの保存形式やリセットトークンの管理まで自分の保守範囲に入るため、要件が特殊でない限り標準のビューを使ってください。

カスタムユーザーモデルは後からでも入れられますか？

技術的には可能ですが、初回migrate後の切り替えは外部キーの張り替えとデータ移行を伴います。Userテーブルは権限、セッション、管理画面の履歴、アプリ側のモデルから広く参照されるためです。公式もプロジェクト開始時の設定を勧めています。予定が無くても、初回にAbstractUserを継承した空のモデルを置いておくと後の自由度が上がります。

ユーザー名ではなくメールアドレスでログインさせるには？

カスタムユーザーモデルでUSERNAME_FIELDにemailを指定し、email列には一意制約が必要です。REQUIRED_FIELDSからemailを外し、マネージャのcreate_userとcreate_superuserを書き換え、管理画面のUserAdminからusernameの参照を外す、の4点が最低限の作業になります。allauthを使うなら、ACCOUNT_LOGIN_METHODSにemailを指定する方法もあります。

django-allauthは必ず入れるべきですか？

要件次第です。ソーシャルログイン、メール到達の確認、多要素認証、ログイン試行の制限のいずれかが要るなら入れます。どれも不要な社内システムでは、標準authだけで完結させたほうが依存が減り、バージョン追随の手間も小さくなります。後から入れる場合、ユーザーモデルはそのまま使えるため、移行の負荷は比較的軽い部類です。

ログアウトのリンクを押しても何も起きないのはなぜですか？

Django 5.0でGETによるログアウトの対応が削除されたためです。現在のLogoutViewはPOSTでのみログアウトを実行します。aタグをCSRFトークン付きのフォームに置き換えてください。古い解説記事のコードをそのまま使っている場合に起きやすい不具合で、バージョンを上げた直後に表面化します。