Support multiple OIDC user agent response formats

[mooreds]

Support multiple OIDC user agent response formats

Problem

For certain configurations of OIDC identity providers, the user info is not returned as JSON, but rather as a JWT (either signed or encrypted/nested). This is allowed by the spec.

FusionAuth only supports the plain JSON response (as documented here: FusionAuth/fusionauth-site#454 ) but it would be great to support other formats when the configuration of the remote identity provider can't be modified.

Solution

FusionAuth should support all the methods that an OIDC userinfo response could be returned in. From the spec

Upon receipt of the UserInfo Request, the UserInfo Endpoint MUST return the JSON Serialization of the UserInfo Response as in Section 13.3 in the HTTP response body unless a different format was specified during Registration [OpenID.Registration]. The UserInfo Endpoint MUST return a content-type header to indicate which format is being returned. The content-type of the HTTP response MUST be application/json if the response body is a text JSON object; the response body SHOULD be encoded using UTF-8.

If the UserInfo Response is signed and/or encrypted, then the Claims are returned in a JWT and the content-type MUST be application/jwt. The response MAY be encrypted without also being signed. If both signing and encryption are requested, the response MUST be signed then encrypted, with the result being a Nested JWT, as defined in [JWT].

Alternatives/workarounds

Ask the OIDC endpoint admin to send back plain JSON. Use SAML instead to integrate with the IdP.

Additional context

Here's a forum post about this issue: https://fusionauth.io/community/forum/topic/834/getting-error-with-oidc-identity-provider

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[brazabr]

This affects our projects a lot since our customers can't use SAML in newer version of FusionAuth (RSA-SHA1 disallow problem) and can't use OIDC because they can't provide userinfo response as JSON.

And just a reminder, the lack of this feature breaks compatibility with the OIDC specs which clearly states that the userinfo endpoint can provide either an application/json or an application/jwt in section 5.3.2 of OpenID 1.0 Connect Core.

[robotdan]

Thanks for the feedback @brazabr much appreciated. This does seem to be a good addition to FusionAuth, but as far as I can tell, we are not breaking the spec w/out this feature.

I read the following to say the response will be application/json unless a different type was requested during client registration. Since we don't currently offer the option to specify other formats, we are returning the correct response type.

UserInfo Endpoint MUST return the JSON Serialization of the UserInfo Response as in [Section 13.3] in the HTTP response body unless a different format was specified during Registration.

https://openid.net/specs/openid-connect-registration-1_0.html

From what I can tell, all of the various formats are optional, and not required to be offered. Specifications can be difficult to interpret, so if you have a different understanding, please provide additional references you have found and we'll be happy to review them.

[robotdan]

can't use OIDC because they can't provide userinfo response as JSON.

Can you expand upon this further? Does this mean you have customers using OIDC, and when FusionAuth is acting as the OIDC SP - the IdP is deciding they only want to send back the Userinfo in a very particular format (not application/json) and because of this it doesn't work, because we expect the response to be JSON?

So for your use case, are you looking for configuration in the FusionAuth OIDC IdP config to specify how the IdP will be sending back the Userinfo response?

Or are you indicating that when FusionAuth is the IdP, you want to configure how we should be returning the Userinfo response to the SP based upon the ability of the SP to consume various response formats?

[brazabr]

@robotdan I am not interested in discussing the specs, since a lot of implementations don't follow it strictly and I can't control the vendor that my customer is using.

In my case I am trying to setup an external IdP using OIDC. FusionAuth requires me to provide an Userinfo endpoint and always make a request to that endpoint. And the external IdP is always providing the response as an application/jwt and thus making FusionAuth fail with an error and not complete login.

I think supporting multiple response types is great and desired. But I can also think of another option:

• Make FusionAuth not require an Userinfo endpoint and only consume claims provided by the ID Token itself

I am just in a place that I cannot use FusionAuth in Fusion Auth cloud with this limitation. This customer particularly cannot upgrade SAML certificates to something newer than RSA-SHA1 and cannot force his Userinfo endpoint to provide me a JSON response if using OIDC.

[robotdan]

No problem. I can appreciate that you cannot control the vendor.

The reason I mentioned the spec is that you indicated FusionAuth is breaking it, which I don't think is the case. But I am happy to explore the spec in more detail if we are in fact out of compliance so to speak or if there is something we can do to be more compatible with other ODIC IdPs.

In the workflow you are describing FusionAuth is the SP instead of the IdP, and the spec you referenced earlier indicates the IdP must return JSON unless the SP - in this case FusionAuth - requested a different format during client registration. So from what I can tell this 3rd party IdP is assuming the response type of application/jwt which is an invalid assumption because we did not request this format. It is possible that for security reasons this IdP has chosen not to support the default behavior of application/json. Any IdP can choose to make these decisions - but it does make it difficult for OIDC SPs to easily integrate.

Upon receipt of the UserInfo Request, the UserInfo Endpoint MUST return the JSON Serialization of the UserInfo Response as in Section 13.3 in the HTTP response body unless a different format was specified during Registration [OpenID.Registration].

FusionAuth is the SP in this workflow, and we did not ask for a format different from application/json, but it sounds like the IdP is returning application/jwt regardless.

I do think this enhancement request is a good one, and ideally we would support more than one format when we are the IdP sending the Userinfo response, and when we are the SP consuming the Userinfo response.

I can't offer a timeline to deliver this feature, but I do think it it will be valuable and we'll plan to get it into the roadmap.

[robotdan]

This affects our projects a lot since our customers can't use SAML in newer version of FusionAuth (RSA-SHA1 disallow problem) ....

An update here, beginning with version 1.32.0 the following XML signature algorithms were removed when we upgraded to Java 17 (which removes them by default).

http://www.w3.org/2000/09/xmldsig#sha1
http://www.w3.org/2000/09/xmldsig#dsa-sha1
http://www.w3.org/2000/09/xmldsig#rsa-sha1

In version 1.37.0 we re-enabled these algorithms by modifying the default Java security configuration. This change was made under #1814.

• https://fusionauth.io/docs/v1/tech/release-notes#version-1-32-0
• https://fusionauth.io/docs/v1/tech/release-notes#version-1-37-0

[ralphkrauss]

@robotdan Our project is also hard-dependent on an external IdP that only supports the application/jwt UserInfo response for security reasons. It's currently a blocker for using FusionAuth in our application. Was the feature already added to the roadmap? Do you have an estimate on the delivery?

[mooreds]

@ralphkrauss This feature has not been added to the near term roadmap as of now, or it'd be assigned to a milestone. Here's our general roadmap guidance: https://fusionauth.io/docs/v1/tech/core-concepts/roadmap

If this is important to you, please do upvote it. And if you are a paying customer, please open a support ticket stating your desire for this to be implemented. All of these play into the planning process.

Thanks for sharing more details, we appreciate it!