Group claims missing when login from localhost

Hi I noticed that for some reason the group claims is missing when I log in from localhost.
If I login from our deployed website everything is working fine.

I am using okta-react with pkce disabled. Any idea why idtoken is missing the claims?

Hi @dusan.plavak,

Are you using the same authorization server for both localhost and deployed website?
If so, are you including the openid and groups scope in your authorization request?

I hope you’ve seen this document which explains this -

Hi yop, everything is same, the only change is dns name from which the app is served and redirect uri (because of dns name change)

So in both cases I am using exactly same code, but it behaves differently.

Hi @dusan.plavak

Can you please confirm the issuers that are set for both production and localhost environments? Also, is the callback URL for localhost added in the OIDC application’s settings in Okta under General >> Login Redirect URIs?

I can confirm that issuer is same for both envs and login redirect Uris contains localhost (I checked that, but I would get 400 anyway if it was not there)

@dragos also note I am specifying group claims in Sign On tab, in section OpenID Connect ID Token, so it is not under authorization server

@dusan.plavak It sounds like you might be running into expected behavior, regarding ‘thin’ ID tokens (where if you request both an ID and an Access token in the same request, the ID token will not contain the full list of claims). If this is the case, as long as you include the ‘groups’ scope in your request, you should still see the groups claim in the output from the /userinfo endpoint.

Can you try sending your access token to /userinfo to see if this is what’s happening?

More info about what I’ve described here:

Hi does it also explain that this behaviour is kid of random? Sometimes it return group claims and sometimes not

Does it differ based on the user? If the Groups claim filter/expression you have created does not result in any matches for the user logging in, their token will not contain the ‘groups’ claim (same as with any other attribute that may be getting pulled into a claim).

Nope, same user. :frowning:

For now we just dropped token from response type and kept only id_token… I guess we are not going to investigate it anymore for now, as the behaviour seems to be random and we do not have exact steps on how to reproduce it