Feedback on Token Exchange and impersonation

[muhlemmer]

This discussion is opened to evaluate the new Token Exchange feature, available on main and starting from zitadel v2.49. As RFC 8693, OAuth 2.0 Token Exchange is a very permissive standard, lots of assumptions have to be made by us as implementer. Some of these assumptions may not work out well for our users.
We hope to gather some feedback on how to improve Token Exchange, possible bugs or misunderstandings and features you like to add.

Some questions I already have:

1. Impersonated tokens cannot be used against the zitadel API yet. We choose this solutions for now, as there is no clear way to distinguish between an end-user and admin user. A end-user in one org may have manager roles on another. If organization grants are configured in certain ways it would be possible for a ORG_END_USER_IMPERSONATER to become such a user and suddenly have unintended management powers over another organization.
   1. Are there users that would need to call zitadel APIs with an impersonated token and therefore need this feature?
   2. Any suggestions on how to implement this securely?
2. Do we really want to allow plain user IDs in the subject_token? Self signed JWTs are a good alternative, but does this really add security? The application might already be authenticated.
3. Currently ZITADEL doesn't care if you enable the token exchange grant for public clients and puts the responsibility of that choice at the administrator. Do we want to keep it that way?
4. We accept self-signed JWTs as subject_token, but only applications with JWT client assertion authentication can add keys to zitadel. Should we add the ability to add keys to all apps, regardless of auth method? Or should we show the key dialogue in console once the token exchange grant is enabled?
5. Exchanging session tokens to OIDC tokens might be a desirable feature. This would allow getting access tokens without the need of the redirect-callback flow.
6. The token exchange RFC is linked to RFC 8707 Resource Indicators for OAuth 2.0 for the resource request parameter. We currently do not implement this. Would this be a desired feature?
7. When requesting a JWT token type and offline_access for a refresh token one gets an access token as JWT and a refresh token. If the application is configured for opaque tokens and the refresh_token grant is used, the new token will be opaque again. Should we instead store the token type in the refresh token event, so that we will always return the same type of token after an exchange?

Any other suggestions are welcome and open to discussion!

[hifabienne]

I can think of an additional question, which we already have added as an issue:
Should we notify a user when it gets impersonated? #7257
Or should we implement something like a consent? where a user has to give a consent on the impersonation?

[muhlemmer]

Should we notify a user when it gets impersonated? #7257

Yes. Tho the user story says the admin gets notified. I already replied there.

Or should we implement something like a consent?

As the token exchange request is send by the client using already existing tokens, we can't ask consent. There is no auth request redirect flow through zitadel, so we can't serve a consent page. The app most take care of that itself.

Off course, zitadel console or login could be a token exchange client and take care of the consent part there. For example, we could start by allowing session tokens for token exchange and the new login could call the TE grant for impersonation, instead of doing a redirect over the token endpoint.

[gpoulin]

5 could be useful to us. We are contemplating use-cases where we would do custom authentication using the session API and then simulate the OIDC flow from our backend to retrieve an access_token/refresh_token. If token exchange was supporting that, it would be way easier.

[cghislai]

One use case would be guest sessions. We could create short-lived guest sessions, providing user agent information and other metadata, then issue tokens for the guest users without redirect to idp, and without creating specific zitadel users for them.

[gpoulin]

As for 1., I feel the issue come from the limit of the authz model of Zitadel. It's only possible to give grant at the org level, you can't for example give permission for a user to impersonate only a subgroup of user. Having some kind of integration with OPA/OpenFGA/Ory Keto could be interesting.

[G0maa]

Hello, I noticed that the example, has all the projects in the same organization, therefore I'm limited to having audience that are already inside the organization.

My use-case: two separate Zitadel instances, say CRM Zitadel and Client Zitadel, I should authenticate through Client Zitadel and exchange token with CRM Zitadel.

[gpoulin]

That use case would be handled with #7211 as one of the Zitadel instance would be an external IdP.

[G0maa]

@gpoulin Do we have an alternative/workaround till #7211 gets implemented?

[G0maa]

Hello, can a service user be used in impersonation?

See this example, the authentication header includes clientId:clientSecret of Portal app, can clientId:clientSecret of service user be used instead?

i.e. the impersonator is a machine, not a human user.

[G0maa]

Weirdly, I got opaque access token using clientId & secretId of service user.

Then to do the impersonation I created a dummy app and used clientId & secretId of it in the header (same as the example request).

Am I missing something or this feels a bit redundant?