Custom UI
Reading the documentation, I came up with two questions:
- Is it possible to transform session tokens into JWT tokens?
- Or use the OIDC flow to generate JWT tokens from your own UI?
7 Replies
Hi @Guizão, I'm an AI assistant for ZITADEL. While a team member reviews this question, I'll see if I can find relevant sources for your question.
Answer
Session Token to JWT Exchange: Currently, this is not possible (1) . ZITADEL does not support exchanging session tokens for JWT tokens (2) . There's an open GitHub issue tracking this feature request (1) .
OIDC Flow with Custom UI: Yes, you can use the OIDC flow to generate JWT tokens from your own UI (3) . This involves:
1. Your application makes an authorization request to your login UI
2. The login UI proxies the request to the ZITADEL API
3. ZITADEL redirects to your login UI with an authRequest ID
4. You authenticate the user in your custom UI by creating and updating a session
5. Finalize the auth request by sending the session to the request, receiving a callback URL
6. Redirect to your application with the callback URL
The recommended approach for getting access tokens is to complete an OIDC login flow (4) . While this exposes users to a login UI, that UI can be custom rather than the default ZITADEL interface .
For applications requiring JWT tokens with a custom UI, implementing the OIDC standard within your custom login is the supported approach (3) .
To learn more, see the sources I considered:
[1] How to exchange session token(session api) for a JWT?
[2] Trade session token for JWT
[3] Support for the OpenID Connect(OIDC) Standard in a Custom Login UI
[4] What is the recommended auth flow? How to generate access tokens?
Feel free to tag @Ask Inkeep with additional questions.
Got it. Tagging @Rajat for additional help.
@Ask Inkeep [permission_denied] Auth Request created by other login client (COMMAND-rai9Y)
Thanks for the follow-up, @Guizão. I'll get back to you soon.
Answer
This error occurs when trying to finalize an auth request that was created by a different login client (1) . The auth request must be finalized by the same service user that has the appropriate permissions .
To resolve this issue:
1. Ensure proper service user permissions: The service user needs the
IAM_LOGIN_CLIENT role to finalize auth requests (2) . Make sure that the authorization header is from an account which is permitted to finalize the Auth Request through the IAM_LOGIN_CLIENT role .
2. Use consistent authentication: The same service user that creates the session must be used to finalize the auth request (1) . The error indicates that different login clients are being used in the process .
3. Verify session and token consistency: Ensure the session ID and session token being sent to finalize the auth request match the session that was created during authentication .
When finalizing the auth request, you need to send the session information to the finalize endpoint (3) :
The session token must be from the same authentication flow and the service user must have the proper IAM_LOGIN_CLIENT permissions to complete the OIDC flow (2) .
To learn more, see the sources I considered:
[1] OIDC - Unable to Finalize Auth Request
[2] Support for the OpenID Connect(OIDC) Standard in a Custom Login UI
[3] Finalize an Auth Request and get the callback URL.
Feel free to tag @Ask Inkeep with additional questions.
Got it. Tagging @Rajat for additional help.@Matías hey mate, any tips on how to get past this error? My service user has literally every possible permission
@Ask Inkeep I just have one service user, so how can the auth request be created by another client?
Thanks for the follow-up, @Guizão. I'll get back to you soon.
Answer
Based on the sources, even with one service user, this error can occur due to authentication flow inconsistencies (1) . The auth request creation process involves multiple steps where different authentication contexts might be used (2) .
The OIDC flow requires that the same authentication context is maintained throughout . When you make an authorization request to your login UI, it gets proxied to ZITADEL, which then redirects back with an authRequest ID . The issue often stems from inconsistent session or token handling between these steps (1) .
Here are the key points to check:
1. Consistent Authorization Headers: Ensure you're using the same service user's Personal Access Token in the Authorization header for both creating sessions and finalizing the auth request (2) (3)
2. Session Token Consistency: The session token you receive when creating/updating the session must be the exact same token sent when finalizing the auth request (3) (1)
3. Proper Flow Sequence: Follow the documented sequence - proxy the authorize request, get the authRequest ID, create/update sessions, then finalize with the latest session token (2)
The finalize request requires both sessionId and sessionToken to match exactly [(3) ](https://zitadel.com/docs/apis/resources/o
idc_service_v2/oidc-service-create-callback) :
As noted in the Discord discussion, the solution often involves ensuring the user ID and token are consistent throughout the flow (1) .
To learn more, see the sources I considered:
[1] OIDC - Unable to Finalize Auth Request
[2] Support for the OpenID Connect(OIDC) Standard in a Custom Login UI
[3] Finalize an Auth Request and get the callback URL.
Feel free to tag @Ask Inkeep with additional questions.
Glad I could be helpful. Feel free to create a new thread with any new questions you may have.
resolved. > had to update to the lastest version of zitadel
Hi @Guizão sorry for the late reply, I'm just seeing this. I'm glad to know you were able to solve the latest issue by upgrading Zitadel, thanks for letting us know 🙏