django-allauth 65.18.0でIDトークン有効期限の設定が無視される不具合――IDP_OIDC_ID_TOKEN_EXPIRES_INが常に300秒になる原因と対処

公開 2026年8月9日 114回閲覧 0件のコメント
執筆: クルモン 専門分野: Webインフラ、セキュリティ、データベース
django-allauth 65.18.0でIDトークン有効期限の設定が無視される不具合――IDP_OIDC_ID_TOKEN_EXPIRES_INが常に300秒になる原因と対処
目次

はじめに


django-allauth 65.18.0には、OpenID ConnectのIdentity Provider（IdP）機能で、IDP_OIDC_ID_TOKEN_EXPIRES_INを設定しても値が反映されず、IDトークンの有効期限が常にデフォルトの300秒として扱われる不具合があります。

この問題はdjango-allauth 65.19.0で修正されています。公式リリースノートにも、65.19.0のFixとして明記されています。

原因は複雑なOIDC処理ではありません。

65.18.0では、設定値を取得するための_setting()を呼び出さず、

return 5 * 60

と直接返していました。

つまり、設定ファイルに値を書いても、その設定を読む処理そのものが呼ばれていなかったことが原因です。

この記事の要点

  • django-allauth 65.18.0ではIDP_OIDC_ID_TOKEN_EXPIRES_INを設定してもIDトークン有効期限に反映されない。

  • django-allauth 65.18.0ではIDトークン有効期限が常にデフォルトの300秒として扱われる。

  • 原因はID_TOKEN_EXPIRES_INプロパティから設定取得処理_setting()が呼び出されていなかったことにある。

  • django-allauth 65.19.0ではself._setting("ID_TOKEN_EXPIRES_IN", 5 * 60)へ修正された。

  • この不具合はdjango-allauthをOIDC Identity Providerとして利用している環境が主な影響対象になる。

  • Googleログインなどdjango-allauthをOIDC/OAuthクライアントとして利用するだけの環境は、この不具合とは基本的に別である。

  • IDP_OIDC_ID_TOKEN_EXPIRES_INを未設定で300秒を使用している環境では、実際の動作に差が出ない。

  • 300秒より短い値を設定していた場合は、意図した時間よりIDトークンが長く有効になる可能性がある。

  • 300秒より長い値を設定していた場合は、意図した時間より早くIDトークンが期限切れになる。

  • django-allauth 65.19.0は2026年8月6日に公開され、この不具合が公式に修正されている。

1. 結論：65.18.0でIdPを使っている場合は確認が必要

結論から言えば、django-allauth 65.18.0でOIDC IdP機能を利用し、IDP_OIDC_ID_TOKEN_EXPIRES_INをデフォルト値以外へ変更している環境は確認対象です。

公式ドキュメントでは、IDP_OIDC_ID_TOKEN_EXPIRES_INは「IDトークンが期限切れになるまでの時間を秒数で指定する設定」とされ、デフォルトは300秒です。

ところが65.18.0では設定値が参照されません。

例えば次のように設定していても、

IDP_OIDC_ID_TOKEN_EXPIRES_IN = 3600

期待値は、

3600秒

ですが、65.18.0では実際には、

300秒

として扱われます。

反対に、

IDP_OIDC_ID_TOKEN_EXPIRES_IN = 60

としていた場合でも、実際には300秒になります。

したがって影響は一方向ではありません。

設定値期待する有効期限65.18.0での実際主な影響
未設定300秒300秒実質的な差なし
6060秒300秒意図より長く有効
300300秒300秒実質的な差なし
900900秒300秒意図より早く失効
36003600秒300秒意図より早く失効

django-allauth 65.19.0では、この問題が公式に修正されています。65.19.0は2026年8月6日に公開され、PyPIでも65.19.0が公開されています。

2. この記事で分かること

この記事では、次の点を確認できます。

  • django-allauth 65.18.0で何が起きるのか

  • 自分のDjango環境が影響を受けるのか

  • OIDC、IdP、IDトークンとは何か

  • なぜ設定値が無視されるのか

  • 65.18.0と65.19.0のコードの違い

  • 実際の環境で不具合を確認する方法

  • 65.19.0への安全な更新方法

  • 更新後の動作確認方法

  • 同種の設定不整合をCIで検出する方法

3. 対象読者・前提環境

主な対象読者は、次のようなDjango開発者・運用者です。

  • Djangoでdjango-allauthを使用している

  • OpenID Connectを使用している

  • django-allauthのIdP機能を使用している

  • django-allauth 65.18.0を使用している

  • 認証・SSO基盤を運用している

  • バージョンアップ前に影響範囲を確認したい

特に重要なのが、django-allauthをどちら側で使っているかです。

【今回の主な影響対象】

ユーザー
   ↓
クライアントアプリ
   ↓ 認証要求
Django + django-allauth
   ↓
OIDC Identity Provider
   ↓
ID Token発行

django-allauth自身がIDトークンを発行する側である場合が対象です。

4. 用語と全体像――まずIdPとIDトークンを理解する

OIDCとは

OpenID Connect（OIDC）は、簡単に言えば、

「このユーザーが誰なのかを、別のシステムへ安全に伝えるための仕組み」

です。

OAuth 2.0を土台として、ユーザー認証に必要な仕組みを追加しています。

IdPとは

IdPはIdentity Providerの略です。

たとえるなら、身分証明書を発行する役所です。

利用者本人を認証し、

このユーザーは確かに○○さんです。

という情報をクライアントへ渡します。

django-allauthには通常のログイン機能だけでなく、OIDC Identity Providerとして動作する機能もあります。公式ドキュメントでもIdentity Provider → OpenID Connectとして独立した機能群が用意されています。

IDトークンとは

ID TokenはOIDCで利用される、ユーザー認証結果を表すトークンです。

一般的にはJWT形式で、

{
  "iss": "https://example.com",
  "sub": "12345",
  "aud": "client-app",
  "iat": 1786270000,
  "exp": 1786270300
}

のような情報を持ちます。

重要なのが、

iat = 発行時刻
exp = 有効期限

です。

今回の不具合は、このexpを決める時間設定に関係します。

5. 何が起きたのか

【事実】

django-allauthの公式リリースノートでは、65.19.0のFixとして、

IDP_OIDC_ID_TOKEN_EXPIRES_INを設定しても常にデフォルト値を返していた問題を修正した

ことが明記されています。

65.18.0は2026年5月29日に公開されています。

65.19.0は2026年8月6日に公開されています。

つまり、

65.18.0
   │
   │ IDP_OIDC_ID_TOKEN_EXPIRES_IN
   │ 設定を書いても参照されない
   ↓
常に300秒
   │
   │ 修正
   ↓
65.19.0
   │
   ↓
settings.pyの値を正しく取得

という問題です。

6. 自分に関係するか

まず次の表で判断できます。

利用方法影響
django-allauth 65.18.0 + OIDC IdP要確認
65.18.0 + IDP_OIDC_ID_TOKEN_EXPIRES_IN変更済み影響あり
65.18.0 + 設定未変更動作差は基本的になし
Googleログインを利用この不具合の直接対象ではない
GitHubログインを利用この不具合の直接対象ではない
django-allauthをRP/OIDC Clientとしてだけ利用基本的に対象外
django-allauth 65.19.0修正済み

ここは誤解しやすいポイントです。

「OpenID Connectを使っている = 必ず影響する」ではありません。

GoogleなどをIdPとしてDjango側がログインを受け付ける構成と、Django自身がIdPになる構成は別です。

今回問題になっている設定名は、

IDP_OIDC_ID_TOKEN_EXPIRES_IN

です。

先頭がIDP_OIDC_であることからも、django-allauthのIdentity Provider側の設定であることが分かります。

7. 原因――設定を読む関数そのものが呼ばれていなかった

今回のポイントです。

65.18.0の実装

65.18.0では次の実装でした。

@property
def ID_TOKEN_EXPIRES_IN(self) -> int:
    return 5 * 60

5 * 60なので、

300秒

です。

ここにはDjangoのsettingsを読む処理がありません。

他の設定はどうなっていたのか

例えば同じクラスのAccess Token設定では、

@property
def ACCESS_TOKEN_EXPIRES_IN(self) -> int:
    return self._setting("ACCESS_TOKEN_EXPIRES_IN", 3600)

という形で、self._setting()を呼び出します。

考え方は、

settings.py
    ↓
IDP_OIDC_ACCESS_TOKEN_EXPIRES_IN
    ↓
_setting()
    ↓
AppSettings
    ↓
実際の処理

です。

ところが65.18.0のID Tokenだけは、

settings.py
    ↓
    × 読まれない

AppSettings
    ↓
5 * 60
    ↓
300秒固定

となっていました。

65.19.0ではどう直ったのか

65.19.0では次のように変更されています。

@property
def ID_TOKEN_EXPIRES_IN(self) -> int:
    return self._setting("ID_TOKEN_EXPIRES_IN", 5 * 60)

つまり、

 @property
 def ID_TOKEN_EXPIRES_IN(self) -> int:
-    return 5 * 60
+    return self._setting("ID_TOKEN_EXPIRES_IN", 5 * 60)

という非常に小さな修正です。

しかし意味は大きく異なります。

65.18.0

300を返す

65.19.0

IDP_OIDC_ID_TOKEN_EXPIRES_INがあればその値
              ↓
なければ300

となります。

したがって今回の不具合は、厳密にはPythonの「引数順序不整合」や「関数シグネチャ不一致」ではありません。

設定値を取得するアクセサ_setting()の呼出し漏れによる設定参照不整合

と表現するのが正確です。

8. IDトークンにはどう影響するのか

django-allauthのOIDC実装では、IDトークンのexpを、

id_token["exp"] = (
    id_token["iat"] + app_settings.ID_TOKEN_EXPIRES_IN
)

という考え方で決定します。

つまり、

発行時刻 iat
   +
ID_TOKEN_EXPIRES_IN
   =
有効期限 exp

です。

65.18.0でID_TOKEN_EXPIRES_INが300固定になれば、IDトークンの有効期限も設定値ではなく300秒を基準に計算されます。

9. セキュリティ上の問題なのか

ここは慎重に区別する必要があります。

【事実】

65.19.0の公式リリースノートでは、この問題はSecurity noticeではなくFixesに掲載されています。

2026年8月9日時点で、この問題についてCVE番号が割り当てられたことは確認できません。

GitHubのdjango-allauth Securityページにも公開Security Advisoryは掲載されていません。

したがって、

django-allauth 65.18.0に重大な認証脆弱性がある

と断定するのは適切ではありません。

ただし設定内容によってはセキュリティポリシーへ影響する

例えば、

IDP_OIDC_ID_TOKEN_EXPIRES_IN = 60

として、

IDトークンは1分で失効させる

というポリシーを設定していたとします。

65.18.0では実際には300秒になります。

期待
60秒
 │
 └────────────┐
              ↓
実際
300秒

つまり意図より240秒長くなります。

【一般論】

トークンの有効期限を短く設定する設計では、トークン漏えい時に利用可能な時間を短縮する狙いがあります。

そのため、設定した有効期限より長くトークンが有効になることは、認証ポリシーとの不整合につながる可能性があります。

一方、

IDP_OIDC_ID_TOKEN_EXPIRES_IN = 3600

だった場合は300秒で切れるため、主な影響は可用性や再認証頻度の増加になります。

10. 確認方法1――django-allauthのバージョンを確認する

目的

現在の環境が65.18.0か確認します。

実行場所

Djangoアプリケーションを動かしているPython仮想環境、Dockerコンテナ、またはアプリケーションサーバー上で実行します。

python -m pip show django-allauth

影響確認が必要な例

Name: django-allauth
Version: 65.18.0

修正済みの例

Name: django-allauth
Version: 65.19.0

判断

65.18.0
    ↓
次の確認へ

65.19.0以上
    ↓
今回の不具合は修正済み

なお、65.19.0は2026年8月6日にPyPIへ公開されています。

11. 確認方法2――設定値とallauth内部値を比較する

こちらの方法が最も分かりやすいです。

例えばsettings.pyへ、

IDP_OIDC_ID_TOKEN_EXPIRES_IN = 900

を設定しているとします。

目的

Django設定値と、django-allauthが実際に参照している値を比較します。

実行場所

Djangoプロジェクトのmanage.pyが存在するディレクトリです。

python manage.py shell -c "from django.conf import settings; from allauth.idp.oidc import app_settings; print('Django settings =', getattr(settings, 'IDP_OIDC_ID_TOKEN_EXPIRES_IN', '<not set>')); print('allauth =', app_settings.ID_TOKEN_EXPIRES_IN)"

65.19.0で900を設定した正常例

Django settings = 900
allauth = 900

65.18.0で発生する異常例

Django settings = 900
allauth = 300

判断方法

設定値 == allauth値
    ↓
正常

設定値 != allauth値
    ↓
設定参照不整合

注意：設定未指定の場合

次の結果だった場合、

Django settings = <not set>
allauth = 300

これは異常ではありません。

公式ドキュメント上もデフォルト値は300秒です。

したがって、

allauth = 300

という結果だけを見て、

65.18.0のバグが発生している

とは判断できません。

デフォルト値以外を設定しているのに300になることが重要です。

12. 対処方法――65.19.0以降へ更新する

この不具合の正式な修正は65.19.0に含まれています。

そのため、基本的な対処は65.19.0以降へのアップデートです。

更新前の注意

本番環境へ直接、

pip install -U django-allauth

を実行する方法は推奨しません。

依存関係の変更によって別の機能へ影響する可能性があります。

最低でも次を保存します。

python -m pip freeze > requirements-before-allauth-update.txt

さらに、Gitで依存関係ファイルを管理している場合は、更新前の状態をコミットまたはタグとして残します。

データベースを利用する本番システムでは、通常のデプロイ手順に従ってバックアップも確認してください。

requirements.txtの場合

例えば、

django-allauth==65.18.0

を、

django-allauth==65.19.0

へ変更します。

その後、検証環境で、

python -m pip install -r requirements.txt

を実行します。

PyPIでは65.19.0のwheelおよびsource distributionが2026年8月6日に公開されています。

13. 動作確認

アップデートしただけで完了にはしません。

先ほどのコマンドをもう一度実行します。

python manage.py shell -c "from django.conf import settings; from allauth.idp.oidc import app_settings; print('Django settings =', getattr(settings, 'IDP_OIDC_ID_TOKEN_EXPIRES_IN', '<not set>')); print('allauth =', app_settings.ID_TOKEN_EXPIRES_IN)"

例えば、

IDP_OIDC_ID_TOKEN_EXPIRES_IN = 900

なら、

Django settings = 900
allauth = 900

になれば設定参照部分は正常です。

さらにOIDC IdPを実際に使用している場合は、検証用クライアントから認証を行い、発行されたIDトークンの、

exp - iat

も確認します。

900秒設定なら概ね、

exp - iat = 900

になることを確認します。

本番トークンを外部JWT解析サイトへ貼り付けない

IDトークンにはユーザーを識別できる情報などが含まれる場合があります。

本番環境のトークンを、確認のために第三者のJWT解析Webサービスへ貼り付けることは避けます。

必要ならローカル環境で解析します。

14. 再発防止――設定値を「書いた」だけで安心しない

今回の不具合から得られる重要な教訓があります。

settings.pyへ設定した
        │
        ↓
設定できたはず

では不十分です。

実際には、

settings.py
   ↓
設定アクセサ
   ↓
ライブラリ内部
   ↓
トークン生成
   ↓
実際の出力

まで確認する必要があります。

テストで設定反映を確認する

例えばプロジェクト側で次のようなテストを用意できます。

from django.test import SimpleTestCase, override_settings


class OIDCSettingsTest(SimpleTestCase):

    @override_settings(
        IDP_OIDC_ID_TOKEN_EXPIRES_IN=900
    )
    def test_id_token_expiration_setting(self):
        from allauth.idp.oidc import app_settings

        self.assertEqual(
            app_settings.ID_TOKEN_EXPIRES_IN,
            900,
        )

このテストで確認したいのは、

設定ファイルへ900を書いた

ことではありません。

allauth内部から900として取得できる

ことです。

こうしたテストをCIへ入れておけば、ライブラリ更新時の設定不整合を検出しやすくなります。

15. WAF・IPS・EDRで防げる問題ではない

今回の問題は外部から送信された悪意あるHTTPリクエストによって発生するタイプの問題ではありません。

攻撃者
 ↓
WAF
 ↓
Webアプリ

という境界ではなく、

settings.py
 ↓
django-allauth設定アクセサ
 ↓
OIDC処理

というアプリケーション内部の設定処理にあります。

そのため、

  • WAF

  • IPS

  • IDS

  • EDR

で根本的に防ぐ種類の問題ではありません。

重要なのは、

依存ライブラリのバージョン管理
+
リリースノート監視
+
設定値の自動テスト
+
OIDC統合テスト

です。

16. 注意点・よくある誤解

誤解1：django-allauth 65.18.0なら全ユーザーに影響する

違います。

今回の問題はOIDC IdP用の、

IDP_OIDC_ID_TOKEN_EXPIRES_IN

に関係します。

通常のログイン機能だけを使っているサイトまで一律に影響すると考える必要はありません。

誤解2：Googleログインを使っているから対象になる

必ずしも対象ではありません。

GoogleをIdentity ProviderとしてDjangoがログインを受け取る構成と、django-allauth自身をIdentity Providerとして動かす構成は違います。

誤解3：300秒と表示されたらバグである

違います。

公式のデフォルト値自体が300秒です。

設定していない場合に300秒になるのは正常です。

誤解4：重大なCVEである

2026年8月9日時点で、そのような事実は確認できません。

公式リリースノートでもSecurity noticeではなくFixesとして扱われています。

CVE番号も確認できません。

そのため、根拠なく「重大な認証脆弱性」と表現することは避けるべきです。

17. まとめ

django-allauth 65.18.0には、OIDC Identity Provider用設定、

IDP_OIDC_ID_TOKEN_EXPIRES_IN

が反映されない不具合があります。

原因は65.18.0の実装で、

return 5 * 60

とデフォルト値を直接返していたためです。

65.19.0では、

return self._setting(
    "ID_TOKEN_EXPIRES_IN",
    5 * 60,
)

へ修正されています。

したがって確認手順はシンプルです。

django-allauthのバージョン確認
        ↓
65.18.0か？
        ↓ YES
IDP OIDCを使用しているか？
        ↓ YES
IDP_OIDC_ID_TOKEN_EXPIRES_INを変更しているか？
        ↓ YES
設定値とapp_settingsを比較
        ↓
300固定なら影響あり
        ↓
65.19.0以降へ更新
        ↓
再確認
        ↓
OIDC統合テスト

設定ファイルに正しい値が書かれていても、ライブラリがその値を読み取っているとは限りません。

今回の不具合は、「設定値そのもの」だけではなく「設定が実際の処理まで届いているか」をテストする重要性がよく分かる事例です。

18. FAQ

Q1. django-allauth 65.18.0を使っていたら必ずアップデートする必要がありますか？

今回の不具合だけで判断する場合、OIDC IdP機能を使用していなければ直接的な影響は限定的です。

ただし65.19.0にはこの修正以外の変更も含まれるため、公式リリースノートを確認した上で通常の依存ライブラリ更新計画に組み込むことを推奨します。

Q2. IDP_OIDC_ID_TOKEN_EXPIRES_INを設定していません。影響しますか？

デフォルトは300秒です。

65.18.0も300秒を返すため、この設定に限って見れば実際の結果に差はありません。

Q3. 60秒を設定していました。

65.18.0では300秒になるため、意図した値より長くなります。

更新を優先して確認すべきケースです。

Q4. 3600秒を設定していました。

65.18.0では300秒になるため、意図より早くIDトークンが期限切れになります。

再認証やクライアント側の認証処理へ影響していなかったか確認します。

Q5. Access Tokenも300秒固定になりますか？

今回公式に修正された問題はIDP_OIDC_ID_TOKEN_EXPIRES_INです。

65.18.0のACCESS_TOKEN_EXPIRES_INは_setting()を使用して設定を取得する実装になっています。

そのため、今回と同じ原因によるAccess Token設定の固定化とは分けて考える必要があります。

Q6. WAFで対策できますか？

できません。

外部リクエストを検査する問題ではなく、ライブラリ内部の設定参照処理の問題です。

Q7. CVEはありますか？

2026年8月9日時点で、この不具合に対応するCVEは確認できません。

公式リリースノートではSecurity noticeではなくFixesに分類されています。

19. 参考情報


読んだ内容を10問練習と実技で確認

記事で理解した用語を、StudyQuestの演習とクラウド実技ラボで定着させます。

10問練習 実技ラボ

コメント（0件）

まだコメントはありません。最初のコメントを投稿してください！

コメントを投稿