veinnotnice
veinnotnice3w ago

Login as an existing user to reproduce API bugs

Hi, I have a question regarding debugging and reproducing issues in Zitadel. Sometimes we run into bugs where an API call is only valid within the context of a specific user. As developers, this makes it difficult to reproduce and debug, since we can’t easily simulate the exact user session or context. Is there a way to log in “as” an existing user (impersonation or similar) so we can reproduce these issues in their context? If so, what would be the recommended or secure approach to do this? Thanks in advance!
3 Replies
Ask Inkeep
Ask Inkeep3w ago
Hi @veinnotnice, I'm an AI assistant for ZITADEL. While a team member reviews this question, I'll see if I can find relevant sources for your question. Answer Yes, ZITADEL supports impersonation through the Token Exchange feature, which is exactly what you need for debugging user-specific issues. Prerequisites First, you need to enable impersonation at the instance level. You can check if impersonation is enabled using the security settings API (1) , which returns an enableImpersonation boolean field . To enable Token Exchange (required for impersonation) , you need to set the feature flag using the Feature API (2) :
curl -L -X PUT '<https://$CUSTOM-DOMAIN/v2/features/instance'> \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <IAM_OWNER_TOKEN>' \
--data-raw '{
"oidcTokenExchange": true
}'
curl -L -X PUT '<https://$CUSTOM-DOMAIN/v2/features/instance'> \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <IAM_OWNER_TOKEN>' \
--data-raw '{
"oidcTokenExchange": true
}'
(3) How Impersonation Works ZITADEL implements impersonation through Token Exchange using the actor_token parameter . The actor token represents the identity of the impersonator (you as the developer) , while the subject_token represents the user you want to impersonate . For debugging scenarios, you can use the urn:zitadel:params:oauth:token-type:user_id token type, which allows you to provide the plain ZITADEL user ID in the subject_token along with a valid actor_token from the impersonator . Required Permissions The user performing the impersonation must have the appropriate *_IMPERSONATOR roles assigned (1) . Without these permissions, the token exchange request will be rejected (3) . Security Considerations ZITADEL strongly recommends configuring only confidential clients (using client credentials or JWT assertion) with the Token Exchange grant type . This is because there's significant trust placed in the application - if it possesses a token of an admin user with impersonation permissions, it can obtain tokens for any other user in your instance . This approach gives you the secure debugging capability you need while maintaining proper access controls and audit trails. ​ To learn more, see the sources I considered: [1] Get Security Settings [2] Set Instance Features [3] Impersonation and delegation using Token Exchange ​ Feel free to tag @Ask Inkeep with additional questions.
veinnotnice
veinnotniceOP3w ago
but how i get the token of the person to impersonate
Rajat
Rajat2w ago
hey @veinnotnice thanks for your question and welcome to the server. Here's a good example to do it https://zitadel.com/docs/guides/integrate/token-exchange#impersonation-examples BUT if you are asking for the token to be passed in the request above
curl -L -X PUT '<https://$CUSTOM-DOMAIN/v2/features/instance'> \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <IAM_OWNER_TOKEN>' \
--data-raw '{
"oidcTokenExchange": true
}'
curl -L -X PUT '<https://$CUSTOM-DOMAIN/v2/features/instance'> \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <IAM_OWNER_TOKEN>' \
--data-raw '{
"oidcTokenExchange": true
}'
The token for this request could be obtained by these three methods the simplest is generatiung a PAT for a service user 🙂

Did you find this page helpful?