We have configured OIDC as authentication mechanism for Harbor. Also, we have several other applications that are consuming the Harbor API.

With OIDC enabled, authentication against the Harbor API is only possible with a valid OpenID Connect ID Token as Bearer Authentication header.

As far as I understood the OpenID Connect specification, the ID Token should not be used to grant access to ressources - like the Harbor API. The Access Token is meant for that.

Harbor validates the ID Token for API requests using the go-oidc library internally. This library has SkipClientIDCheck enabled by default (which is totally fine for ID Tokens).

This leads to the fact, that Harbor does not allow access to the API with valid tokens, issued by other clients from the same issuer. You are forced to use Harbors OIDC client credentials in other applications to be able to interact with the Harbor API.

Expected behavior:
I would have expected that Harbor uses an Access Token to grant access to API resources rather than the ID Token. Then this should not be an issue, right?

I can see two possible solutions:

• Change authorization of Harbor API to use Access Tokens instead of ID Tokens
• Allow setting the SkipClientIDCheck via Harbor Configuration (leads to a possible security leak)

Steps to reproduce the problem:

• Enable OIDC auth in Harbor with credentials for ClientA
• Fetch an ID Token from the same Issuer with client credentials for ClientB
• Make an API call against the Harbor API with that ID Token issued by ClientB

Harbor will fail with failed to verify token: oidc: expected audience ClientA got ClientB

Versions:
Please specify the versions of following systems.

• harbor version: [v2.1.3]
• docker engine version: [19.03.13]
• docker-compose version: [1.24.0]