Using Authenticated User Tokens for Zitadel API Calls Best Practices

Hi,

I have a question regarding reusing authenticated user's access token to perform some actions (not Zitadel actions, e.g. listing organization users, updating a user's role, updating a user's own avatar...), instead of relying on a service user, is it possible to use the logged in user's token to make actions?
What is the best practice around this, I had a chat with AI (ChatGPT) for reference: https://chatgpt.com/share/68c3128d-f9bc-8000-b1d4-368d3780dcee

ChatGPT

ChatGPT - User roles with Zitadel

A conversational AI system that listens, learns, and challenges

Ask Inkeep•9/11/25, 6:23 PM

Hi @Joebeurg, 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.

Ask Inkeep•9/11/25, 6:23 PM

Answer

I wasn't able to find a direct answer, here are some relevant sources:

Authenticate service users and client applications : This covers service users which represent non-human entities for secure machine-to-machine communication and are used to access ZITADEL's APIs.
Configure personal access token authentication for service users : This demonstrates how to use PAT tokens to call ZITADEL APIs, but specifically for service users rather than authenticated human users.

Ask Inkeep•9/11/25, 6:23 PM

Feel free to tag @Ask Inkeep with additional questions.

AAsk Inkeep Empty message

Ask InkeepAPP•9/11/25, 6:24 PM

Got it. Tagging @Rajat for additional help.

AAsk Inkeep Empty message

Ask InkeepAPP•9/13/25, 9:19 AM

Got it. Tagging @Rajat for additional help.

Tegar•9/14/25, 4:48 AM

I'm also looking for this.

Currently when I use the user JWT to call zitadel API like https://auth.portierlabs.com/management/v1/users/grants/_searchhttps://auth.portierlabs.com/management/v1/users/grants/_search, it will return like this

{
    "code": 16,
    "message": "Errors.Token.Invalid (AUTH-7fs1e)",
    "details": [
        {
            "@type": "type.googleapis.com/zitadel.v1.ErrorDetail",
            "id": "AUTH-7fs1e",
            "message": "Errors.Token.Invalid"
        }
    ]
}

{
    "code": 16,
    "message": "Errors.Token.Invalid (AUTH-7fs1e)",
    "details": [
        {
            "@type": "type.googleapis.com/zitadel.v1.ErrorDetail",
            "id": "AUTH-7fs1e",
            "message": "Errors.Token.Invalid"
        }
    ]
}

With same user, inspect network and see the token used in Zitadel console is different. Probably when login, there is some scope that I need to add, but not sure which one https://zitadel.com/docs/apis/openidoauth/scopes

ZITADEL Docs

ZITADEL supports the usage of scopes as way of requesting information from the IAM and also instruct ZITADEL to do certain operations.

TTegar I'm also looking for this. Currently when I use the user JWT to call zitadel ...

JoebeurgOP•9/14/25, 9:54 AM

I haven't tested yet the use case as I am concerned about performance and best practices.
I have in my frontend added the

urn:zitadel:iam:user:resourceowner

urn:zitadel:iam:user:resourceowner

So the Org ID is always included in the auth header, not sure if this helps, but planning to work on this use case next week.
If you have a setup that uses the logged user's context/token, can you please share?

JJoebeurg I haven't tested yet the use case as I am concerned about performance and best p...

Rajat•9/15/25, 10:29 AM

hey @Joebeurg @Tegar no, a user access-token issued for your application (audaud = your client-id) is not accepted by the mgmt/admin endpoints,they require the reserved audience which is urn:zitadel:iam:org:project🆔zitadel:audurn:zitadel:iam:org:project🆔zitadel:aud(more about ie here)

TTegar I'm also looking for this. Currently when I use the user JWT to call zitadel ...

Rajat•9/15/25, 10:31 AM

I do not know what user did you use to make this request, but either you missed the scope that I said above OR usong a wrong token altogether.
There is no scope you can add to the front-end token to turn it into a mgm token, the audience check is hard-coded on the server side.

RRajat hey @Joebeurg @Tegar no, a user access-token issued for your application (`aud` ...

JoebeurgOP•9/15/25, 10:40 AM

Hey Rajat, thanks for your reply.
So that means the service user will be the one showing up in the audit if we are leveraging a custom business logic from a backend.
Just to confirm if an org manager or user made changes directly in the console, the auth checks and audit will be based on that human, while if the console has been blocked from public access the only option (using GO SDK in my case) the service user will be held accountable for those actions with additional custom checks

JJoebeurg Hey Rajat, thanks for your reply. So that means the service user will be the on...

Rajat•9/15/25, 10:45 AM

hey @Joebeurg exactly!
When an org manager or user makes changes directly via the ZITADEL Console, audit records and authorization checks are tied to that human user
Same call coming through your backend + GO SDK (service-user token) → audit log shows service-user-id.

RRajat hey @Joebeurg exactly! When an org manager or user makes changes directly via th...

JoebeurgOP•9/15/25, 10:46 AM

Got it thank you

RRajat I do not know what user did you use to make this request, but either you missed ...

Tegar•9/15/25, 10:50 AM

I use token from pkce app, so yes it's from frontend.

With that said, that's mean I can't create a custom UI for my user add a user, give him a role and list all user in his organization without backend proxy (and then the audit log will be service user instead of the user itself), even though my user has the permission for that.

TTegar I use token from pkce app, so yes it's from frontend. With that said, that's me...

Rajat•9/15/25, 10:54 AM

you Exchange the front-end token for a service-user token + actor header via token-exchange (impersonation)
you can check it here

Gigi the Giraffe (Zitadel)•9/15/25, 1:23 PM

Looks like you just helped out another community member! Thanks for being so helpful @1346540274674827395! You're now one step closer to leveling up—keep up the amazing peer support!