How to Validate a Session Token in Go Server Middleware After Custom Login?
We are building a custom login screen. After the password check is completed, I pass the session token generated from the response (https://zitadel.com/docs/guides/integrate/login-ui/username-password#response-2). This session token is set as a Bearer token in the request header, which is then sent to a Go server to fetch the user's organizations. However, the Go middleware is unable to validate this token. How can I validate this token on the Go server?
ZITADEL Docs
Flow
10 Replies
what do you mean by the go server is unable to validate the token?
this is an opaque token, you can read the session from the session api of zitadel, and then decide if the user is allowed to do what you want or not.
be aware that it is not an oidc compliant token
What about JWT?
We support giving a JWT instead of an opaque token, and with that the sig. can be verified by the client directly.
yes we support thaa if you are using our hosted login with oidc, or if you build your custom login and you build oidc on top, but the session token is always opaque at the moment
I want to use the token on the server side to access user scopes. I was using that opaque token in a Go authenticator middleware, but since it's an opaque token, it was not validated. Are there any specific documents or guidelines on getting a JWT token instead of an opaque one while building a custom login flow? Additionally, I want particular scopes to be added to the tokens.
You mentioned building a custom login and then building OIDC on top. What do you mean by "building your own OIDC on top"?
At the moment it is not possible to get a jwt token with the sesstion api. we have an issue here but no timeline yet: https://github.com/zitadel/zitadel/issues/7900
GitHub
Allow Token Exchange with Session Token · Issue #7900 · zitadel/zi...
We should allow Session Tokens to be exchanged for OAuth / OIDC tokens on the Token Exchange. This would give developers the opportunity to get an access_token from a session token, without the nee...
regarding the oidc implementation you can find the description here: https://zitadel.com/docs/guides/integrate/login-ui/oidc-standard
ZITADEL Docs
To build your own login ui for your own application it is not necessary to have the OIDC standard included or any additional work that has to be done.
Thanks. Will look into it.
I'm trying to implement a custom login using the OIDC standard, but I'm a bit stuck on the proxy request step.
The user is redirected to my login page:
http://localhost:3000/oauth/v2/authorize?client_id=170086824411201793%40yourapp&redirect_uri=https%3A%2F%2Flocalhost:3000%2Fauth%2Fcallback&response_type=code&scope=openid%20email%20profile&code_challenge=9az09PjcfuENS7oDK7jUd2xAWRb-B3N7Sr3kDoWECOY&code_challenge_method=S256&login_hint=minnie-mouse.
From there, I'm attempting to make a fetch (manual redirect) request to Zitadel at https://xyz.zitadel.cloud/oauth/v2/authorize with the relevant information, setting the x-zitadel-login-client header.
However, I'm encountering a CORS issue when requesting from http://localhost:3000.
@fabienne Any update on this ?Unknown User•9mo ago
Message Not Public
Sign In & Join Server To View
@Candyboobers Based on a workaround, we are not making this call (/oauth/v2/authorize) from the client side. Instead, we are doing the authorized calls from the server side returning backing that auth request ID to the front end.