Ich prüfe, ob ich etwas übersehen habe. Ich weiß, dass der Aufruf von download_avatar_url basierend auf dem userinfo/picture-Attribut fehlschlagen wird, da das Zugriffstoken nicht in diesem Aufruf enthalten ist (für Entra ist dies der graph/me-Endpunkt). Das Hinzufügen von Authentifizierungslogik zum Importer fühlt sich wie ein Durcheinander von Bedingungen an und wäre fehleranfällig.
Ich habe einen Avatar-Endpunkt, der anonym ist und funktioniert (getestet mit externer URL und namensbasierter Ersetzung).
Normalerweise würde ich solche Dinge mit optionalen Claims in Entra handhaben, und die App würde diese Claims auf ihrer Seite den richtigen Feldern zuordnen. Das kann ich erfolgreich tun und sehe den richtig formatierten JWT mit den Claims im ausführlichen OIDC-Protokoll. Aber der Standardablauf ist, dass der access_token verwendet wird, um Benutzerinformationen abzurufen, was ich nicht hinzufügen/ändern kann, und die restlichen Claims werden verworfen.
Mir ist aufgefallen, dass, wenn der userinfo_endpoint undefiniert ist, die Claims aus dem JWT verwendet werden. Das Problem ist jetzt, dass dies durch den Inhalt des Discovery-Dokuments ausgelöst wird, was ich nicht ändern kann, da es Teil von .wellknown ist. Das Hacking von Ruby, um immer JWT zu verwenden, ist eine Krücke. Wir haben sogar darüber nachgedacht, eine “Fork” des Discovery-Dokuments zu erstellen und es von der Öffentlichkeit auf unserem Deploy zu servieren, aber das ist wieder ziemlich kludgey.
Übersehe ich einfach einen Mechanismus, um die Variablen festzulegen (oder zu kuratieren), anstatt das Discovery-Dokument zu manipulieren? Es macht mir nichts aus, sie zu duplizieren, anstatt das Discovery zu verwenden, aber ich sehe keine Möglichkeit, dies zu tun, ohne den Code zu patchen.