Проверяю, не упустил ли я что-то. Я знаю, что download_avatar_url, основанный на атрибуте userinfo/picture, не сработает, так как в этом запросе не передается токен доступа (для Entra это конечная точка graph/me). Добавление логики авторизации в импортер кажется запутанным набором условных операторов и ненадежным решением.
У меня есть анонимная конечная точка для аватаров, которая может работать (проверено с использованием замены по внешнему URL и имени пользователя).
Обычно я бы обрабатывал подобные вещи с помощью необязательных утверждений (claims) в Entra, и приложение сопоставляло бы эти утверждения с правильными полями на своей стороне. Я могу это успешно сделать и увидеть правильно отформатированный JWT с утверждениями в подробном логе OIDC. Однако стандартный поток предполагает использование access_token для получения данных пользователя (userinfo), что я не могу добавить или изменить, а остальные утверждения отбрасываются.
Я заметил, что если конечная точка userinfo_endpoint не определена, система будет использовать утверждения из JWT. Проблема в том, что это срабатывает на основе содержимого документа обнаружения (discovery doc), которое я не могу изменить, так как оно является частью .well-known. Внесение изменений в Ruby-код для принудительного использования JWT — это костыль. Мы даже думали о создании «форка» документа обнаружения и его обслуживании публично на нашем деплое, но это тоже довольно костыльное решение.
Не упустил ли я какой-то механизм для установки (или отбора) переменных вместо возни с документом обнаружения? Я не против их дублирования вместо использования discovery, но не вижу способа сделать это без патчинга кода.