If the v2 standard profile is enabled alone (nor federated, neither impersonation) this will manage all the requests even if they contains parameters for the other requests. Some of the possible combinations will return a token (for example for the client instead of the external IdP, or for the same user instead of the impersonated user). What do you think about checking for the presence of those parameters too in this provider? Something like:

String requestedIssuer = context.getFormParams().getFirst(OAuth2Constants.REQUESTED_ISSUER);
String requestedSubject = context.getFormParams().getFirst(OAuth2Constants.REQUESTED_SUBJECT);
return requestedIssuer == null && requestedSubject == null;

Federated external to internal will fail because of signature, but we can check it too if you like.

Good point! I was thinking exactly about that before as well. In the end, I've added the check directly to the tokenExchange() method itself in case that those parameters are present: https://github.com/keycloak/keycloak/pull/36407/files#diff-d6af3e4db00e3f2e9ce210ddbd14152aab83f0dd584411ae918110e9e1912c5aR91-R103 .

My thinking was this: Assuming that only "standard" is enabled and "federated" is disabled and "impersonation" is also disabled. And customer uses for example requested_subject parameter. Then:

• In case the check is in the tokenExchange() method, customer will see the error like Parameter requested_subject is not supported . When he sent this error to us, we will see immediately from this error message what is going on. We will see the fact that he enabled just "standard" and used parameter requested_subject, which is not allowed for "standard" .

• In case that check would be in the supports() method like you suggested, he will see error No token exchange provider available . When he send this error to us, it is slightly less clear what is going on (we will need to ask for the parameters, startup command for enabled features etc).

So that is the only reason for adding to tokenExchange() :-) But maybe it has some other disadvantages... Like conceptually it is maybe better to have it in supports() ? Not sure...

If you prefer, I can move to supports() . Not strong on this... Just added my points

Ah! Yes, I didn't detect the tokenExchange was doing those checks. It's OK, I just wanted to return an error and this solution is even better because it directly says that the option is not supported.

Although the version is 2 for the new token exchange features, the name is different, so you can start the server like this for example:

./kc.sh start-dev --features token-exchange,token-exchange-standard,token-exchange-federated,admin-fine-grained-authz

I'm not saying this is an error but at least we can increase the order of the new v2 standard factory to 1 to be tried before the v1 version.

The isAvailable can also be used to avoid the two features are enabled at the same time

@rmartinc Thanks for pointing that. I've updated the PR (added additional commit just for the easier review what changed).

I've used the approach with order() . The approach with isAvailable in profile might be possible too, but will probably require some updates in the Profile class itself (due the isAvailable is called before Profile is initialized, so it is not easily possible to ask for other enabled features). So rather went the easier path for now :-)