-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JWT Profile Grant: return id_token if openid scope is set #587
Comments
Furthermore, it would be desirable to have a 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 |
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 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. |
zitadel/zitadel#7822 would fix this |
It would fix it only for zitadel through the custom implementation of the |
Thank you @muhlemmer for implementing this extension 🙏 |
@akaegi with the |
Unfortunately no. I already added the project scope and have no problems with access_token validation on API/server side. |
@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:
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 Described case is for anonymous user API access and is as follows:
The 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.The text was updated successfully, but these errors were encountered: