Deny M2M access tokens at the IdP when no matching role/grant exists
❌Unsolved❓Question➕Feature Request
Hey 
Question about M2M / service accounts and roles.
When a service account authenticates via private-key JWT (jwt-bearer), ZITADEL always hands out an access token — even if that service account has no role/authorization on the project I target with
The roles claim is just omitted, but the token is still issued.
I dug through the docs + source and it looks like there's no way to make ZITADEL refuse to issue the token in that case:
The project "Only authorized users can authenticate" check only applies to the interactive login flow, not M2M tokens that reference the project via
The
Assumed using AI (my fellow Opus-Coworker):
- The token-creation hooks (Actions v1 complement-token, Actions v2 PreAccessToken/PreUserinfo) are add-only — they can set claims but can't deny.
- Actions v2 Request executions can return a 4xx, but they only cover the gRPC API, not the /oauth/v2/token endpoint.
So my questions:
Is that understanding correct — no built-in way to block M2M token issuance based on project roles?
Is anything like that planned (e.g. a deny option in PreAccessToken, or a project setting that also gates the M2M flow)?
For context - I assume the intended pattern is to enforce roles at the resource server via introspection/JWT — I'm just after an optional fail-closed guardrail at the IdP for defense-in-depth.
Thanks!
Question about M2M / service accounts and roles.When a service account authenticates via private-key JWT (jwt-bearer), ZITADEL always hands out an access token — even if that service account has no role/authorization on the project I target with
urn:zitadel:iam:org:project:id:{projectId}:audurn:zitadel:iam:org:project:id:{projectId}:aud. The roles claim is just omitted, but the token is still issued.
I dug through the docs + source and it looks like there's no way to make ZITADEL refuse to issue the token in that case:
The project "Only authorized users can authenticate" check only applies to the interactive login flow, not M2M tokens that reference the project via
:aud:aud .The
:aud:aud scope just adds the project id to aud with no authz check.Assumed using AI (my fellow Opus-Coworker):
- The token-creation hooks (Actions v1 complement-token, Actions v2 PreAccessToken/PreUserinfo) are add-only — they can set claims but can't deny.
- Actions v2 Request executions can return a 4xx, but they only cover the gRPC API, not the /oauth/v2/token endpoint.
So my questions:
Is that understanding correct — no built-in way to block M2M token issuance based on project roles?
Is anything like that planned (e.g. a deny option in PreAccessToken, or a project setting that also gates the M2M flow)?
For context - I assume the intended pattern is to enforce roles at the resource server via introspection/JWT — I'm just after an optional fail-closed guardrail at the IdP for defense-in-depth.
Thanks!
