Closed livio-a closed 3 months ago
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.
@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.
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".
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.
https://github.com/zitadel/zitadel/pull/7822 would fix this
It would fix it only for zitadel through the custom implementation of the ClientCredentials
server method. Is that sufficient for the requested usecase?
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
@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?
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
)
@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.
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:
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 :-)
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
openid
is set, an ID Token to be returned to the client on JWT Profile Grant.