@coadler what do you think about this? Feels a bit half baked, but should give a route to provide more context on the claims for any given user. We have had a lot of group/role sync debug sessions that were difficult.

From my perspective, this is great for debugging group sync. I know within a workspace you can sometimes debug the token but I found, even with OIDC, sometimes its not a JWT and you can't hit the userinfo endpoint post-login. Idk if this is because some providers have a weird exchange going on but this is a reliable and quick solution to understand what is being passed from the provider

From my perspective, this is great for debugging group sync. I know within a workspace you can sometimes debug the token but I found, even with OIDC, sometimes its not a JWT and you can't hit the userinfo endpoint post-login. Idk if this is because some providers have a weird exchange going on but this is a reliable and quick solution to understand what is being passed from the provider

Currently only owners can hit this, it only works if the user does authenticate. I am storing the original claims used for the group/user sync.

Is there anything this stores that we don't output in the logs? Or does it just make the claims easier to access

Is there anything this stores that we don't output in the logs? Or does it just make the claims easier to access

Yes we only log the claim fields. This outputs the claim values.

I assumed we only logged the claim fieldnames and not the values for some secret reasons or something?

Is there anything this stores that we don't output in the logs? Or does it just make the claims easier to access

We don't output the claim values through the logs, just the names. We output the specific values for the OIDCS_GROUPS_FIELD if it is an array, but not if it is a string. We found some providers will send the value as a string if there is 1 value but then an array if it is several. Or some provider send a comma-seperated string. Since our product doesn't support all these formats, it's a bit of a chicken-and-egg problem: what is the format then if/how do we support it or can it be mapped on the IDP side or the Coder side.

This is the current issue we're running into

I assumed we only logged the claim fieldnames and not the values for some secret reasons or something?

I originally had it log fields but I think it was removed later on https://github.com/coder/coder/pull/6922/files#diff-0bdad5dd6f860b794a5f97ea3f7be5a74a7ad2a5aadcfcf02e67a63efd4222fdL591

If we're going to make this info exposed to owners either way I think it would be easiest if we just logged them since the security implications seem similar, unless accessing them this way unblocks any customers.

NOTE: we were previously logging all of the userinfo claims here; this could contain sensitive user information. I modified this to instead log the claim fields, and which of these claim fields are an empty string.

This was the note. Logs are more easily "dumped" somewhere imo. I figured a route that requires a human to hit won't accidentally be dumped anywhere.