Посмертный анализ: неожиданное изменение `iss` в JWT

Краткое описание#

18.03.2024 в Logto Cloud было обновление, изменяющее поведение издателя JWT, что нарушило процессы аутентификации для пользователей с кастомными доменами и проверкой iss. Для исправления проблемы таким пользователям потребовалось обновить логику проверки.

• Затронутые пользователи: пользователи с включенными кастомными доменами и проверкой iss.
• Степень серьезности: критическая, нарушающая проверку iss в процессах аутентификации.

Коренная причина#

Обновление изменило поле iss так, чтобы оно соответствовало запрашиваемому домену, нарушив существующие проверки, ожидающие предыдущего издателя по умолчанию.

Хронология#

• 18.03.2024 10:00 (UTC): развертывание обновлений, изменение поведения iss.
• 18.03.2024 23:30 (UTC): поступил первый отчет от пользователя о нарушении существующего поведения.
• 19.03.2024 12:00 (UTC): подтверждение проблемы и начало расследования.
• 19.03.2024 14:00 (UTC): определение коренной причины и последствий.
• 20.03.2024 20:00 (UTC): подготовка письма для затронутых пользователей.
• 20.03.2024 06:00 (UTC): отправка писем всем затронутым пользователям.

Анализ воздействия#

Подробности релиза#

Logto Cloud поддерживает кастомные домены для аутентификации. Разработчики могут задать конечную точку с кастомным доменом в SDK, тогда конечный пользователь будет использовать эту конечную точку для инициации аутентификационной процедуры и получения токенов. Некоторые токены имеют форму JWT, которая включает поле iss, указывающее на издателя этого токена. Ранее, даже когда использовалась конечная точка с кастомным доменом для запроса токена доступа, издатель оставался нашим стандартным доменом ([tenant-id].logto.app).

Однако домен издателя должен быть таким же, как и запрошенная конечная точка. Поэтому мы выпустили обновление, чтобы устранить эту проблему, и теперь поле iss автоматически будет отражать домен, использованный в запросе.

Для тех, кто уже использует кастомные домены для выдачи токенов и реализовал проверку поля iss на сервере ресурсов, это может быть разрывным изменением. Существующая аутентификационная проверка не пройдет из-за изменения издателя. Чтобы это исправить, разработчикам необходимо изменить код проверки, заменив ожидаемого издателя на нового с кастомным доменом.

Мы не учли в полной мере влияние на существующие проверки iss, в результате чего этот релиз стал разрывным изменением без предварительного уведомления.

Решение#

Уведомили затронутых пользователей по электронной почте, посоветовав им обновить свою проверку iss, чтобы она соответствовала запрашиваемому домену.

Откаты?#

Изменение является необходимым исправлением для поля издателя, и некоторые пользователи уже могли адаптироваться к новому поведению. Откат вызовет путаницу и несоответствия.

Извлеченные уроки#

• Изменения в коде, влияющие на основную аутентификацию, должны иметь подтверждение команды в дополнение к обычным обзорам.
• Автоматические тесты должны охватывать больше случаев, особенно в облачных сценариях.

Корректирующие и предупредительные меры#

• Добавить интеграционные тесты: Добавить случаи тестирования, чтобы охватить сценарий в этом инциденте.
• Проекты мониторинга функций: В дополнение к Logto Cloud создайте наши собственные побочные проекты и глубоко интегрируйтесь с Logto, чтобы предугадывать потенциальные проблемы до релизов.