「JWTでログイン機能を作ろう」と思ったら、気づいたら5個もライブラリを入れていた……なんてこと、ありませんか?😅
python-jose、passlib、Redis、自作RBAC……パズルみたいにライブラリを組み合わせていくのは、正直しんどいですよね。そんな課題にズバッと切り込む面白い比較記事が話題になっています。
🔐 本格的なAuth、実は「意外と部品が多い」

「JWT認証」と一口に言っても、実際に本番で使えるレベルにするには、こんなピースが必要になります。
- ✅ パスワードハッシュ(Argon2id推奨。新規プロジェクトでbcryptはもう古い)
- ✅ JWTの署名と検証
- ✅ RBAC(ロールベースアクセス制御):管理者・一般ユーザーの権限管理
- ✅ ログアウト時のトークン失効(ブラックリスト管理)
これをFastAPIで実装しようとすると、自然と python-jose + passlib + Redis + 自作RBACの組み合わせになりがちです。
⚡ FastAPIでの典型的な実装イメージ
ポイントをまとめるとこんな感じです👇
# FastAPI + python-jose + passlib の典型パターン
from fastapi import FastAPI, Depends, HTTPException, status
from jose import JWTError, jwt
from passlib.context import CryptContext
from datetime import datetime, timedelta
SECRET_KEY = "your-secret-key"
ALGORITHM = "HS256"
# パスワードハッシュ設定(Argon2idを推奨)
pwd_context = CryptContext(schemes=["argon2"], deprecated="auto")
# トークン失効用ブラックリスト(本番はRedisに替える)
blacklist: set[str] = set()
app = FastAPI()
def create_token(data: dict, expires_delta: timedelta = timedelta(minutes=30)):
"""JWTトークンを生成する"""
payload = data.copy()
payload["exp"] = datetime.utcnow() + expires_delta
return jwt.encode(payload, SECRET_KEY, algorithm=ALGORITHM)
def verify_token(token: str):
"""トークンを検証 + ブラックリストチェック"""
if token in blacklist:
raise HTTPException(status_code=401, detail="トークンは無効化されています")
try:
payload = jwt.decode(token, SECRET_KEY, algorithms=[ALGORITHM])
return payload
except JWTError:
raise HTTPException(status_code=401, detail="トークンが不正です")
def require_role(required_role: str):
"""RBACの簡易実装:ロールを確認するデコレータ的な依存関係"""
def checker(payload: dict = Depends(verify_token)):
if payload.get("role") != required_role:
raise HTTPException(status_code=403, detail="権限がありません")
return payload
return checker
@app.get("/admin")
def admin_only(user=Depends(require_role("admin"))):
return {"message": f"ようこそ管理者 {user['sub']} さん!"}
@app.post("/logout")
def logout(token: str):
"""トークンをブラックリストに追加してログアウト"""
blacklist.add(token)
return {"message": "ログアウトしました"}
ここが重要です📌
- ブラックリストをメモリ上のsetで管理しているので、本番環境ではRedisに置き換えが必要
- RBACはFastAPIの
Dependsを使って「依存関係として注入」するパターンが主流 - ライブラリが増えるほど、バージョン管理や互換性の維持コストも増える
🆚 Fitzというアプローチが面白い理由
今回話題になっているのが、Fitzというフレームワークを使うと、これらを追加ライブラリなし・言語組み込みの機能だけで実装できるという主張です。
つまり……「ライブラリを5個並べてパズルを解く」のではなく、最初からAuth機能がまとまっている設計思想ですね。
FastAPI側は「組み合わせの自由度が高い」、Fitz側は「最初からまとまっていて追加作業が少ない」というトレードオフです。どちらが正解かではなく、プロジェクトの規模や用途で選ぶのがポイントです。
📝 まとめ
JWT認証・RBAC・トークンブラックリストを組み合わせた本格的なAuth実装は、FastAPIだと複数ライブラリの連携が必要になりがちです。一方、Fitzのように「全部内包」を目指すアプローチも出てきています。
まずはFastAPIで基本的な流れを手を動かして確認してみてください。「むずかしそう」を「できそう」に変える第一歩になるはずです💪 ぜひ試してみてください!





