ChirpStack oidc object issue

Hi All,

I have solved the initial issue I used this topic for, but have encountered another. The oidc login is now accessible, but it continues to fail.
I have verified with the person that is providing the token that email_verified is being passed in the request token as a string of value “true” which can now be unmarshalled thanks to code @chopmann so kindly added.

My question might be more of a general GO question at this stage. For this object
Does every field mentioned here need to be present in the token for the unmarshalling to succeed?

I am confused because I do not get an error regarding unmarshalling, and as I have to use the Chirpstack-Application-Server image as part of a K8s deployment with its own regulations, I am unable to modify it to test the logs in the environment where these values pass.

This is a template of the object passed.

When the Go JSON unmarshaler does not find the value, each field will be set to its default value (for each type), e…g integer value will be 0, string value will be an empty string, …

1 Like

Do you mind if I ask what is the correct condition for SSO to work?

I have the object coming as in the original post, which I would assume should succeed, but it hasn’t despite the merge of code for email_verified.

Does a user have to pre-exist in the Chirpstack users table, and email_verified is true for that record in order for the operation to succeed?

I have taken another look again and I wanted to check something with you.
Is there something in GO that would automatically call this Unmarshal function? I have tried doing a global search in the ChirpStack App Server code and there is only this one mention of the method.

The UnmarshalJSON method is automatically called when decoding from JSON, it implements the Unmarshaler interface. It is not mandatory to implement this for all struct, only if you want to customize the way how values are unmarshaled. See also:

Ok, thank you so much for the information. It sounds like there must still be some discrepancy in the oidc object being returned. If the fields retain a default value if they can’t be found, and I saw that bool defaults to false in GO then I must revisit the claims.


@orne Hi, so I have done some more digging into things from my side, and this is the structure and fields of the object I am receiving from Azure.

The only thing missing is UserInfoClaims, but surely if that item does not exist in the payload it shouldn’t effect the rest of the object from unmarshalling correct?

And in the unmarshalling process it should only grab the fields mentioned here? There wouldn’t be any issue with there being extra fields in the json would there?

Correct, fields not defined in the struct are ignored. Fields that are in the struct (e.g. user_info_claims) but that are not defined in the JSON payload are set to the default value of that type (empty map in this case).

After some more investigating and digging into the code I’ve seen that there was a code change to the Application Server that removed any ability to use the id_token to pass claims for SSO. The claims are now gotten only from what is returned from userinfo endpoint, which in our case is immutable and doesn’t provide the fields needed.

Essentially, using SSO has been made impossible for us in our flow.

The problem was that in an other use-case, it was exactly the opposite. That implementation required the use of the userinfo endpoint to get all the needed claims. I’m open to make this configurable.

1 Like

Just to reply to the last post here, a PR has been raised against ChirpStack to add both the ability to assume email_verified is true, and to make use of UserInfo, or the Id Token configurable.

Yes, I saw this PR and this is great! I’ll look into this shortly (as in days). I’m also planning to port this to ChirpStack v4 :slight_smile: