[alex-yatsenko]

Implements the TODO in UserInfoValidator::getProvisioningStrategy() — the one tracked in #1258, and related to #1255.

Why

UserInfoValidator validates opaque access tokens by calling the provider's userinfo endpoint, but it returned an empty string from getProvisioningStrategy(), and Backend skips provisioning entirely when the strategy is empty:

$provisioningStrategy = $validator->getProvisioningStrategy();
if ($provisioningStrategy) {
    $this->provisionUser($validator->getProvisioningStrategy(), $provider, $tokenUserId, $headerToken, $existingUser);
}

A self-encoded JWT carries its claims, so SelfEncodedTokenProvisioning can decode them. An opaque token carries nothing — the claims only exist behind userinfo. For providers that issue opaque tokens the account still gets created, but group membership and attribute sync never happen, and nothing is logged: the failure is completely silent.

What

• OCA\UserOIDC\User\Provisioning\UserInfoProvisioning — counterpart of SelfEncodedTokenProvisioning, deliberately mirroring it and differing only in where the payload comes from (OIDCService::userinfo() instead of JWT::decode()). It reuses ProvisioningService::provisionUser(), so the group whitelist (groupWhitelistRegex) and all mapping settings keep applying exactly as before — it does not add a way around them.
• UserInfoValidator::getProvisioningStrategy() now returns UserInfoProvisioning::class. If fetching userinfo fails at provisioning time it logs the error and returns null: the very same token was just validated against that endpoint in the validator, so a failure here is a transport failure, not an authorization one.
• Unit tests for both paths (payload reaches ProvisioningService, endpoint failure is handled and does not provision).

Testing

• php -l on all changed files.
• Two new unit tests in tests/unit/User/Provisioning/UserInfoProvisioningTest.php.
• Carried as a downstream patch (and running in production) since August 2026 on Nextcloud 34 with an IdP that issues opaque access tokens: groups and the display name arrive on the bearer path, and the whitelist filter keeps rejecting groups that are not in it.

We are happy to reshape this to whatever the maintainers prefer (e.g. sharing code with SelfEncodedTokenProvisioning, or wiring the strategy differently) — the point is that the bearer path should provision like the interactive one does.

Refs #1258
Refs #1255