Sto verificando se mi è sfuggito qualcosa. So che download_avatar_url basato sull’attributo userinfo/picture fallirà poiché il token di accesso non è incluso in quella chiamata (per Entra questo è l’endpoint graph/me). Aggiungere la logica di autenticazione all’importer sembrerebbe un pasticcio di condizionali e fragile.
Ho un endpoint avatar che è anonimo e può funzionare (testato utilizzando URL esterni e sostituzione basata sul nome utente).
Normalmente gestirei questo tipo di cose con claim opzionali in Entra e l’app mapperà quei claim ai campi corretti dalla loro parte. Posso farlo con successo e vedere il JWT formattato correttamente con i claim nel log OIDC dettagliato. Ma il flusso predefinito è che access_token viene utilizzato per recuperare userinfo che non è qualcosa che posso aggiungere/modificare e il resto dei claim viene scartato.
Ho notato che se userinfo_endpoint è indefinito, utilizzerà i claim dal JWT. Il problema ora è che questo è attivato dal contenuto del discovery doc che non è qualcosa che posso modificare poiché fa parte di .wellknown. Fare un hack del ruby per utilizzare sempre il JWT è una soluzione di fortuna. Stavamo persino pensando di creare un “fork” del discovery doc e servirlo pubblicamente sul nostro deploy, ma di nuovo, è piuttosto una soluzione di fortuna.
Mi sfugge qualche meccanismo per impostare le variabili (o curarle) invece di modificare il discovery doc? Non mi dispiace duplicarle invece di usare il discovery, ma non vedo un modo per farlo senza modificare il codice.