<![CDATA[Topics tagged with userinfo]]>https://fusionauth.io/community/forum/tags/userinfoRSS for NodeTue, 18 Aug 2026 15:11:13 GMTInvalid Date60<![CDATA[Adding supplementary user data]]>@Alex-Patterson tunnel rush said in Adding supplementary user data:

@evanm Yes you can use the sub inside of the JWT when making any API call to your backend. In your database this will be a unique Id for the user. You can even get more details about the user from FusionAuth by calling the User endpoints.

https://fusionauth.io/docs/apis/users#response-1

Thanks for sharing!!

]]>https://fusionauth.io/community/forum/topic/2715/adding-supplementary-user-datahttps://fusionauth.io/community/forum/topic/2715/adding-supplementary-user-dataInvalid Date<![CDATA[Save user address and return address (postal_code, street, number...) in OAuth token]]>Hi @vinicius-alfonso !

As documented here: https://fusionauth.io/docs/v1/tech/oauth/endpoints#userinfo we don't provide the address info, even if you pass the address scope.

Per the OpenID spec, section 5.4, it appears that supporting the address scope is optional: https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims

If this is important to you, please file an issue here: https://github.com/fusionauth/fusionauth-issues/issues with details about the use case.

We are guided by our customers and community when it comes to implementation of issues. Here's our general roadmap guidance: https://fusionauth.io/docs/v1/tech/core-concepts/roadmap

]]>https://fusionauth.io/community/forum/topic/1727/save-user-address-and-return-address-postal_code-street-number-in-oauth-tokenhttps://fusionauth.io/community/forum/topic/1727/save-user-address-and-return-address-postal_code-street-number-in-oauth-tokenInvalid Date<![CDATA[Getting error with OIDC identity provider]]>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.

]]>https://fusionauth.io/community/forum/topic/834/getting-error-with-oidc-identity-providerhttps://fusionauth.io/community/forum/topic/834/getting-error-with-oidc-identity-providerInvalid Date