📑

# 4.1 認証・ログインセッション管理（Django REST Framework + Vue 編）

に公開
Django
tech

API ドリブン構成において、認証・ログインセッション管理は最初のハードルになる。
Django は標準で認証機能を持っているが、SPA（Single Page Application）や外部サービスと組み合わせる場合は少し工夫が必要。

この記事では Django REST Framework（DRF） + Vue を前提に、認証とセッション管理の仕組みを整理する。
さらに、EC サイトなどでよく使われる JWT 認証、そして実務で特に苦労した Okta 認証 についても触れる。
あわせて、AI をどう活用できるかも補足する。

1. Django 側の認証

標準の認証機構

Django には以下が標準で備わっている。

  • ユーザーモデル（拡張可能）
  • セッションベース認証
  • ログイン・ログアウト API（django.contrib.auth）

業務システムではこれをそのまま活用するケースが多い。

💡 AI活用のヒント
「Django の標準ログイン処理のコード例を出して」と依頼すれば、ほぼそのまま動く雛形が生成される。
ただし、自作ユーザーモデルとの互換や CSRF 対応までは AI が省略しがちなので、自分の環境に合わせて調整が必要。

2. DRF での認証 API

Django REST Framework は以下の認証方式をサポートしている。

  • SessionAuthentication: Django のセッションをそのまま利用
  • TokenAuthentication / JWT: トークンを使った stateless 認証

プロジェクトで採用した方針

  • 業務システム（社内向け） → セッション認証を採用
  • EC サイト（外部公開 API） → JWT 認証を採用

💡 AI活用のヒント
「DRF で JWT 認証を実装して」と依頼すると、djangorestframework-simplejwt を使ったコード例がすぐ出てくる。
ただし、Refresh Token の設計や Vue 側の保管方法までは触れられないことが多いため、そこは設計判断が必須。

3. セッション認証の実装例

ログイン API

# views/custom_login.py
from django.contrib.auth import authenticate, login
from django.http import JsonResponse

def custom_login(request):
    if request.method == "POST":
        username = request.POST["username"]
        password = request.POST["password"]
        user = authenticate(request, username=username, password=password)
        if user is not None:
            login(request, user)
            return JsonResponse({"message": "ログイン成功"})
        return JsonResponse({"error": "ログイン失敗"}, status=400)

Vue 側でのセッション管理

import axios from "axios";

async function login(username, password) {
  const res = await axios.post("/api/login/", { username, password });
  return res.data;
}

ログイン後はセッション ID が Cookie に保存される。

💡 AI活用のヒント
セッション認証は比較的シンプルなので「Vue 側でセッション認証を扱う axios コード例」と依頼すれば、ほぼそのまま使える。
ただし、Cookie の送信設定や CSRF トークンの付与は AI が抜けやすいので、人間の確認が必須。

4. JWT 認証の実装例

外部向け API では JWT を使うケースが多い。
DRF では djangorestframework-simplejwt を利用できる。

インストール

pip install djangorestframework-simplejwt

設定

# settings.py
REST_FRAMEWORK = {
    "DEFAULT_AUTHENTICATION_CLASSES": (
        "rest_framework_simplejwt.authentication.JWTAuthentication",
    )
}

ログイン API

from rest_framework_simplejwt.views import TokenObtainPairView, TokenRefreshView

urlpatterns = [
    path("api/token/", TokenObtainPairView.as_view(), name="token_obtain_pair"),
    path("api/token/refresh/", TokenRefreshView.as_view(), name="token_refresh"),
]

レスポンス例:

{
  "access": "jwt_access_token_string",
  "refresh": "jwt_refresh_token_string"
}

Vue 側での利用例:

api.interceptors.request.use(config => {
  const token = localStorage.getItem("access_token");
  if (token) {
    config.headers.Authorization = `Bearer ${token}`;
  }
  return config;
});

💡 AI活用のヒント
AI は JWT のコードをすぐ出してくれるが、保存場所に localStorage を推奨する例が多い。
実運用では httpOnly Cookie を使う方が安全なので、人間側で判断・修正する必要がある。

5. Okta 認証での注意点（実務で最もハマった部分）

私は実際に Okta 認証を組み込んだ際に、かなり苦労した。
理由は以下の通り。

  • Okta 側の設定（アプリ登録・リダイレクト URI 設定）
  • Django 側の設定（allauth / socialaccount まわり）
  • settings.py の調整（認証バックエンド・コールバック URL）
  • 管理サイトとの兼ね合い

これらが相互に絡むため、構造を的確に整理しないと迷子になる。

さらに、Vue を加えた SPA 構成だとややこしさは倍増する。

  • ローカル開発で 127.0.0.1 と localhost が別オリジン扱いになる
  • CORS / SameSite / Secure 属性などの オリジン関連設定で詰まりやすい
  • Django や allauth のバージョン差で挙動やセキュリティ要件が変わる

👉 このあたりは AI に任せるのは難しく、トライ＆エラーを繰り返すしかなかった。
ただし AI に「Okta + Django + allauth の統合例を示して」と依頼すると、方向性のヒントは得られる。
そこに 自分の環境（リダイレクト URL、オリジン、CSRF 要件など）を的確に提示する ことで、ようやく使えるコードが出てくる。

💡 実務Tips

  • まず AI に「Okta 認証の統合例」を生成させる
  • その上で「うちの環境は Vue SPA / ローカルは 127.0.0.1:8000 と localhost:5173」などの具体条件を追加で伝える
  • 出力を叩き台にしつつ、実際は何度も試行錯誤が必要

6. セッション認証と JWT 認証の比較

項目 セッション認証 JWT 認証
管理方式 サーバーがセッションを保持 stateless（トークンのみ）
CSRF 対策 必要 不要
有効期限 セッションタイムアウト トークンの exp による
スケーラビリティ セッション共有が必要 スケールアウトしやすい
向いているケース 社内システム、イントラ、閉じた環境 EC サイト、スマホアプリ、外部連携 API

💡 AI活用のヒント
比較表の生成は AI が得意。
自分は「セッション認証と JWT 認証のメリット・デメリットを表形式で」と依頼して作り、それに自分の業務要件を追記することで資料を効率化した。

まとめ

認証・ログインセッション管理では以下を押さえる。

  • Django 標準の認証はそのまま使える
  • DRF はセッション認証・JWT 認証を両方サポート
  • 業務システムはセッション認証、EC サイトは JWT 認証と使い分ける
  • JWT は stateless でスケーラブルだが、有効期限とセキュリティ管理が必須
  • Okta 認証は設定とオリジンの組み合わせでハマりやすく、トライ＆エラーが避けられない

💡 AI活用のまとめ

  • 雛形コード生成や比較表は AI に任せると効率的
  • ただし Okta のような外部認証連携は「環境依存の条件を提示しないと使えるコードは出ない」
  • 最終的には試行錯誤と人間の検証が不可欠

次回は、JWT 認証の仕組みと実装 についてまとめる予定。

Discussion