FHuh that is weird 
FWe alwasy include the projectID and all ApplicationID of the project in the aud claim by default
FActually actions is one of the things we will start improve soon
FWe know that the devex is not good
FATM I think the constrain is that you can change the content of the aud claim with an action.
Correct @livio ?
If proxmox has a problem with multiple audiences would be weird
Correct @livio ?
If proxmox has a problem with multiple audiences would be weird
FFYeah the audiences thing popped up in a rust lib recently as well.
We are not yet sure how to make this super easy to "change" since it has a security impact to it.
FOh well that is not cool 
Hm I think the only system that would be affected by removing the projectID would be zitadel itself.
I am not sure that would solve the problem though. You could pass the projectID to the client as trusted audiende or am I missing something?
Hm I think the only system that would be affected by removing the projectID would be zitadel itself.
I am not sure that would solve the problem though. You could pass the projectID to the client as trusted audiende or am I missing something?
FHm how does one pass additional aud to the lib?
At least looking at their description it sounds like that "should" be possible.
At least looking at their description it sounds like that "should" be possible.
FHm not an easy one from our end.
I can poke around proxmox, maybe i find something
I can poke around proxmox, maybe i find something
SJust run into this when trying to set this up on my home lab, and found https://bugzilla.proxmox.com/show_bug.cgi?id=5076
unpleasant times
unpleasant times
Fhttps://github.com/zitadel/zitadel/pull/8178
At least the clientID part should be resolved soon, I guess in 2.56
At least the clientID part should be resolved soon, I guess in 2.56
GitHub
Which Problems Are Solved
The client ID for OIDC applications has an @ in it, which is not allowed in some 3rd-party systems (such as AWS).
How the Problems Are Solved
Per @fforootd and @hifabienne...
The client ID for OIDC applications has an @ in it, which is not allowed in some 3rd-party systems (such as AWS).
How the Problems Are Solved
Per @fforootd and @hifabienne...
FThe second AUD is the projectID that contains your APP
I think the next thing that need solving is that either we need to change how we work with AUD or proxmox should change the way how they check the AUD claim
I think the next thing that need solving is that either we need to change how we work with AUD or proxmox should change the way how they check the AUD claim
SFThe issue is that the aud claim is not super well specd. https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3
IETF Datatracker
JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity ...
Fhm, I guess it appended it to the client_id then
Fhow did you configure exactly for that?
Fah yeah that breaks the authorization flow
FActually I only see two options here:
1) We allow to modify the AUD claim in zitadel
2) Proxmox allows to "ignore" other ids
1) We allow to modify the AUD claim in zitadel
2) Proxmox allows to "ignore" other ids
FI think authentik only has one audience and that is why it is working
FWe would be open for a PR that introduces a setting or scope that only introduces one audience to a token.