【要約】1つの JWT で複数 service を verify したかったら、python-jose の audience list 仕様の罠を踏 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
Codensの開発者が、単一のJWTを複数のサービスで検証する仕組みを構築した際に直面した問題である。設計上、トークンのaudience claimに複数の値を保持させる必要があったが、ライブラリの仕様が壁となった。
- ・RFC 7519では、audienceは文字列またはリスト形式が許容されている。
- ・python-joseの
jwt.decodeは、引数にリストを渡すと型エラーで停止する。 - ・PyJWT等の他ライブラリとは仕様の互換性がなく、ライブラリ側の修正も期待できない状態にある。
// Approach
開発者は、全サービスのライブラリ刷新という重いコストを避け、検証ロジックを分離する手法を採用した。ライブラリの機能を部分的に無効化し、不足分を自前で補完するアプローチである。
- ・
options={'verify_aud': False}を指定し、ライブラリによる自動検証を無効化した。 - ・署名や有効期限の検証はライブラリに任せ、セキュリティレベルを維持した。
- ・トークンのaudienceを集合（set）に変換し、許可リストとの積集合（intersection）を用いて手動で照合した。
// Result
この手法により、既存の依存関係を維持したまま、目的の認証フローを安全に実現した。設計の分離が副次的なメリットをもたらしている。
- ・全サービスの認証ライブラリを入れ替える膨大なコストを回避できた。
- ・「デコード」と「検証」を分離したことで、サービスごとの個別ポリシー適用が容易になった。
- ・
python-joseのoptionsを活用し、検証項目を細かく制御する堅牢な構造を得た。
Senior Engineer Insight
> ライブラリの仕様を過信せず、RFCとの乖離を即座に検知した判断は極めて実践的である。大規模システムにおいて、認証基盤のライブラリ刷新はリスクが非常に高い。今回のように「検証ロジックの分離」という設計パターンを選択したことは、将来の拡張性（ポリシーの個別化）に大きく寄与する。ただし、python-joseのメンテナンス状況を考慮すると、新規プロジェクトでは最初からPyJWTを選択すべきだ。ライブラリのquirk（癖）を考慮した設計は、実戦における必須スキルと言える。