[feature] OIDC: support identity providers without name in id_token

[LittleFox94]

While trying to configure GTS to use my personal Gitlab as OIDC provider, it failed authenticating me since Gitlab does not set a Name claim in the id_token. For now I patched my local code to use the local part of the EMail claim instead, but this is only a hacky workaround.

Is proper support for such IDPs wanted? I guess some kind of IDP interface to handle such quirks would be a good way to tackle this, users then configuring which kind of IDP it is (Generic, Gitlab, ..) and the Gitlab implementation would make an API call to get the name.

[tsmethurst]

Is proper support for such IDPs wanted

Yes :) I got OIDC in as quickly as possible a while ago because I wanted to be able to use Dex as an OIDC provider, but after getting it working I didn't test it with other providers.

I think one solution here--rather than having separate interfaces per-provider--would be to allow more granular configuration under the oidc section, so that instance admins can specify where certain values should be selected from. I know I've seen this pattern elsewhere--I think in Synapse?

[LittleFox94]

Problem for Gitlab is, it does not provide the name in the id_token at all - stating you have to call an API to get it, as written in this doc below the table:
https://docs.gitlab.com/ee/integration/openid_connect_provider.html#shared-information

I've seen something like a common base class and implementations for different provider quirks (yeah, for me they are quirks - maybe I'll go fix gitlab in this regard) and let the user choose one of that quite often - like in Gitlab's Omniauth

[LittleFox94]

We could add a config URL+jsonpath to retrieve name from though, this isn't completely generic but might work in enough cases for now ™️

[LittleFox94]

Just looked at the OIDC spec to find if name is a required claim and found this info about claims "They can be requested to be returned either in the UserInfo Response, per Section 5.3.2, or in the ID Token, per Section 2.". Looking at Section 5.3.2, I learned the API route Gitlab wants applications to use is actually one of the valid ways in OIDC - the route where to retrieve that is given in the discovery document.

I think I can build something to retrieve the additional claims from that route when some are missing :)

[tsmethurst]

Closed by accident!