Estoy viendo si me he perdido algo. Sé que la llamada a download_avatar_url basada en el atributo userinfo/picture fallará ya que el token de acceso no está incluido en esa llamada (para Entra, este es el endpoint graph/me). Añadir lógica de autenticación al importador se sentiría como un lío de condicionales y sería frágil.
Tengo un endpoint de avatar que es anónimo y puede funcionar (probado usando URL externa y reemplazo basado en nombre de usuario).
Normalmente, manejaría este tipo de cosas con claims opcionales en Entra y la aplicación mapearía esos claims a los campos correctos en su lado. Puedo hacer eso con éxito y ver el JWT formateado correctamente con los claims en el log detallado de OIDC. Pero el flujo predeterminado es que el access_token se usa para obtener la información del usuario, que no es algo que pueda añadir/modificar, y el resto de los claims se descartan.
Noté que si el userinfo_endpoint está indefinido, usará los claims del JWT. El problema ahora es que esto se activa a partir del contenido del documento de descubrimiento, que no es algo que pueda modificar ya que es parte de .wellknown. Hackear el ruby para usar siempre el JWT es una solución improvisada. Incluso estábamos pensando en hacer una “bifurcación” del documento de descubrimiento y servirlo públicamente en nuestro despliegue, pero de nuevo, es bastante improvisado.
¿Simplemente me falta algún mecanismo para establecer las variables (o curarlas) en lugar de modificar el documento de descubrimiento? No me importa duplicarlas en lugar de usar el descubrimiento, pero no veo una forma de hacerlo sin parchear el código.