Replies: 3 comments 1 reply
-
I can think of an additional question, which we already have added as an issue: |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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:
ORG_END_USER_IMPERSONATER
to become such a user and suddenly have unintended management powers over another organization.subject_token
? Self signed JWTs are a good alternative, but does this really add security? The application might already be authenticated.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?resource
request parameter. We currently do not implement this. Would this be a desired feature?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 therefresh_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!
Beta Was this translation helpful? Give feedback.
All reactions