JWT claims instead of Userinfo in oidc-connect with Entra as IdP

Product Support SSO

AI-generated summary

The user is seeking a way to use JWT claims instead of the UserInfo endpoint in OIDC Connect when using Entra as the IdP. They note that the download_avatar_url fails because the access token isn’t included in the UserInfo call, and adding auth logic to the importer is fragile. While they can include optional claims in the JWT and see them in logs, the default flow uses the UserInfo endpoint, which ignores other claims. They discovered that if userinfo_endpoint is undefined, the JWT claims are used, but this depends on the discovery document, which cannot be modified. They consider hacking the code or serving a custom discovery doc, but see these as kludges. They ask if there’s a proper mechanism to set or curate claims without patching the code or altering the discovery document.

1

Seeing if there is something that I have missed. I know that the download_avatar_url based on the userinfo/picture attribute will fail since the access token is not included in that call (for entra this is the graph/me endpoint). Adding auth logic to the importer feels like it would be a mess of conditionals and be fragile.

I do have an avatar endpoint that is anoymous and can work (tested using external URL and username based replacement).

Normally I would just handle this type of thing with optional claims in Entra and the app would map those claims to the correct fields on their side. I can do that successfully and see the properly formatted JWT with the claims in the vebose OIDC log. But the default flow is that the access_token is used to grab userinfo which is not something i can add/modify and the rest of the claims are tossed.

I did notice that if userinfo_endpoint is undefined it will use the claims from the JWT. The issue now is that is triggered off the discovery doc content which is not something i can tweak as it’s part of .wellknown. Hacking the ruby to always use JWT is a kludge. We were even thinking of making a “fork” of the discovery doc and serving it from the public on our deploy, but again pretty kludgey.

Am I just missing some mechanism to set the vars (or curate them) instead of the messing with discovery doc? I don’t mind duplicating them instead of using discovery, but can’t see a way to do that without patching the code.