Hi, Hannah. Are you able to request that custom scope from userinfo endpoint? Could you try to get it this way, and let us know the result? Best regards, Alex.

Hi, All I get from the userInfo endpoint is the inum of the user, doesn't seem to be anything else in the response. Thanks, Hannah

Ok, let me give it a try. A couple more questions: 1. Do you use a clean 2.4.4 CE instance there, or have you installed SP1/SP2 patch for it? 2. What OIDC RP's implementation do you use? Please note we are now limiting support for those to the list provided [here](https://www.gluu.org/blog/limiting-openid-connect-community-client-support/).

This was a clean instance, as far as I am aware we have not installed any patches on the box. We are using our own .Net application to make the calls to Gluu.

I think there is a patch for custom scopes. We'll confirm and get back to you tomorrow on this.

Just as an FYI, I have installed SP1, and I am still seeing the same issue. Hannah :)

I tried changing our custom scope to include a pre-existing attribute, "Organisation inum" to test it out. This is being returned fine - maybe it is an issue with my custom attribute setup!

I managed to get this working - turns out the value I had for the SAML2 URI for my custom attribute was incorrect. I have changed both the SAML1 URI and SAML2 URI to be the same value: urn:mace:dir:attribute-def:partygid Does this seem correct? Thank you for all your help, Hannah

Hi, Hannah. Thanks for your updates, and sorry for late response. First, regarding SAML1 and SAML2 uris - those *shouldn't* affect OIDC part. Moreover, if you won't set them at all when creating your custom attribute, Gluu will come up with some auto-generated values which are mostly fine for internal usage. I haven't ever met any issues using attribute with SAML uris generated in such way. I've tested it a bit too. My instance is patched to SP2 (which isn't yet available in the stable repo, but will be very soon; atm you can grub it from our testing repo, if you really want to try it out asap). I couldn't reproduce your issue: when configured correctly, claims based on custom attributes, `edu*` attributes, and regular attributes were all included both in the `id_token` and userinfo's response, in my case. May be it's because SP2 patch contains the fix Michael was mentioning above. I'm not sure how you were able to resolve your issue by changing some SAML uri, though. My only guess is that it wasn't the only change you did, and something else actually resolved it. You could try to change it back to previous value, restart Tomcat, and check whether it will still work as expected, to experiment a bit.

My tests at another 2.4.4 instance patched to SP1 this time show that with very same OIDC client settings it exhibits a different behaviour. Unlike my SP2 instance, it never returns any claims in `id_token` except for some limited set of mandatory claims. Still, it returns all claims I put in request from userinfo endpoint, including the one based on custom attribute. Hannah, when you said before that you were able to resolve your issue, what did you mean? Did you manage to make it to return your custom attribute based claim in `id_token` somehow?

I've figured it out. It all revolves around [this](https://github.com/GluuFederation/oxAuth/issues/340) issue/enhancement reported/proposed by Michael earlier. He refers to [Section 5.4](http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims) of OIDC Core spec, which states: >The Claims requested by the profile, email, address, and phone scope values are returned from the UserInfo Endpoint, as described in Section 5.3.2, when a response_type value is used that results in an Access Token being issued. However, when no Access Token is issued (which is the case for the response_type value id_token), the resulting Claims are returned in the ID Token. In Gluu packages prior to this enhancement oxAuth would have **always** included all claims requested via scopes in `id_token` too. After this enhancement, the only case when anything except for a set of mandatory claims would have been included in the `id_token` was when `response_type` used wouldn't allowed subsequent request to token/userinfo endpoints, i.e. when no authz code or access token is returned in response from authz endpoint, like in case of `response_type=id_token`, used by implicit flow. Michael also proposed to add a new oxAuth's setting `legacy_id_token_claims=true` to preserve legacy behaviour, to facilitate migration to the new version. In my SP2 instance this setting has value "true", and in the mentioned SP1 instance it isn't included in list of settings, what, I suppose, means that a default behaviour (the new one) is in effect. I've tested it by using `response_type=id_token` in request to its authz endpoint, and indeed I got `id_token` with all my claims in response to this request. So, shortly, you are advised to use userinfo endpoint to get all your usual claims whenever it's possible (and that's possible for most of flows defined by OIDC). But if you really need to have them in `id_token` for other flows too, you could try to set `legacy_id_token_claims` to "true" (no guarantee this hack will not be removed in future versions, though, as this is against specs)