Previously, we would always hit the Userinfo endpoint when performing OIDC logins, and would merge the claims returned by UserInfo with the claims from the ID token.

Unfortunately, certain identity providers require different URL parameters when requesting UserInfo versus requesting an ID token. For example, ADFS requires specifying the relying party identifier as theresource parameter when requesting an ID token, but requiresresource=urn:microsoft:userinfo when requesting the resource parameter.

As far as I can tell, this is aproposed standard (RFC8707) but I'm not sure it has been ratified yet. To make matters more complicated, the proposed standard also says that

Multiple resource parameters MAY be used to indicate that the requested token is intended
to be used at multiple resources.

So, we can't guarantee that simply specifying multiple resources in the resource parameter will work for all IDPs.

To work around this, I propose changing the OIDC login logic such that weonly request UserInfo if we lack the required claims from the ID token itself. This allows folks using identity providers like ADFS to stuff everything they need into the ID Token withallatclaims and not have to worry about UserInfo.

Update: to minimise the level of magic in the product, I elected instead to add an extra optionOIDC_IGNORE_USERINFO. This will allow an operator to cause Coder tonever hit the UserInfo endpoint of the upstream identity provider, and instead take all information from the ID token. This also eliminates the possibility of introducing breaking behaviour into the product in the case where the upstream OIDC provider returns inconsistent information from the ID token versus from the UserInfo endpoint.

Also, I noted that the environment variableOIDC_GROUP_MAPPING was missing theCODER_ prefix, so updated that for consistency. This is technically a breaking change.

Still TODO:

• Update documentation