Allow configuring valid audiences

[butonic]

When an OpenID Connect identity provider issues access tokens for multiple applications, an access token for e.g. Immich could be used for OpenCloud. The

From https://www.rfc-editor.org/info/rfc7519/#section-4.1.3

4.1.3.  "aud" (Audience) Claim

   The "aud" (audience) claim identifies the recipients that the JWT is
   intended for.  Each principal intended to process the JWT MUST
   identify itself with a value in the audience claim.  If the principal
   processing the claim does not identify itself with a value in the
   "aud" claim when this claim is present, then the JWT MUST be
   rejected.  In the general case, the "aud" value is an array of case-
   sensitive strings, each containing a StringOrURI value.  In the
   special case when the JWT has one audience, the "aud" value MAY be a
   single case-sensitive string containing a StringOrURI value.  The
   interpretation of audience values is generally application specific.
   Use of this claim is OPTIONAL.

Currently, OpenCloud does not verify this "aud" claim. We should create an env var PROXY_OIDC_AUDIENCES or OIDC_AUDIENCES to configure an optional list of valid audiences. Default is empty, since Use of this claim is OPTIONAL.

cc @dragotin @rhafer @pbleser-oc

[pbleser-oc]

It's not actually optional, as of RFC 9068 - JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens:

• in 2.2. Data Structure: aud is required

REQUIRED - as defined in Section 4.1.3 of [RFC7519]. See Section 3 for indications on how an authorization server should determine the value of "aud" depending on the request.

• in 4. Validating JWT Access Tokens:

The resource server MUST validate that the "aud" claim contains a resource indicator value corresponding to an identifier the resource server expects for itself. The JWT access token MUST be rejected if "aud" does not contain a resource indicator of the current resource server as a valid audience.

But we might choose to have it empty by default for a smoother user experience, to prevent existing setups that are working as of now from suddenly having all their token authentication being broken because we then require a certain aud value to be present in the tokens. Especially since that is something that admins must configure in their IdP of choice (e.g. Keycloak), and even something that not all IdP might be able to do.

And then make announcements in the release notes and wait for a major release to change the default to aud matching being required, instead, e.g. with a default value of opencloud. It should probably be handled as a breaking change, since it will require admin intervention in most scenarios, either to configure the IdP to add an aud claim, or to configure OpenCloud to ignore aud validation.

[butonic]

maybe log a warning when the env var is empty?

[zerox80]

It's not actually optional, as of RFC 9068 - JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens:

• in 2.2. Data Structure: aud is required

REQUIRED - as defined in Section 4.1.3 of [RFC7519]. See Section 3 for indications on how an authorization server should determine the value of "aud" depending on the request.

• in 4. Validating JWT Access Tokens:

The resource server MUST validate that the "aud" claim contains a resource indicator value corresponding to an identifier the resource server expects for itself. The JWT access token MUST be rejected if "aud" does not contain a resource indicator of the current resource server as a valid audience.

But we might choose to have it empty by default for a smoother user experience, to prevent existing setups that are working as of now from suddenly having all their token authentication being broken because we then require a certain aud value to be present in the tokens. Especially since that is something that admins must configure in their IdP of choice (e.g. Keycloak), and even something that not all IdP might be able to do.

And then make announcements in the release notes and wait for a major release to change the default to aud matching being required, instead, e.g. with a default value of opencloud. It should probably be handled as a breaking change, since it will require admin intervention in most scenarios, either to configure the IdP to add an aud claim, or to configure OpenCloud to ignore aud validation.

I think making the aud validation optional is a good solution. However, I think it is important to make this very explicit in the documentation/configuration so that it cannot easily be overlooked.

For improved security, we should clearly recommend configuring and enabling aud validation whenever possible.