That is an encoded (signed) JWT being sent in response to the user info request that the FusionAuth OIDC identity provider is making.
This is technically allowed in the OIDC spec, but we do not currently support this response type.
Per spec, the endpoint should support a JSON response which is the default unless the client requests a signed or encrypted response body.
I would look at how your client is registered and see if it is asking for a JWT userinfo response at that time, and change it to be a normal JSON response. You could also file an issue detailing your needs for FusionAuth to support this user info response type.
If that isn't an option, you could also look at using a SAML Identity Provider if the remote identity source supports that.
It sounds like you're asking if you can modify the issuer claim.
You can control the "Issuer", or iss claim, in two different ways:
You can set it in the tenant config, where it will apply for all JWTs issued for that tenant. You'd modify that by navigating to "Tenants", then your tenant, then "General". Modify the "Issuer" field value to be login.example.com.
You can set it at the individual JWT level by modifying the JWT populate lambda. You would do this if you wanted to have a different issuer based on some information from the user or registration data. (This does not appear to be the case here, just including this for completeness.)
I'm not clear if you have more than one tenant in your system; if you do, you can either change the "Issuer" setting for the default tenant (which is what is provided when no tenantId is on the URL) or request the endpoint with a tenantId appended, like this:
The JWT TTL can be configured per application, so if you were using a different application for OIDC vs an API - then you could do it.
But if you don't want to use multiple applications, then it is not possible, at least currently.
I could see a use case for asking for a JWT with a TTL equal to or less than the configuration and that request being honored, that could be a feature request. But as of right now, the only option is different applications.
Yea, that flexibility would be ideal IMO, although the registeredLogoutURLs should be workable for us at this point. FWIW that is actually the behavior I assumed before digging into the docs. I'll definitely add the issue to GitHub, as I think it's probably part of the path to getting OIDC Certification which appears to already have an issue.