[OID4VCI] Impersonation possible in OID4VCI credential creation endpoint

Before reporting an issue

• I have read and understood the above terms for submitting issues, and I understand that my issue may be closed without action if I do not follow them.

Area

oid4vc

Describe the bug

There is the endpoint for creating OID4VCI credential offer at the URL like https://as.keycloak-fapi.org:8443/realms/test/protocol/oid4vc/credential-offer-uri . The endpoint is required to be secured by Authorization: Bearer header when valid access token needs to be provided. Let's assume the token was granted to user john and client foo.

The credential offer endpoint mentioned above also has parameters like client_id and username as of today, which allows to pass custom client and user, for whose the credential offer would be created. Note those can be different than the user and client for whom the token was granted.

The credential offer can be later easily obtained and then used for pre-authorized code grant to obtain access-token granted to the client specified by client_id parameter and user specified by username parameter.

The token returned from pre-authorized grant is supposed to be used in the credential-request, however it is regular Keycloak access token and can be used for other services as well.

This in fact allows user and client impersonation and escalation of privileges and can be considered as quite important security issue.

There are only those restrictions in place:

• The user john, who is subject of the passed access token needs to be in role credential-offer-create . But that is all. Assuming that user is in this role, user can obtain access-token from pre-authorization grant for any realm user, like for example for user admin (As long as he use username=admin in credential-offer creation endpoint) -> KO
• The client foo needs to have OID4VCI enabled. And that is sufficient to obtain access-token issued to any other client bar specified by client_id parameter of credential-offer endpoint as long as bar client has client scope to the specific OID4VCI credential requested in the credential-offer URL above. There is not any trust relationship needed to be set between clients -> KO

Version

nightly (from 2025-12-09), (version from 2025-12-08 uses parameter user_id instead of username but otherwise it is pretty much same

Regression

• The issue is a regression

Expected behavior

I would expect that:

• Impersonating users should not be possible at all. Only the user, who the original access-token was granted (like user john from example above) should be capable of creating credential-offer

• Impersonating clients is more tricky. As per my understanding, it may be needed for the OID4VC use-case as foo can be a regular OIDC client, when the other client bar might be an OID4VC wallet. However at the same time, it should not be allowed for the client foo to create access-token granted to any other client bar without any further trust among clients (The fact that client bar has client scope of OID4VCI credential is not sufficient protection IMO...). IMO there should be at least same restrictions like applied for the regular standard token-exchange . But that is very tricky as currently supported standard token-exchange allows to issue token for client bar just if bar is confidential client and token-exchange request is authenticated with it's credentials. But in case of normal OID4VCI flow, the bar might be OID4VCI wallet and this may be client without client credentials (Examples of pre-authorized grant in the OID4VCI specification don't use client credentials: https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-request-credential-issuance ).

Since client impersonation typically may need to be done in regular OID4VCI flow (as client foo might be a web client, but client bar might need to be a wallet, which doesn't support regular browser authentication), however security is a concern, it is a question if credential-creation endpoint is a good way to approach the problem of credential-offer creation at all.... Can we perhaps use something different like required-action? Started discussion regarding this: #44764

Actual behavior

There is user impersonation and client impersonation possible. See description and expected behaviour sections.

How to Reproduce?

See description and expected behaviour sections.

Anything else?

No response