I have tried modifying the scopes and claims settings but to no avail.
I amp attempting to retrieve user info via this curl call:
curl -Ssk \
"http://auth.dev.org/oauth/v2/oauth-userinfo?scope=profile" \
-H "Authorization: Bearer _0XBPWQQ_0ee51157-949d-49da-91e9-1d7f19945acc" \
-d "scope=openid profile"
It just returns:
{"sub":"9dcbd13683ff1e37cbc28956a8b062c9c3bae31087a29ebe9fee15b5cecd7ac1"}⏎
The user info endpoint and what is returned by that endpoint is configured by the owner of the authorization server you are connecting to.
While changing scopes for example adding a email scope, or profile scope may return the users profile information on some authorization servers it will not do that on all of them.
The response you are getting would suggest that this authorization server does not return additional claims via the user info endpoint.
The docs for configuring-a-claim implies that this is something that needs to be configured properly.
What is returned from the user-info endpoint is based on the scope of the access token used to call that endpoint. Adding a scope parameter to the call to user-info doesn't change anything. You should make the authorization request with a broader scope, e.g. openid profile email. This way the access token will contain scope that enables you to read that information.
If you have custom claims about the user in your tokens (apart from the defaults that OpenID Connect gives) and you want them to be returned in the user-info endpoint, then you have to properly configure that. Have a look at this tutorial: https://curity.io/resources/learn/token-designer/ to learn how to configure which claims are returned at the user-info endpoint (and inserted into tokens). Basically what you need to do, is to let the Curity Identity Server know that claim X should be associated with scope Y and you want that claim to be returned at the user-info endpoint. Then, if you call the user-info endpoint with an access token that contains scope Y, the response will contain claim X.
I think I can be forgiven for the confusing UI in Curity. It's not until you go into the token designer UI (for the active claims mapper) that you can see which claims are associated with any scope - instead of seeing all active claims for scopes you might not even be utilising. I managed to achieve what I wanted by making sure the openid scope was assigned email and preferred username claims and making sure the openid scope was defined in my initial request to the /oauth-token endpoint. The user_id token now includes these desired fields.