事後分析：予期しない JWT `iss` の変更

概要#

2024年3月18日、Logto Cloud の JWT 発行者の動作が変更され、カスタムドメインを持つユーザーと iss 検証を行っているユーザーの認証フローが破損しました。この修正には、ユーザーが検証ロジックを更新する必要がありました。

• 影響を受けたユーザー：カスタムドメインが有効で、iss 検証を行っているユーザー。
• 重大度：重大、認証フロー内の iss 検証が破損。

根本原因#

アップデートにより、iss フィールドが要求されたドメインと一致するようになり、以前のデフォルト発行者を期待する既存の検証が破損しました。

タイムライン#

• 2024年3月18日 10:00 (UTC)： アップデートがデプロイされ、iss の動作が変更。
• 2024年3月18日 23:30 (UTC)： 既存の動作が破損していると最初のユーザーレポートを受け取りました。
• 2024年3月19日 12:00 (UTC)： 問題を確認し、調査を開始。
• 2024年3月19日 14:00 (UTC)： 根本原因と影響を特定。
• 2024年3月20日 20:00 (UTC)： 影響を受けたユーザーへのメール準備。
• 2024年3月20日 06:00 (UTC)： 全影響ユーザーにメールを送信。

影響分析#

リリースの詳細#

Logto Cloud は認証にカスタムドメインをサポートしています。カスタムドメインが有効なテナントを持つ開発者は、SDKでエンドポイントをカスタムドメインに設定でき、最終ユーザーはこのエンドポイントを使用して認証プロセスを開始し、トークンを取得します。一部のトークンは JWT 形式で、トークンの発行者を示す iss フィールドが含まれています。以前は、カスタムドメインのエンドポイントを使用してアクセストークンを要求しても、発行者は依然として標準ドメイン ([tenant-id].logto.app) にデフォルトで設定されていました。

しかし、発行者のドメインは要求されたエンドポイントと同じであるべきです。この問題を修正するためにアップデートをリリースし、今後は iss フィールドがリクエストに使用されたドメインを自動的に反映するようになります。

すでにカスタムドメインを使用してトークンを発行し、リソースサーバーで iss フィールド検証を実装しているユーザーにとって、これは重要な変更となる可能性があります。発行者の変更により既存の認証チェックが失敗します。これを修正するためには、開発者は検証コードを変更し、期待される発行者をカスタムドメインの新しいものに置き換える必要があります。

既存の iss 検証への影響を完全に考慮することができず、結果としてこのリリースが事前の通知なしに破壊的変更となってしまいました。

解決方法#

影響を受けたユーザーにメールで通知し、リクエストされたドメインに一致するように iss 検証を更新するようにアドバイスしました。

ロールバック?#

発行者フィールドに対するこの変更は必要な修正であり、一部のユーザーはすでに新しい動作に適応している可能性があります。ロールバックすると混乱と不整合が生じるでしょう。

学んだ教訓#

• コア認証に影響を与えるコード変更は、通常のレビューに加えてチームによる承認が必要です。
• クラウド固有のシナリオでは特に、より多くのケースをカバーする自動テストを行うべきです。

是正および予防措置#

• 統合テストを追加：このインシデントのシナリオをカバーするテストケースを追加します。
• 機能監視プロジェクト：Logto Cloud に加えて、自分たちのサイドプロジェクトを作成し、Logto と深く統合してリリース前に潜在的な問題をキャッチします。