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