Je vois s’il y a quelque chose que j’ai manqué. Je sais que download_avatar_url basé sur l’attribut userinfo/picture échouera car le jeton d’accès n’est pas inclus dans cet appel (pour Entra, c’est le point de terminaison graph/me). L’ajout d’une logique d’authentification à l’importateur me semble être un fouillis de conditions et fragile.
J’ai un point de terminaison d’avatar anonyme qui peut fonctionner (testé en utilisant une URL externe et un remplacement basé sur le nom d’utilisateur).
Normalement, je gérerais ce type de chose avec des revendications facultatives dans Entra et l’application mapperait ces revendications aux bons champs de leur côté. Je peux le faire avec succès et voir le JWT correctement formaté avec les revendications dans le journal OIDC détaillé. Mais le flux par défaut est que le access_token est utilisé pour récupérer les informations utilisateur, ce qui n’est pas quelque chose que je peux ajouter/modifier, et le reste des revendications est jeté.
J’ai remarqué que si userinfo_endpoint est indéfini, il utilisera les revendications du JWT. Le problème maintenant est que cela est déclenché par le contenu du document de découverte, ce qui n’est pas quelque chose que je peux ajuster car cela fait partie de .wellknown. Pirater le ruby pour toujours utiliser le JWT est une solution de contournement. Nous pensions même créer une « fourche » du document de découverte et le servir publiquement sur notre déploiement, mais c’est encore une solution de contournement.
Est-ce que je manque juste un mécanisme pour définir les variables (ou les organiser) au lieu de modifier le document de découverte ? Cela ne me dérange pas de les dupliquer au lieu d’utiliser la découverte, mais je ne vois pas comment faire cela sans patcher le code.