JWT Profile Grant: return id_token if openid scope is set about oidc HOT 11 CLOSED

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.

from oidc.

Thank you @muhlemmer for your clarifications. If client_id must be the same as sub, then I should address it on client side I guess. I probably mixed the two auth flow use cases (normal users vs. anonymous users) in my mind.

Described case is for anonymous user API access and is as follows:

• Mobile app obtains assertion from server
• Mobile app uses jwt-bearer grant to obtain access_token for anonymous API access.

The id_token is rather a by-product not really used on app side for anonymous users but nevertheless checked by the used oidc library. Now thinking about it again, it probably makes sense to have client_id="anonymous user id" in this case. I'll tweak the library so that id_token verification can still succeed.

In any case, no "secrets" whatsoever are stored on mobile app side.

Long story short: No more actions required on your side, thank you :-)

from oidc.

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.

from oidc.

@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.

from oidc.

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".

from oidc.

zitadel/zitadel#7822 would fix this

from oidc.

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

from oidc.

Thank you @muhlemmer for implementing this extension 🙏
When trying to incorporate it into our mobile app I ran into the following issue: The returned id_token has its client_id claim set to to the user id of the asserted user as given by the assertion. However I'd like the client_id to be the mobile app's client_id (and have it in the aud claim as a consequence). Otherwise the id_token validation will fail on mobile app side.
Any idea on how I could either pass the client_id (currently ignored if passed to the token endpoint) or request it to be added to the aud claim?
@livio-a
Many thanks for your support,
Andreas

from oidc.

@akaegi with the urn:zitadel:iam:org:project:id:{projectid}:aud scope you can add the entire project of the client into the audience, making it valid for that app. Would that solve your issue?

from oidc.

Unfortunately no. I already added the project scope and have no problems with access_token validation on API/server side.
The problem is that the client-side OIDC library checks whether the configured client_id (of the mobile app) is part of the audience claim (this is according to OIDC specs)
Apparently, the client_id is currently somehow "fixed" to the service user id that is tied to the assertion of the jwt-bearer grant, see screenshot below (service user id ends with 0383)

from oidc.

@akaegi when mixing Oauth2 authentication methods with OIDC compliance, such collisions do occur. JWT Profile for client authentication is not part of the OpenID Connect specs.

RFC 7523, Section 3, item 2B specifies:

For client authentication, the subject MUST be the "client_id" of the OAuth client

I'm also surprised. Are you storing a private key in a mobile app, use it for end-user authentication and then pass the tokens to an OIDC library for verification? This doesn't sound like a good security practice, as malicious actors may try to obtain such private key using reverse engineering techniques.

Perhaps your use case confuses me. May I suggest a new discussion to be opened that describes the complete use case and explain how that use case can't be fulfilled using regular authentication flows? As I wasn't part of the talks that were held with @livio-a, I'm just guessing here.

from oidc.