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.
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, …
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.
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.
