Description
Description
This issue is a follow-up of #40134 . It is about support for exchange external-internal tokens when external token is the token issued by OIDCIdentityProvider .
Possible approach is to:
-
Add support for "introspection endpoint" into the OIDC Identity provider configuration and probably also to the response from "Discovery endpoint" (Well-known endpoint).
-
External token could be considered as authorized for external-internal token exchange if introspection response could b contains either:
client_idclaim with client ID of the client configured as the client in the IDPaudclaim with client ID of the client configured as the client in the IDPaudclaim with issuer or token-endpoint of the KEycloak server.
In shortcut: In the case of IDP, the Keycloak acts as a client (OIDC RP) . The "client ID" of the client configured in the Keycloak IDP represents the Keycloak on the IDP side. Hence in the introspection-response OR in the JWT token (in case that introspection is not used), we should verify that this client (which represents Keycloak) is used as audience or token was issued to it. This means that Keycloak should be considered as valid audience for external-internal token exchange and it is not just some random external token issued to any random IDP client.
The last bullet point (when Keycloak issuer or tokenEndpoint URL is directly mentioned as token audience) also means that Keycloak is valid audience and hence token should be valid for external-internal token exchange (Partially aligned with https://datatracker.ietf.org/doc/html/rfc7523#section-3 - point 3).
More details in the google doc .