A commercial SSO solution which supports OIDC returns the following JSON on the userinfo_endpoint URL:

{
  "id": "[REDACTED]",
  "name": "vitor.barth",
  "profilePictureUrl": "[REDACTED]",
  "email": "vitor.barth@[REDACTED] ",
  "sub": "[REDACTED]",
  "verified": true,
  "phoneNumber": null,
  "provider": "oidc",
  "mfaEnrolled": false,
  "metadata": null,
  "vendorMetadata": null,
  "roles": [
    {
      "id": "[REDACTED]",
      "vendorId": "[REDACTED]",
      "key": "registry",
      "name": "Registry",
      "description": null,
      "isDefault": false,
      "firstUserRole": false,
      "createdAt": "2023-12-22T19:59:23.000Z",
      "updatedAt": "2023-12-22T19:59:23.000Z",
      "permissions": [],
      "level": 0
    }
  ],
  "permissions": [],
  "createdAt": "2023-12-22T19:54:15.000Z",
  "lastLogin": "2023-12-22T23:27:11.000Z",
  "isLocked": false,
  "managedBy": "[REDACTED]"
}

where the roles tag indicates the groups which this user belongs.

However, Harbor expects the Group list to be an String Map, and throws the following error

Dec 23 00:58:32 registry core[22271]: 2023-12-23T00:58:32Z [WARNING] [/pkg/oidc/helper.go:401]: Element in group list is not string: map[createdAt:2023-12-22T19:59:23.000Z description:<nil> firstUserRole:false id:[REDACTED] isDefault:false key:registry level:0 name:Registry permissions:[] updatedAt:2023-12-22T19:59:23.000Z vendorId:[REDACTED]]

because it could not decode the group claim correctly, since it is actually a JSON.

Cause

The problem arises when /pkg/oidc/helper.go does

if remote.hasGroupClaim {
		res.Groups = remote.Groups
		res.AdminGroupMember = remote.AdminGroupMember
		res.hasGroupClaim = true
	} 

so it forces the mapper to use the profile JSON returned by the provider if it has group claims. However, since the ID Token has the correct structure, it could also be used if the mapper fails as a fallback (because the user is valid).

This can be verified since when this conditional is deleted, the groups are correctly mapped using the ID Token.

Proposed Solution

When the remote.Groups fails to be parsed but the server returned the user correctly, it should fallback to the local.Groups before giving up parsing.

After a proper way of solving it is set, I can gladly implement it.