JWT Profile Grant: return id_token if openid scope is set

[livio-a]

Although JWT Profile Authorization is an Oauth2-only extension (there is no mention in the OIDC standard) it would be useful if we return an ID Token is the requested scope is set to openid. This is to have a compatible result with the rest of the toolkit, regardless of the method of authentication flow that is chosen.

Acceptance criteria

• When scope openid is set, an ID Token to be returned to the client on JWT Profile Grant.

[akaegi]

Furthermore, it would be desirable to have a refresh_token returned as well if scope offline_access is given.

Reason: This would allow to use the same token refresh mechanism (as is used for "auth code" grant type) in a client application.

[muhlemmer]

@akaegi we did discuss this. But as the JWT profile grant already works without user interaction, there is no real offline_access. The app might as well just send a freshly signed JWT, instead of needing a refresh token.

[akaegi]

I understand your reasoning @muhlemmer. However it produces more code on client side because token renewal has to be implemented manually. Otherwise this can be handled by most libraries that automatically renew access tokens based based on the "refresh token grant".

[muhlemmer]

I also understand your reasoning. However, we enforce the grant type on the token endpoint by OIDC client config. For refresh_token the OIDC config must contain that grant. In our current model, only OIDC apps have OIDC config. But JWT profile can be used by so much more, like APIs and service users. If those apps would start sending refresh tokens, they would simply get an error back that the grant is not allowed. So supporting refresh tokens here, is not as simple at the moment. This limitation is also present for other features and I'm currently rethinking the data model to unify the different App types we have, but I don't have anything formal yet.

Currently this issue discusses returning an ID token. We estimated this to be an easy fix that takes us less than a day, hence we categorized it as "Small issue". Adding refresh token functionality to this issue won't fit that definition anymore by the above reasoning. Hence, we will probably not do it now. I suggest you open a separate issue / feature request which can be estimated independently.

[livio-a]

zitadel/zitadel#7822 would fix this

[muhlemmer]

It would fix it only for zitadel through the custom implementation of the ClientCredentials server method. Is that sufficient for the requested usecase?