docs: correct what the openid-connect audience key does to ID tokens [10.16]

[oc-tmueller]

The audience paragraph added in #41846 says this about ID tokens:

…stops being accepted. So do ID tokens, but only where the configured value differs from the client-id, since an ID token's aud is the client-id by definition.

That makes this key the thing that decides ID tokens. It is not, and has not been since the openidconnect app started requiring a token that labels its own type to label itself an access token.

• Where the provider puts that label in the payload — Keycloak's typ of ID, AWS Cognito's token_use of id — an ID token is refused whatever this key is set to, including not set at all. The check runs at the head of both the JWT and the introspection branch of verifyToken(), before the audience is looked at, and reads nothing from the configuration.
• Where the provider puts no type claim in the payload, which is Entra ID and ADFS, the old sentence reached the right outcome for the wrong reason: what accepts the token is the client-id being an accepted audience, so setting this key to anything else rejects it as a side effect rather than as its purpose.

Both halves now say so, in a paragraph of their own instead of wedged into the one about binding a token to a resource, which is a different property.

Two things a review of this change turned up, fixed in the same commit:

• The sentence the paragraph builds on still described the client-naming fallback as accepting a token whose azp, appid or client_id names ownCloud. The app consults only the most authoritative of those three that the token carries, so a token with an honest azp naming another client plus a mapped client_id naming ownCloud is refused — the opposite of what the docs promised.
• The app README closes the topic with advice this file omitted, for the case where neither branch helps: treat ID tokens as credentials.

Sequencing — why this is a draft

The behaviour described here ships in openidconnect 2.3.5, the ownCloud 10 line's release, which is not out: it lives in owncloud/openidconnect#368, the backport of owncloud/openidconnect#374, still under review. This must not be marked ready before that lands, or the parameter reference documents a release that behaves differently.

The matching regeneration of the admin manual is owncloud/docs.owncloud.com#137 (also a draft). That one has to merge before or with this, because the docs repo's config-in-sync job regenerates the page from core's branch HEAD and is not path-filtered — merging here first turns every subsequent docs PR red until the regenerated page lands.

Master counterpart: #41858. Discussed on owncloud/openidconnect#374.